Repository navigation
Server Rendering for Queries? #501
Description
Activity
I notice that createSubscribeQuery has
options.results, described as "Prior query results, if available, such as from server rendering." However it's not clear how to generate these results and what type of objects they are expected to be.Should
resultsbe an array ofDocinstances? If so, how would one go about populating them? Could one calldoc.ingestSnapshotfor each of those? For that, we'd need an array of Snapshots corresponding to query results. For that, it would indeed be useful to have a utility method on Doc that generates a Snapshot. If we had that, we could iterate overresultsfrom a fetched query and serialize that during server rendering.I'm still trying to figure out how to do this. The Racer logic does not appear to be directly usable.
It seems that
connection.createSubscribeQuery()from the client side (as seen in Leaderboard) is the most common approach, but has anyone experimented with server rendering query results? Are there any examples out there where the query is executed in the server, then the results are deserialized and instantiated client side?I understand that
connection.createSubscribeQuery(collection, query [, options [, callback]])can be invoked whereoptions.resultsis defined, but how exactly to define it is not clear.The documentation states:
- options.results – Object[]
- Prior query results, if available, such as from server rendering
But what kind of Object[] should it be? An array of snapshots? An array of fetched Docs? An array of subscribed Docs?
I am also unable to find any test code that populates
options.results(intest/client/query-subscribe.js).Thanks in advance!
The source code lists
options.resultsas an array of Doc instances, as obtained fromconnection.get(collection, id):
sharedb/lib/client/connection.js
Lines 563 to 567 in 1cca122
I'll update the docs to indicate the specific type of
options.results!To initially populate a Doc on the client based on server-rendered data, you'd use Doc#ingestSnapshot
Thank you @ericyhwang for investigating!
To summarize:
options.resultsis expected to be an array of Doc instances, as obtained fromconnection.get(collection, id).- We can invoke
doc.ingestSnapshoton each Doc, but we do not need to fetch or subscribe them. - The internals of
createSubscribeQuerywill handle subscribing to changes in those Docs.
Greetings,
Is it possible to execute a ShareDB Query server-side, then pass the results data into the client via server rendering and use that to data hydrate a client-side ShareDB query?
Use case: a page that lists a number of ShareDB documents, where server rendering is in play.
Desired behavior: the query runs against the database once during server rendering, then in the client side the same query can be instantiated with results from the first execution, then subscribed for updates without triggering the query to be executed again.
I notice there is an internal method on Queries called
_ingestSnapshots. This seems useful for the task at hand.Is it possible to leverage that method? Might it be possible to expose that method as part of the public API?