I’m wondering why people doesn’t seem to use GraphQL jus with Redux.
I’ve never used GraphQL before but I’d like to start a new project, but neither Apollo and Relay doesn’t convince me. Currently I’m creating an app that use react and redux and “old fashion” rest api. And I love the idea of redux that it store whole informations about my app in one place.
And now, as far as I understand both Apollo and relay does something similar but they use separate store and in both we mixing the logic and view even more than with just React, both of these things (another store and mixing code) seems to be a bit messy. The advantage is caching, am I right?
So why can’t we just send the query as we used to with normal rest api and put the data to the redux store (maybe try to store some kind information about sync for optimisation).
Sorry if there are thing that i missed, I’m new here and I’m not a pro, it’s why I ask some people that probably has more experience that me :)
"store some kind [of] information about sync for optimisation" becomes a very hard problem when you have lot of interdependent entities.
Also, structuring the client side state is a hard problem in large applications. The rules of thumb, considered as best practices, in the redux community are that you need to normalize and remove redundancy in your redux state tree when inserting and denormalize them when using in components.
The libraries like relay and apollo want to own the state they manage so that they can remove this responsibility of normalizing/denormalizing the data, and managing the cache (as much as possible) to a significant extent from end users while still providing them low level control when they need to.
This is a fairly sophisticated problem because different components may depend on partial models eg. NoteSummary component may need only title and tags fields, the NoteDetails component will need description and comments too.
If you manage the redux state yourself you will have to write code for the following, when NoteDetails component is presented:
If a Note is not already present in the redux tree, fetch the required fields using a graphql query.
If a Note is already present, but not all the required fields are present, create a graphql query for the missing fields, and then fetch them by querying the graphql server.
If a Note is already present, and has all the required fields, just use the local version.
This becomes a lot more complex when we have entities which have dependencies on each other, or when realtime collaboration or subscriptions are involved.
GraphQL libraries attempt to solve all of the above in a very network efficient manner. Using react-apollo or relay your component can declare what all it needs and the underlying library, will intelligently figure out what and how much to fetch.
This is philosophically similar to how you write react components: In your render method you declare what your final component hierarchy should look like (given present state) and the library (react) figures out what changes are to be made to the DOM.
You should evaluate if your use case benefits from this kind of network efficiency and if so, whether you are willing to invest time putting in the effort required to learn GraphQL and the ecosystem around it.
If a redux store and a few ajax calls suffice for your use case, it can be a much simpler setup.
If you decide to go full on with GraphQL and Apollo, you might want to not have redux at all. You can use apollo-link-state and manage all your data (local or remote) using graphql Queries and mutations. Then from the perspective of your components it becomes irrelevant whether some data is remote or local.
Having said all the above, if you really want to just use redux along with graphql without any additional libraries like Relay you can use Apollo client directly. You can dispatch thunks from components, then in your thunks, you can make graphql queries directly using the Apollo client, and once you receive the response you can put that data in the tree in the tree using another action dispatch.
If this sounds more complex, it is because it simply is.
Related
I am planning to build a large React application which might contain hundreds of components. But not sure what state management system to use between Redux and Context API.
Context API is in-built in React and doesn't need any third party library. It is easy to implement and solves the problem of sharing states at different levels of the component.
But on the other hand Redux is the Industry standard and has support for middleware to perform async actions.
If I choose Context API how can we manage API calls with it. Also do you think it is a good idea to use context for a large application where we might need state objects extensively.
The design benefit from Redux is that the action does not implement. An action is an indication that something happened (for example SAVE_PROFILE_CLICKED) but the action doesn't do anything (like connecting to api, sending data and saving response in state). You can do this with context api but the separation isn't enforced as much and you won't have the redux devtools. The pattern is called event store/sourcing. You could change the reducer and replay the events to see if your changes work and create a consistent state, testing is easier, extending is easier, logic is better isolated and probably many more benefits to be had.
The design also separates writing to state (reducer), side effects (thunk) and reading from it (selectors). This pattern (writing/reading separation) is called cqrs. Your query/selector is separated from the command/reducer. This gives you easier testing, isolation of logic, less chance of duplicate implementation and probably many more benefits.
You can still make a complete mess of your project when using Redux and not fully understand it so using Redux does not guarantee anything.
If I choose Context API how can we manage API calls with it.
You can do it any way you like it, the question is too general to answer.
Also do you think it is a good idea to use context for a large application where we might need state objects extensively.
As stated before; Redux is no guarantee your project won't be a mess. It will give you the tools to implement certain patterns with more ease. Make sure you understand it and it's patterns. Most example applications don't demonstrate why Redux is so powerful as the problem they implement (counter, todo app) isn't complex enough to even warrant using it. I can only advice you would write code that you're comfortable with and can understand.
I am using Apollo Client 3.0 to fetch data from graphql server, but I can't decide what to use for local state management (Redux or Apollo Client 3.0).
I think Redux force me to write more code, but in a predictable and cleaner way which it's good. Also adding Redux to the app means I will have mix of 2 state management libraries.
Apollo Client 3.0 has Reactive Variables, but for large application I think it will become a mess! Also I can use queries and mutations with #client directive, but this could be a little bit confusing.
What do you recommend me ?
What should I use ?
Can you provide me some good examples ?
Thanks!
Apollo is not a state management library. It's an amazing client & cache for graphql, but when you start using it as a client-side state management, you'll notice that it isn't really meant for that.
The amount of code you have to write is similar to vanilla redux, as you have to write your own resolvers for every local query and mutation, but since there is a text-based protocol in-between, you lose all type safety you could have when staying "pure JavaScript". And then you have to manually put your data into a normalized cache, even if your data is not normalized, so you'll start putting your settings into settings/1, because everything needs an id, even if you have only one instance of settings in your application.
It all feels very clumsy from my experience.
Also, modern redux has a lot less boilerplate than you might be used to right now - if you follow the official recommendation to use redux toolkit (take a look at this page of the official redux docs), you'll write probably a fourth of code code you are used to with "vanilla redux".
Modern redux doesn't have hand-written action creators, action types, switch-case reducers or immutable logic. Those are all implementation details that are handled under the hood by now.
I actually did a conference talk on the topic a year and half ago, so I have some examples.
Here is what you write with Apollo (and yeah, the example is a bit artificial for Apollo - but I wanted to use the same example for all libraries and a login flow was what I had gone for)
This is what it looks like in redux
our team is using a hybrid of redux/sagas/apollo.
my question: why even use apollo to wrap components if we can
call fetch on the graphql endpoint
update our Redux store
use selectors to memoize and cache results
is there any other benefit besides code readability? (tying Apollo's graphql higher order component to the view)
Couple of things here. You can do what you described. In the end you can merge concepts together at your own will. There is no central authority deciding that you must keep concepts separate or together.
The question is really a team decision regarding how you collectively feel about redux's syntax and tradeoffs versus that of other state management. When you take that and compare it against your immediate needs then you ultimately must decide what the cost / benefit is.
Does your team feel ok about just using setState, bringing in unstated only when needed? Do you move away from higher order components since Apollo supports render props which are more easily composed? Might you be better off just using Apollo instead of redux? Do you want to use Apollo for your remaining local state?
Naturally I am leading you to my opinions based on what the community is exploring at the moment. Should you rewrite your application to use a certain pattern? Only you and your team can evaluate your current pain points you are running into to determine that. As long as you continue to ask questions like this an attempt to compare it against your team's needs then you'll be on the right track.
Redux works great in apps, but many teams run into challenges when they seek to generalize components that rely on redux, favoring more composable state solutions. Naturally YMMV.
in the Redux documentation is written:
In Redux, all the application state is stored as a single object.
And that starts my problem.
I'm writing an application that will manage few entities with many data in a SPA (React + Redux) and something is concerning me in to using Redux and get some kind of lag because the quantity of data that I'll need to manage.
I don't believe that transferring all the application state over Redux would be nice, because in some way, it may consume a lot of memory, but I may be wrong.
Redux looks like (to me) so simple and so confuse at the same time and I don't if I should or shouldn't use this, but, the application will grown a lot and I have sure that it will help me to maintain the project organized as well.
Another thing that scared me is about rendering DOM element when an updated state occur. It's different from using setState() on React and as we can see in the Redux videos from Dan Abramov, he is using a forceUpdate wich isn't recommended in the React docs.
Is it possible to manage the entities in different stores but put them together just when it is necessary?
Will it consume a lot of memory if storing all the application state in a single store object?
What's the best way to render React components using Redux?
You've definitely got several different questions there, and you are over-thinking things :)
First, caching data on the client-side is no different in Redux than with any other Javascript framework. In fact, caching data with Redux will likely take up less memory than it would with something like Backbone, because a Redux app will store plain JS objects and arrays rather than wrapping the data in model class instances. There's also no difference size-wise between splitting that data between multiple stores, and combining it all into a single state tree in one store.
Now, how much data you cache is up to you, but realistically you could easily load tens of thousands of records into a client app over time without having issues.
Second, don't confuse the small examples that Dan shows in those videos with how the React-Redux library really works. Dan was trying to illustrate some basic ideas, not show production-grade code. If it helps, he actually wrote a miniature version of connect that shows the basic idea of what connect actually does. Meanwhile, the real React-Redux library is highly optimized (and does actually use setState internally once it knows the data has really changed).
Finally, while you can create multiple stores, the Redux FAQ advises to only use one store, for several reasons.
I recently published a presentation that introduces the basics of React and Redux. You might want to read through that. I'd also encourage you to read through the Redux docs thoroughly.
Also, I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at https://github.com/markerikson/react-redux-links . Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a solid source of good info on more advanced topics.
Are Relay and Redux alternatives to each other? When are they best used with? Can we use Relay, GraphQL with Redux?
REDUX:
Redux is library
Redux is a state container for your app
Its a single point source where all information related to your app is stored.
You create actions,reducers and update your state by dispatching actions.
The state is immutable and you cannot update it. Always a cloned version of state is returned.
You use packages like redux-thunk / redux-saga to call apis. On Response of API's you update your state.
Now if you see in redux there is a lot of boilerplate code.
I personally find redux really cool and handy but you need to take care of following:-
Creating actions/reducers/store.
Dispatching actions and updating store.
Handling api calls.
Implement caching.
Maintaining store.
Maintaining expected props in components.
RELAY:
Relay is a Javascript Framework.
Handles store for you. You dont have to worry about updating store
Takes care of your API calls(this is the best feature)
Store is immutable and clone version is returned.
Works with GraphQL(this part is bit tricky as you need to understand graphql as well). After working on this for sometime I realised this is one major drawback. But once you understand graphql its really powerful
Works on queries and mutations
Relay is really really powerful and provides following benefits:-
You dont need to work about API calls. Relay network layer takes care of it. You do that through specifying queries and mutations
One of the best features of relay which makes it really useful is caching implementation. It reduces api calls drastically.
Relay is really really powerful but you there is bit of overhead when you get started. Following are the pre-requisites:-
React
Graphql
ES2015 JS
Once you are done with prerequisites also understanding how relay actually works is bit tricky and not as easy as redux. But once you understand how it works and why was it brought into picture you would really be amazed. Its indeed a really powerful tool.
So in case of your project is small-medium sized I would say go with redux and if its on large scale relay. But if you are working on react-native do give relay a try , its really interesting.
Also,yes you can use redux with relay.