Another post in the series!
Thanks!
4 Likes
I hope you know we’ll eventually steal all of your posts for the Meteor Guide 
1 Like
The GraphQL Server then puts together the state, possibly from many locations, and returns the client a representation of that domain state. The client can manage this state without putting constraints on how the server is built/managed.
This is the part I’m interested in, how does the client represents domain state that’s been gathered from many locations using REST, Graph, Meteor.Calls specifically using Redux with Meteor.
Where are you storing this data? and how are you using it?
For example, with Blaze, you store client side domain state in minimongo, UI state with reactive-vars in the template helpers. Templates would likely communicate/trigger through a tracked session variable. However, templates would typically have all the logic on a page so they could just use local variables in the same template helper.
This is what I’ve been struggling with using redux/meteor, there seems to be several ways to achieve this, which is in essence the whole client architecture.
The client represents data from the server like anything else, objects. State that is gathered from different locations should provide the easiest transform of that data to an object/format the client can consume.
Where are we storing this data? Most likely in Relay and passed through container components. We use it to power any UI that requires the data.
Yes just pick a way that works easiest for the problem youre trying to solve.
I’d be interested in a more in-depth look at how you guys use Relay with Redux within the context of Meteor. Feels like this is the most interesting part that you’re skipping over.
I mean doing domain state is pretty straightforward, your meteor.methods update/create on the backend db. Then you pub/sub to it or use a REST api to get snapshots of it.
Doing UI state is also pretty straightforward with redux. User events trigger actions that update state that updates components.
UI state can also be done without redux, just component state, and passing callbacks via props to parent/sibling components.
But how these interact in the actual app is the part where there are alot of options available right?
This misses the point of my reply. I’d like to know what your way is, eg how are you using Relay with Redux so I can compare my approach. Your article gets to it by the last paragraph, but doesn’t go into detail about how you handle the domain/UI state on the client.
They don’t interact. The apis to manage them are different. They represent different things.
Theres Redux and Theres Relay.
Sure I’ll post something about it soon
Also we are not running this code in production. This is the learning phase…
