I am producing mobile app using react native, and after days of learning Redux, and react-redux.
I have a big question mark that:
What is the scenario of using Redux in react-native?
I studied many tutorials that told us how wonderful it manage the state, how simply it manage the actions.
BUT, is it just happening when you only have many components on one page in your app?
For example, if I have a app with 2 pages, so called Page A and Page B.
Does redux can maintain the state of A, then using at B? (I am using react-navigation of jumping among pages)
If it can do, what is the different of that I stored state to AsyStorage in A, then fetch it back on B?
Seriously confused.
Just need your discussion about it please, if I get thing wrongly.
THX!
Before getting into your problem statement let us first see why we should use these tools anyway?
For Handling App's Data:
State - It handles component's internal data with not much complexity.
Props - It tosses data back and forth from parent component to children and vice verse.
Redux - It handles data efficiently using action-reducer-store architecture. Great for a complex app with a lot of user's data to handle.
For Data Persistance:
AsyncStorage - Simple API to save and manage data on device manually.
Redux Persist - Built over Redux to store all the Redux State data to device synchronously.
Now getting back to your situation,
If you JUST have TWO screens to manage data back and forth on, it's better to use just state and props. You don't need anything else.
By calling AsyncStorage you are saving data on the device and then receiving it from the other screen. This is not necessary if you don't want your app's data to remain on the device even after closing the app.
I hope this helps :)
Related
I'm trying to implement a simple app displaying data fetched via an API. I'm exposing my own API with an express server. With the API I can basically interact with my SQL database.
For the front-end and especially state management I wanted to use Redux, but I'm not sure how Redux can be used to manage state while simultaneously fetching data from a database / updating the database via the API.
Does Redux hold the same information as the database? How would one implement a combination of Redux and a database?
Redux is for state management. That means it basically has the same functionality as the react native state, that means they are going to get resetted when you restart your app.
A database on the other hand is used to store data also when you restart the App.
So, yes, it's definitly useful to implement both. Information which is going to be saved until it gets deleted should be saved in the database and information that triggers a re-render or basic information like if a checkbox is checken should be save in the state or Redux.
I'm trying to build an app, it has 3 Reducers
AccountDetails it holds all kind of user's products
GeneralData (eg. device's unique id, token, etc)
shopping carts
Me and my coworker currently building a registration screen that has 6 screens (the ui/ux team request this)
input username
input password & confirm the password
input DoB
input Email
screen to submit all the four data
nb: we use react-navigation
so my coworker suggesting to use redux to handle this kind of data flow, I think it is kinda "overkill" to create another redux for register, why not passing the username data, password, DoB, and email to route.params and submit it to the last screen and we will have lot of Reducers to handle registration, recover password, recover username, and maybe other things.
but we both want to make this application scalable and easier to maintain, but i don't really know the proper way to do that
Your project is simple that has only 6 screens. In case of simple project, you don't have to use Redux.
Whether to use Redux or not depends on your decision.
But as your project expands, you'll find it extremely difficult to handle all the states with route.params. Then you'll need to use something special to handle the states effectively and that must be Redux.
Redux is not something special but centralized state management system.
A lot of people take the approach of wanting to throw Redux at every situation. A lot of other people try to avoid Redux, using it only when absolutely necessary.
You mentioned that you and your coworker both want to make the application scalable and easier to maintain. You can make an argument for doing it either of the two ways you are considering, so neither way is necessary wrong.
However, the general consensus is that you should probably not put your form state in Redux. Redux has an FAQ page on this question here.
The general way to think about answering 'Should I use Redux for this?" is whether or not that piece of information will be used in other places throughout the app.
So for your scenarios you've got:
Account Details -> 100% use Redux
General Details -> Maybe. Usually there's simpler ways for tokens and such like just putting them in LocalStorage or AsyncStorage
Shopping Cart -> Probably. Again just ask yourself if you'll be using that information in more than a couple screens that are close together
As per your debate with your coworker, I'd say the answer is a combination of both. Passing that data inbetween screens is perfectly fine (and using Redux each step of the way is certainly overkill), but you'll want to add all those values to Redux at the end of a successful sign up. Cause those are the 'Account Detail's' you spoke of earlier are they not?
As the question suggests, I'm trying to figure out how to persist cached data beyond a phone reboot or app closure using React Native with Redux Toolkit Query. I've noticed that the cached data gets wiped in those scenarios. I believe that caching data beyond an app closure or phone reboot is a common practice.
I have thought about simply storing the data in client-side Redux using Redux Persist to get around this issue, without persisting the api slice. As this post indicates, persisting the api slice is a bad idea:
What happens when i use RTK Query with redux-persist?.
Any tips on this would be appreciated! Thank you.
Generally I can only repeat what I already said in the other issue:
I do not recommend doing this. Data from a server should be fresh, and this way it defitely won't be.
That said, we are currently working on SSR integration and that, too, will need similar functionality. So some kind of rehydration mechanism will be integrated, probably in Redux Toolkit 1.7 - but until then you have the choice between not keeping api data cached (again, my recommendation. No user wants to open an app and see data from five weeks ago - rather show them a loading screen!) or restoring it, but potentially ruining cache collection of said data.
After I got into the basics of React Native and developed some components, I did some research on how state management is being organised in larger apps and am trying to find out what I should be focusing on to learn those days. At first it seemed to be obvious to me that I would be using Redux, but it seems a lot of people are happy using GraphQL in a way that makes Redux even obsolete after implementing it. Now there's also the Context API and I'm wondering what you would be choosing today when writing an entire new React Native app that would be interacting with 3rd pty APIs a lot.
Thanks and regards,
Dennis
The answer depends on a lot of different factors. There are some cases where choosing one over the other makes more sense, but ultimately the decision is up to you. Nevertheless, let's look at some scenarios where it might make sense to use each of these options.
Redux
Redux is best suited for applications that need complex state management and a single source of truth. Typically you would wrap your entire application in a Redux provider so that the state of your entire application changes when this store changes. So this is best used when you have state that is used in many different places throughout the app and needs to be available to every component. An example might be that of a game where a player's actions impact everything around them. Here you could dispatch actions to Redux when a player takes damage or levels up to increase enemy difficulty.
Context
Context is (in my opinion) simpler to use than Redux and is useful for sharing state between a group of components. This is not necessarily for the entire app, although it can be and would effectively be a simpler replacement for Redux in that case. Rather, Context is used in situations where you have deeply nested components that need state from a parent several layers up, or for components that aren't nested within eachother but need the same data in order to work together. An example of when to use context would be in designing an image editor. You could have an image component wrapped in a filter component wrapped in a crop component wrapped in a sizing component and not want to pass the props down to each level every time. So you would wrap the top most layer in a provider and have each nested component be a consumer. You could also have a toolbar that can change the sizing, filter, etc. and so they would also be consumers and would call functions passed in by the provider. The rest of your app would have its own state and would not change when this state changes.
GraphQL
This is useful if you need to pull in state from several differnt APIs or backend services and combine this state all at once. This is dependent on either fetching from a preexisting GraphQL API or by setting up your own to pull in data from your other endpoints. Since you said you would be interacting with a lot of different 3rd party APIs, you could set up an Apollo server to retreive data from them, or use a service like AWS AppSync with Lambda if you want a managed GraphQL service. The beauty of GraphQL lies in that you can query for only exactly what your application needs at any given time. So instead of the APIs dictating what data the client can access, it is the client that tells the APIs what it wants, and then GraphQL gets it in an efficient manner. A perfect fit for this style of state management would be a blogging application. Here you need to pull in information on an author, and get all of their posts, and get all of the comments on their posts, and get their user info, and then get how many followers they have, etc. Where each of these pieces of data would normally be served from their own REST endpoint, you would end up making dozens - and in some case hundreds - of requests to your APIs and pulling in a huge amount of unnecessary data. With GraphQL you can declare what you want in the shape that you want it and pull it into your app in a single request. This would save you a lot of trouble in trying to see if your APIs have all returned a certain piece of data yet or not, and so you don't have to write a thousand if/else statements in your components. Only one would be necessary. However, GraphQL tends to be much harder (in my opinion) to setup compared to using Redux and Context. So be prepared that there is a tradeoff here. When people switch from Redux to GraphQL, they usually switch to the Apollo library in order to make use of their local state management and cache systems. These are not technically a part of GraphQL but are rather just nice add-ons that Apollo provides.
So that's just a general overview of the strengths and weaknesses of using each option. Again, which one (or which combination) you end up using really is dependent on your app's requirements. My suggestion is to experiment and find out.
In Android apps, when you start a new activity, the original activity is still in there, with all its internal data, so when you come back, it is the same as before.
How can I simulate this behaviour in my vue.js hybrid app? Is there some existing solution?
PS. I'm aware of vuex, but I think if I want to all the internal states of the pages in the history stack, then I must implement a stack-like structure by vuex myself. Is there some existing library can do this for me?
Thanks.
Wrapping <router-view> in <keep-alive> would get you expected results.
Or some custom baked solution, similar vuex-router-sync library to keep your page state in sync with the router.