I'm running a comparison between RTK Query and React Query, trying to decide which one to use in my React/Redux app.
One of the points for consideration is their integration with Redux.
I did some research and it seems like the only difference between the two in that regard, is that if using RTK Query you would see the query results in your Redux store and in the Redux DevTools which is a bit more convenient.
Am i missing something else? Or other than that, they both work the same with Redux?
RTK Query is part of your Redux store and as such also internally works with Redux. Everything is an action. So you can listen for those actions in your own middlewares or you can have your normal slice reducers act on top of those actions.
Granted, both React Query and RTK Query take over cache management for you, so in both cases, that data will be kinda separated - just because it is conceptually not very interwoven with your other state in most situations.
If redux is being used then RTK query can be a good choice for cache management because then the reducer of the api services example: post service, can be easily used in the store by adding them in the reducer object in the store. And if RTK query will be used with redux then there will be a lesser requirement of writing middleware in the code for redux.
Related
I got confused with the right data flow when I have a backend API and a redux state that passing the data to the components.
The question is: What is the right methodology to handle 2 data resources, API and Redux?
should I update the state and then fire a send request to the API with the update?
or, let the redux send that request for me every time the state changes?
or, should I update the API directly and then fire a get request to update the Redux store?
I'm really confused and do not know what is right approach should I take with less error in the future use
Appreciate any help, even sending me an article that talks about this issue and I'm gonna read it
Thank you
should I update the state and then fire a send request to the API with the update?
That's called "optimistic update", the advantage is that your app feels fast and responsive, since the network delay is hidden from the user. The downside is that the request might fail and you have to undo what the user did and inform them that it failed. For simple operations (for example marking a product as a favorite in an ecommerce website) this works great in my opinion.
To explain how it works with the example in mind:
User action triggers update of redux state (product is immediately shown as favourite on the page)
At the same time, an API request is fired to favourite the product on the backend side.
You fetch the product data again from the API and render it
Now either the request has successfully changed the product, so visually nothing changes on the page for the user - to them it looks like the operation happened without network delay - Or the request failed and you show the old state where the product is not a favourite and and error message appears.
or, let the redux send that request for me every time the state changes?
Parts of redux-toolkit embrace this approach if I'm not mistaken. If you decide to go down this road, I'd recommend to not implement it yourself but instead rely on existing libraries/middlewares.
or, should I update the API directly and then fire a get request to update the Redux store?
This is the classic, safe, and simple approach.
My advice is:
If you have lots and lots of CRUD operations against your API, and you want to not write lots of boilerplate code, look into redux-toolkit (specifically https://redux-toolkit.js.org/rtk-query/overview ).
If you care about perceived performance of your app, try optimistic update.
If you want to keep it simple and just get things to work, follow the classic approach.
How would you combine / solve the two diverging approaches of:
rtk query / graphql advising to only fetch what is needed on that screen
offline first capability
in a react native app?
Basically apollo and also rtk-query advise for small queries that are only fetching data that is relevant to what the component needs. This would mean that all data is only present when rendered, but what happens when the user does not have internet?
We don't want the user to see outdated data if they haven't visited that screen for a long time so we want to fetch this in the background and never show loading spinners. When they are offline everything should be as up to date as possible and usable.
Also mutations should be queued and performed when internet access is restored. The app should basically behave as if there is no connection issue at all.
So probably a graphql subscription would be ok but everyone strongly discourages to the subscribe-to-anything-pattern. Subscriptions in graphql still sound like they should be small and also only care about what is rendered on the screen and unsubscribe when the screen is unmounted.
At this point this whole seems like a graphql anti-pattern to me, but from a user perspective it makes sense for a (react) native app. You want stuff to be up to date because it is an app not a website where a lot of data is cached anyway and timeliness doesn't matter that much.
I'm very new to React Native (did some courses) and now building my first app on my own which is going great, but I need some advice regarding user applied filters and how to handle this.
Quick summary of what needs to be done.
The user should be able to set some filters so only certain data is displayed and this state is saved even after closing the application, user logs in again and still sees only the data that is filtered because of the filter option he/she set before.
In one of my courses I got an introduction into Redux and my question here is should I use Redux for this feature or maybe Context for this ? My data is fetched from Firestore and I'm able to use a query to filter data from firestore but that just ends up in many read/writes which cost money.
All advice is more than welcome!
use redux
when you need some static state globally in your app then use context like open close drawer etc. For dynamic states go for redux
As mentioned in stackoverflow answer :
As Context is no longer an experimental feature and you can use
Context in your application directly and it is going to be great for
passing down data to deeply nested components which is what it was
designed for.
As Mark Erikson has written in his blog:
If you're only using Redux to avoid passing down props, context could
replace Redux - but then you probably didn't need Redux in the first
place.
Context also doesn't give you anything like the Redux DevTools, the
ability to trace your state updates, middleware to add centralized
application logic, and other powerful capabilities that Redux enables.
Redux is much more powerful and provides a large number of features
that the Context API doesn't provide, also as #danAbramov mentioned
React Redux uses context internally but it doesn’t expose this fact in
the public API. So you should feel much safer using context via React
Redux than directly because if it changes, the burden of updating the
code will be on React Redux and not you.
It's up to Redux to actually update its implementation to adhere with
the latest Context API.
The latest Context API can be used for Applications where you would
simply be using Redux to pass data between components, however
applications which use centralized data and handle API requests in
Action creators using redux-thunk or redux-saga still would need
Redux. Apart from this Redux has other libraries associated with it
like redux-persist which allows you to save/store data in localStorage
and rehydrate on refresh which is what the Context API still doesn't
support.
You can refer to the blog1 and blog2 in order to get more clarity on when to use redux and context.
I'm looking to persist the application NgRx store to either local storage or a NoSQL database. This is so the application/user can resume from where they left the application last time they visited.
However, if the structure of the state has changed in my application the old persisted state will need to be migrated to the current one. Is there a way to do this with standard NgRx tooling or features or another popular pattern/method?
There is no generic way as far as I know, it's up to you to handle structure changes - we can't make those decisions for you.
The answer also depends on what you store, is it the full state or are you storing the actions. Both are valid and serve different needs.
If you're storing the full state, you'll have to provide a migration to migration from version 1 to version 2.
If you're storing actions, you'll have to keep the reducer functions to handle those actions.
I am new to redux. I am modifying an existing code in redux based aurelia app. I am developing new features which does a rest call on successful return of another rest call. As far as I have researched, many people recommend think for async and sync calls. I need to know that does adding thunk requires significant code change in the existing project like modifying dispatch and other invocations.
I am developing new features which does a rest call on successful return of another rest call.
I am not sure if you need Redux at all for doing such things. If you are using service like Axios to call API you can easily achieve this.
I would recommend you to go through this article to better understand if you need redux at all, and for Redux Thunk middle ware this official page. It does not require so much change as you are thinking.
Though, I would suggest you to check your approach first, if you need Redux or Middleware at all!