-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[meta] Make all state contextual #558
Comments
I think this is actually fairly critical for server side rendering. |
@josephsavona Do we want |
@josephsavona Also |
The methods for injecting these should be on Relay.Store since that's public, but they should save the scheduler/network layer to RelayStoreData. |
Re RangeUtils, agree this map can be saved into StoreData. |
Looks like |
I was on my phone earlier, so here's more context on each of the above
Re the distinction between |
Super helpful, thanks 👍 |
Summary: Converts `ChangeEmitter` to a class instead of singleton and holds an instance in `RelayStoreData`. Note that `QueryResolver` was already contextualized (it accepts an instance of `RelayRecordStore`) but it now needs the `RelayStoreData` instance to get access to the change emitter. Original:Builds on #562. Part of #558 Closes #565 Reviewed By: yungsters Differential Revision: D2632148 fb-gh-sync-id: b5073151d6459c018bc56654a9deb8bb407fcc41
@josephsavona you can use this syntax to track subtasks: * [ ] In progress
* [x] Done Result:
|
Summary: > This PR is another step toward making all Relay state contextual (#558). Originally this was submitted as a part of #683, but josephsavona [suggested](#683 (comment)) to split it to smaller PRs. `RelayContext` will ultimately be the public API of Relay Core, exposing all methods required to implement declarative APIs such as `RelayRootContainer` and `RelayContainer`, and will manage its own private instance of `RelayStoreData` (which will be an implementation detail). This diff is a first step in that direction: - Creates the `RelayContext` class - Changes `RelayStore` to be a (singleton) instance of the above, using the singleton `RelayStoreData` to ensure that callers of `RelayStoreData.getDefaultInstance()` get access to the same information as that accessed by via `RelayStore` - i.e., that all existing apps keep working as-is. Closes #698 Reviewed By: yungsters Differential Revision: D2784307 fb-gh-sync-id: e1764f9e0ef1dc7a1d1016fe8fdfd9012e7e63d3
Summary: This PR is another step toward making all Relay state contextual (#558). Originally this was submitted as a part of #683, but josephsavona [suggested](#683 (comment)) to split it to smaller PRs. Closes #761 Reviewed By: wincent Differential Revision: D2863416 fb-gh-sync-id: f9907959aac71b14e54d2746b86927b6fd8b1952
is there a timeline for release? I'd love to contribute, but finding the time to get up to speed with the internals would probably be longer than it'd take you to finish. |
Just a heads up that this and the react-relay/Relay core split will be my main area of focus for the next couple months. Contributions are welcome, but definitely reach out to us before starting a major PR in this area. |
@leebensen there are always things that need attention. I'd recommend starting with a small task at first - take a look at issues tagged with "good first bug"! |
Summary:== Original Description == This PR is another step toward making all Relay state contextual (#558). Contextual `RelayNetworkLayer` is important for server-side rendering. It will allow to inject a contextual network layer initialized with client request specific params (e.g. authentication cookies) on the server. Currently it is impossible because the injected network layer is global, and shared between client requests. == Summary of Changes == - Moves `fetchRelayQuery` to a method on `RelayNetworkLayer`, which is now a class with an instance held by each `RelayStoreData`, thereby making the network layer contextual to the context instance. - Changes `Relay.injectNetworkLayer` to a facade for `RelayStore.injectNetworkLayer()`. - Changes the FB/OSS `Relay` module to inject a network layer directly on `RelayStore`. - Re-create `fetchRelayQuery` in relay-fb for convenience Closes #704 Reviewed By: wincent Differential Revision: D3016293 Pulled By: josephsavona fb-gh-sync-id: 2e5f3163bc048a089776477b3d2dac2546fd9f48 shipit-source-id: 2e5f3163bc048a089776477b3d2dac2546fd9f48
Summary:== Original Description == This PR is another step toward making all Relay state contextual (#558). Originally this was submitted as a part of #683, but josephsavona [suggested](#683 (comment)) to split it to smaller PRs. == Summary of Changes == - Make `relayContext` a required prop on `RelayRenderer` - Change `RelayRootContainer` to pass `RelayStore` (a default instance of RelayContext) as the relayContext prop to its internal RelayRenderer - Update tests (in particular, checking that changing the relayContext prop on RelayRenderer works as expected) - Update products that use RelayRenderer directly to pass RelayStore as the Relay context Closes #810 Reviewed By: wincent Differential Revision: D3006237 Pulled By: josephsavona fb-gh-sync-id: 6cf774f1ee5a81ec9d3c5e499f0d1e25fe3befc5 shipit-source-id: 6cf774f1ee5a81ec9d3c5e499f0d1e25fe3befc5
Reviewed By: wincent Differential Revision: D3017230 fb-gh-sync-id: 0de370b24e0db51b3dbbce4a55f6eb8167390773 shipit-source-id: 0de370b24e0db51b3dbbce4a55f6eb8167390773
Heads up that we're renaming |
Summary:== Original Description == This PR is another step toward making all Relay state contextual (#558). Originally this was submitted as a part of #683, but josephsavona [suggested](#683 (comment)) to split it to smaller PRs. Currently, Relay resolve mutations props using the global `RelayStore`, and store them in the `props` instance field of `RelayMutation`. That makes it impossible to contextualize Relay mutations without changing the public API. After analyzing different alternatives, I have found that the probably cleanest solution is not to store resolved mutation props in an instance field, but to pass them as an argument to each of the mutation methods. That way mutations can be reused in different `RelayStoreData` contexts, and also they can be reused in the same context but at different times, because props are re-resolved at each mutation execution. == Summary of Changes == - Change `RelayMutation` constructor to not immediately resolve data for fragment props - Add `bindContext` method on RelayMutation, called when the mutation is committed on a specific RelayContext - This necessitated adding the `read` method to `RelayContextInterface`, and stubbing this method on alternative context implementations. - Updated mutation docs to mention this method. Closes #699 Reviewed By: yungsters Differential Revision: D2913334 Pulled By: josephsavona fb-gh-sync-id: 5051fddf068fc8bc7379bb55c8b1e4d97e33313c shipit-source-id: 5051fddf068fc8bc7379bb55c8b1e4d97e33313c
As of 8e53183, all of Relay's internal state tracking has been contextualized. Each instance of Thanks especially to @denvned and @devknoll for their impressive contributions! |
Awesome. Looking forward to it! 🎉 |
Amazing work! Thanks @denvned, @devknoll, @josephsavona . 🎉 |
Yeah! On Wed, Mar 9, 2016 at 6:59 AM Rodrigo Ribeiro notifications@github.com
|
This is a meta-task to track progress toward making all Relay state contextual, such that multiple instances of Relay can be run in the same JS context. The primary motivation is to support server rendering in open source, where sharing JS contexts is the norm.
Tasks:
GraphQLQueryRunner
GraphQLPendingQueryTracker
should write query results into the contextual RelayStoreData instanceGraphQLDeferredQueryTracker
: should read query root IDs from the contextual RelayStoreData instanceRelayMutationTransaction
should write mutation results into the contextual RelayStoreData instanceGraphQLStoreRangeUtils
- this holds a global mapping of dataID -> range information, and will have to be made contextual. The primary caller isreadRelayQueryData
.GraphQLStoreChangeEmitter
notifies components (or other observers) of data when it changes.RelayStore
a singleton instance ofRelayEnvironment
RelayContainer
/RelayRenderer
to access data via the React contextRelayRenderer
Relay.injectTaskScheduler
a method onRelayEnvironment
Relay.injectNetworkLayer
Note: the following will be completed as part of #559:
DocumentRelayEnvironment
, make it accessible viaRelay.Environment
or other, and remove any unsupported APIs (or mark them as such).PromoteRelayRenderer
to public APIThe text was updated successfully, but these errors were encountered: