imagine a data driven app like a hotel management software implemented in react redux, now we have multiple pages like users, check-ins, services, invoices etc.
while opening each page data is loaded from API and stored in redux store, so my question is what are common design patterns to handle previously fetched data when navigating to a new page, you obviously don't need users when navigating to invoices as invoices API provides minimum user info associated with each invoice.
So should we unload users in store in ComponentWillUnmount as we navigate to invoices?
Should we leave the data in store?
Should we use a single array to hold our data and overwrite it every time?
What are some best practices according to your experience?
What are some best practices according to your experience?
Generally, we can always follow these guidelines as rules.
Everything will fall in place.
Should we use a single array to hold our data and overwrite it every
time?
If you have some data like invoices which is not too complex, that also need to be listed but not frequently updated, using array will work fine. we also can use selectors or utilities,
to select specific invoice and update component.
In case, if we have data that is frequently updated or has nested list then it is recommended to make it flat (normalise). Here is a detail read :
Assuming invoices are frequently updated ? we can keep map of invoices
{
"invoiceId1" : {},
"invoiceId2" : {}
}
So should we unload users in store in ComponentWillUnmount as we
navigate to invoices?, Should we leave the data in store?
It depends on use case. Let say if we have one single (route) or page component adhere's to both
Complex data
Total independent data
Then It is recommended to clear it up, else it should be good. however in redux,if we are normalising the store then it should not be a problem.
Please go through this FAQs related to redux-performance, it will provide clarity on memory management in Redux.
Related
I'm currently building an e-commerce react application, where users can sell pre owned stuff to each other. A typical workflow from a user perspective for creating and managing ads can look like this: A user creates an Ad -> The Ad is uploaded to a database -> The user fetches his ads from a database and views them in a list -> He decide to change something in an Ad, clicks it and gets a form with the ad data (fetched from database) that can be edited.
My problem here is that I'm really confused about what to keep in redux? The purpose of redux is to simplify data flow, data that is needed in multiple components should be stored there. But if I always fetch the data i need from database (as for example when a user fetch a list of his ads or the ad data that can be edited), isn't redux just an unnecessary step then?
I want to be consistent throughout my code about how I'm fetching data. Right now I've been using redux to store all my data fetched from database, keeping all my API calls in different actions. The data fetching however get really troublesome when it comes to fetching data from the database that then should be editable by the user. To make fetched data editable, it has to be stored in the components local state, so storing the data both in redux and local state feels very inconvenient.
I've searched the web for specific guidelines for the but I'm not getting any wiser. To be honest I don't think I've understood how to use redux properly. I would be really grateful for some advice on this matter.
Primarily its used for application state management. You need to consider your usecase and yourself simple questions i.e
Do you need that state for rest of the applications?
Will other components get affected by these states?
How often your data will
change?
Are there other users using the same data and can update it?
Do you need to cache the data to prevent refetching?
The view built on top of it is a reflection of that state, but does not have to exclusively use that state container for everything it does.
For example, in your case, you will need to keep your api's responses into redux state if you want to pass that state to other components and you dont want to do the same API call again and again.
But, if your data changes so often and you need refreshed data everytime you should not keep it in the redux. Otherwise you will end up having stale data on different screens.
Note :
There could also be other possibilities that can be consider but this is some very basic info that I thought will be useful for you to take a decision
I'm very new to ReactJS and Redux (but not development, in general). I'm trying to determine how best to approach a SPA I'm building.
My app will download datasets via API and display them in a spreadsheet. I'd like to use Redux to store the data. Is that the right approach? We could potentially be looking at very large datasets. Would it be more appropriate to only store the data that is currently rendered in the spreadsheet?
I'm totally lost as to an approach that would be efficient in terms of rendering speed and memory management as well as mindful of potential network issues as rows of data are requested from the API.
Thanks...
When you are working on a react/redux app, you generally will have two options to store your state: local component state or in redux. There are quite a few blog posts out there detailing when each is appropriate. This github issue comment from Dan Abramov, one of the creators of Redux, pretty succinctly sums it up
Use React for ephemeral state that doesn't matter to the app globally and doesn't mutate in complex ways. For example, a toggle in some UI element, a form input state. Use Redux for state that matters globally or is mutated in complex ways. For example, cached users, or a post draft.
Sometimes you'll want to move from Redux state to React state (when storing something in Redux gets awkward) or the other way around (when more components need to have access to some state that used to be local).
The rule of thumb is: do whatever is less awkward.
Both component state and redux state can be used performantly, so I wouldn't worry too much about that when choosing. From what you've described, the questions I would ask are
Do I need to have multiple spreadsheets of data loaded, but not all displayed at once? For instance, maybe you have multiple tabs of spreadsheets and you want to be able to tab through them without having to re-fetch the data each time
Do I need access to the spreadsheet data in a lot of different places, or is it fairly localized?
Will I be able to modify the data in the spreadsheet, and if so, how difficult would it be to perform those modifications using redux and without?
There are quite probably other considerations as well. In general, the advice given is to stick with just using React local component state until it starts feeling awkward, and then move to redux at that point. Oftentimes, components state is all you need, and if not you'll get a better appreciation for situations where redux helps.
So, we are planning to use a PHP backend with a React+Redux frontend server. We are developing a very large application, lots of tables across the entire application. Since it will be a Single Page Application, all the data is contained within on store object.
So, let's see if I am with the right mindset. My state would start almost empty when I login into the app. As I visit pages, my state will start to fill up. Example: I visit the "photos" of the app, then I will end up load some of the photos from my DB and putting it inside my store:
state{
...
photos: [1: {...}, 3: {...}, 17:{...}]
...
}
And later on, if I need photo with id = 17, I don`t need to request it again, I can use it from my store, right? Or maybe I take it from store first and request it async to check if there were changes to it.
As I visit more and more pages, I'll have a huge store object with a lot of elements from different tables, eg. photos, videos, user_configurations, friends etc. How should I deal with data consistency? If I need an object I already fetched 10min ago, should I request it again? Is it "healthy" to have such a big store object?
I'm planning to use normalizr & reselect to manipulate my date inside react-redux.
Any thoughts on it?
I would like to hear how do you think is a good way to deal with the situation.
Thanks in advance!
Fábio
Yes, a normalized Redux store is the standard recommendation. See Redux FAQ: Organizing Nested State , Structuring Reducers - Normalizing State Shape, and the Selectors and Normalization part of my React/Redux links list for more information.
As for caching data, conceptually this shouldn't really be different than any other client-side setup. Storing lots of data will take up a similar amount of memory, no matter whether you're using Redux, Angular, Ember, Backbone, or something else. It's up to you to decide how much you want to cache, and when and how you might want to clean out cached data.
Finally, for manipulating relational/normalized data in your Redux store, I recommend a library called Redux-ORM. You should absolutely use Reselect in general, and Normalizr is good for normalizing data you've received, but Redux-ORM provides a useful abstraction layer for querying and updating that normalized data once it's in the store. I've written a couple blog posts describing its use: Redux-ORM Basics and Redux-ORM Concepts and Techniques.
Lets say we want to have one instance of the application and multiple tenants trying to access same features but also have some level of customisation and of course data isolation. In short Basic SaaS model.
Tenants will probably be identified by subdomain/domain and/or by querystring.
So the main question (which is rather specific):
What are common approaches onto implementing a multitenant environment using React + Redux ?
Thinking loud:
How to approach/structure the Application Store.
How to deal with tenant specific configurations
Do I need to have some sort of a TenantContext available somewhere at hand.
How to ensure proper level of isolation and avoid race conditions?
What else should be kept in mind while developing it?
Any thoughts, ideas, past experience, advice, are highly appreciated.
Thank you!
A typical Redux store usually only reflects persistent data, and contains application-specific data, like which tab is active or what is the value of that field. But in case of persistent data, that's an interesting question. I believe React and Redux are simply not for that. But even though, there's an interesting solution for that: Relay and subscriptions.
Relay connects your components to a GraphQL source of data (typically remote), and then you simply access props that are seamlessly injected into component and given values from the data storage. With subscriptions, any update in the data storage causes its delivery to a connected component via a subscription established between the app and the GraphQL server.
Now, you can add an extra layer for multitenancy and synchronize data between nodes on a lower level, completely unrelated to React. The only thing now is that you'll need to listen to every update and send subscription updates, and there's no nice "single-click" solution for that yet.
You can see this discussion to get an idea how you can update a subscription. Good thing is that, on the client-side, the app will simply react to updated props with a connected component being re-rendered with new props.
I have some questions about the store in ReactJS/Flux implementation.
Basically, I have all my API request which use store. But sometimes, I think store is an overkill features.
A simple example :
I just want display a list of the five last user who have registered on the home of my dashboard. I never want to refresh this list until the user refresh the browser. Should I use a store just for that ?! Or maybe I can create a "global" store for my home page where I include all this little things like this (static display of data requested by the API).
I have another question about store, how much a medium-size application have store ? Because mine have already a lot of store (20-30).
You create one store by page ?! By models ?! By components ?!
Thanks for you response.
TL;DR: many Reducers, one Store.
You tagged this with Redux so I'm going to answer based on the assumption that you're either using Redux or want to use as your Flux implementation.
Regarding the number of Stores, from the Redux docs:
It’s important to note that you’ll only have a single store in a Redux application. When you want to split your data handling logic, you’ll use reducer composition instead of many stores.
So it might be that you want to create a home Reducer to handle all the API responses for your homepage and save those to your single Store.
In your simple example, probably you don't need a store, but I would still use one, as it makes your application scalable. You never know when you would be asked to add new features to it.
About your other question, it totally depends although 20-30 stores sound a bit excessive.
Personally, I use redux and I just have one store with multiple reducers which I combine using redux's combineReducers.
This answer is assuming a few things, but here is my attempt:
A store might be overkill in this case since there is no updating happening after the user refreshes the page. Seems like a static object to me. If you don't have a store already and want to keep going without one I would suggest (assuming you are using flux) to create your dispatcher events within the component that needs this list. The dispatcher will listen for events from your actions. I am guessing your actions make the back-end call to get the last 5 users so the action would then emit an event with the 5 users you are wanting. When the dispatcher receives the event you can set the list of 5 users within your component.
The use case for a store that I have found is when you have "living" objects that change with user interaction on your page. With a store it may be easy to live update your list of 5 users every so often based on an interval and it also serves a way of abstracting out the dispatcher logic from your component into a nice and neat store.