The only thing we care about is whether or not we have (any & all) data
about the submission. Using URL here is confusing because it conflates
with the prop, and checking the prop in the first place always gives the
same result.
Previously, receiving new items could "locally create" pages,
half-filled with whatever items were pushed down into them. Frontend
would see the existence of the page and assume all was well. However,
the page may have contained more items (on the backend) than just what
we pushed down.
This adds a per-page flag, "local", to indicate such pages. When display
logic sees it's set, it will send a request for the full page,
regardless of currently available data, loading in the canonical full
page as a result.
The Number() usage is sane, but should be scoped around the variable by
itself. Previously a string of "3" would lead to a Number("31") call,
which is not the intended behavior here.
Also stops passing a {} in if the actual number is unknown.
On the frontend, updates the route path to include the (base64-encoded)
url. Uses that and the load-single functionality to support loading
directly into a submission page, which fetches just the requested
submission.
Also ensures we don't open duplicate comment subscriptions.
Replaces .json requests with channel.js subscriptions. Rewrites reducers
to match, now being more careful about paginated data, and storing
comments in their own structure, at [group][url] indices, rather than
the non-static [page][index] ones used previously.
Note that this requires some changes to the frontend UI code also.
See next commit.
Base64 encoding isn't actually @ta-safe, since it contains capitals and
=. +wood escapes all such characters explicitly. The result is more
readable and more hoon-native paths, but does mean clients will have to
re-implement +wood locally.
Better subscription path API support. Should support us better moving
forward.
Note that this kills the server-hook. It will be replaced with a
link-view shortly.
Also re-orders the comment paths to have URL first, which is easier to
handle and also seems more correct wrt the behavior you might want in
the web extension and similar use cases.
