Satyen Desai
Satyen Desai
Beyond the basic concepts, we've heard from developers that a set of recipes for common JSONGraph domain modeling problems would be useful.
Although we have pretty decent unit test coverage, we still have issues which slip through due when hitting real world client-server interactions. It seems like it's more efficient to invest...
We could provide an option to materialize empty atom on the client, as opposed to requiring the server to fill out them - maybe something we'd want to do for...
Which may highlight missing batching/collapsing/de-duping opportunities, resulting in inefficient request/responses.
We spent some effort optimizing `get` assuming a response from cache (that is, we took some stabs at optimizing the get from cache algorithm). There may still be optimization worth...
e.g `[list, currentPage] -> [lists, 1234, {from:10, to:20}]` Need to flush out more details, and whether or not this is valuable/a priority for top-down/single source of state re-render UI integrations...
Allows for more convenient integration in state change top-down re-render flows (react). May require us to evaluate immutable output from get for a performant implementation.
Supporting PathTrees as input, results in both a more ergonomic API (less overlapping paths in pathsets) and has the potential to result in a more performant code path.
Figured it was worth uncommenting one of the examples, so that users see something when they first run the instructions in 'Getting Started' for falcor. Not sure if there was...