I'm working on a React + Redux application, and I need to display a datagrid with paginated data. I have potentially thousands of rows, but I don't want virtual loading through scrollbar; I want pagination. I load data through Ajax calls.
I'm probably going to use jqGrid which seems to be a fine candidate for the job, as it can load data given on the fly, and display a "virtual" pager for data which is not yet loaded.
My question is about how I handle that in the React + Redux world.
Should I make Ajax calls in action creators, and pass the fetched data to reducers, to put it in the state, so then components which are subscribed to the Redux store can get it?
Or should I make the Ajax calls directly in the component?
Also where should I keep the querying data (page number, items count per page, total number of rows, sorting/grouping/filtering informations)? In the component or in the state?
Keeping the ajax logic in async action creators (with redux-thunk middleware) is generally a cleaner solution than messing with ajax inside components. Ideally your components should be dumb, only dealing with the props they're fed. If you're not familiar with async action creators in Redux, the docs cover it quite well: http://redux.js.org/docs/advanced/AsyncActions.html
As for storing stuff in the Redux store vs. components, the general rule of thumb is that if you want to replay a certain state, or the state says something about the application as a whole: keep it in Redux. With Redux I only use component state for trivial stuff like displaying tooltips, and other things that don't have much to do with the general data model. Of course, React and Redux don't force you to do it in one way or another, but speaking from experience, using the Redux ecosystem to handle flow of data and metadata in an application makes it much easier to reason about the code later, especially when using redux-devtools.
Related
I'm currently using React (with hooks) and Redux-Toolkit. After reading through the docs, I've come across Redux Thunks, createAsyncThunk, and RTK Query. Out of these three methods, which is the best for fetching data in a Redux slice, modifying that data within the slice, and then dispatching said data to a React?
Thanks in advance for your answers!
Each of them serves its own purpose, and only RTK-Q is made exactly for data fetching and caching.
The "problem" is that it's
Not really integrated with the application store's Redux and Thunks by default - it "lives" in its own store, with its own cache state, actions, and middleware.
The idea is that you don't want to put fetched data in your app-store, course, it will just duplicate the data and add another "source of truth" with the following inconsistency.
RKT-Q adds a concept of "API state", which represents the data on the backend, and should be handled significantly differently than App's (frontend) state.
In extra cases, you may handle the RTK-Q-related actions, handle them in your middleware (Thunks in your case) and update your Redux app-state producing actions with some calculated data\flags, etc.
Not covering all the cases of Application <-> API negotiation.
As an example - file\data export, API action calls, and other stuff that is out of RESTfull architecture. If you'll try to download a file from API via RTK-Q you'll find how bad it's covering such a case, and you'll be forced to use separate flow via Thunks\Sagas or\with plain fetch API to do so.
But still, RTK-Q brings you so much out of the box, so it is worth using it by default for data fetching, even with some work to handle several edge cases.
Wrapping up - I believe that there is no right\complete answer to your question and just more things to consider for your own app architecture design.
I'm working with a react app and currently working with a feature. The main task is showing some charts by getting data from API. And these charts will show the last 30 minutes' data.
I have questions,
In this situation, is it necessary to store these data in the state by Redux, though it can be handled at components very easily? And every time I refresh or request, I get new data (log base data).
When do we make the mind to store data in state and when not?
A redux store is a singleton, thus a single source of truth that can be made available to all components in the whole react application. If your state is intended only for one react component then you don't need a redux store. A useReducer react hook allows to well reproduce the redux pattern in a single component. Stick with a useReducer hook for a single component and use redux library for a store available to an app composed of several components.
Redux is not designed for the specif role of a special type of data.
You can use still store your temporary (30 min) data into redux, and use it to cross your feeling the same as the rest of your data.
But in this case, you might need to reset data after 30 minutes or invalidate your cache, keep your eye in react-query and RTK-query handling these types of actions more easily for you.
If data is being used for many states or those data are being used by many components then you should use redux. You can still go without redux, it is up to you after all.
If you have various components and routes then redux will help you to reduce the codes and also make the codes simpler.
Redux will give the one store for all the components in the project to store and access the data which is better then context or props tricks.
Also if you want to achive something like if user opened two different tabs. Let it be same page or two different pages of your website and if user done an action on page A and you want that page A or page B opened in another tab should get that update then redux can let you achieve that. Context and props passing are not useful in this case.
https://redux.js.org/faq/general#when-should-i-use-redux
Redux is most useful when in cases when:
You have large amounts of application state that are needed in many places in the app
The app state is updated frequently
The logic to update that state may be complex
The app has a medium or large-sized codebase, and might be worked on by many people
You need to see how that state is being updated over time
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.
Flux design pattern has been such help in simplifying my web application. However I ended up directly calling web APIs for certain situations simply because Flux seemed such overkill for the job. I was wondering how others might have solved such problem in a Flux way.
As the diagram suggests, we created the Action via the Action Creator for all Web API calls. I will give an example scenario. Let's say there are 3 components that are interested in User Store changes at the moment. User clicks one of them to load a list of user's hobbies from the back-end. But I only want only that one particular UI component to display the list of hobbies due to the user's action. The other 2 components won't change at all. Traditionally this would have been a simple couple lines asynch call with a callback. If you are to religiously follow Flux for this,
You create an action via Action Creator with a specific reference ID
Fetch data via Web API
Upon receiving data, action is created using the Action Creator
User store listens to this result arriving via the action
Update the store
Fire store updated event, all 3 components react to that and check if that was for mine using the reference ID
then finally render with the data fetched in that 1 UI component
My app having many small parts that load data dynamically like this per user action, I decided to use Flux for things that many components have to share states with since the stores act as centralized state provider. How do you guys use Flux to do simple data fetches such as the one mentioned above?
There are couple of ways to solve this.
Let all the components receive the update and the component decide whether to update or ignore the update.
Split up your store and subscribe only to those which are need in the component. This approach can get messy with stores getting dependent on each other and simultaneous dispatch problem.
If you haven't used any flux library , redux is highly recommended. It solves this by allowing the components to subscribe to part of state(store) tree.
I Have react app which contains many pages. For each page i added store. I using params from url for example photoId then passing to actioncreator which call service and then dispatching data to store. In page component i have store listener. Store imiting change and listener calling render for new state.
Store and action creator relates to this page only. How to create pages more simple?
Thank you!
The Flux model (using actions, dispatcher, and stores) works well for larger apps where a data fetch may affect many components and pages. If you think your app will grow then it may be worth the extra verbosity. If you're keeping your app small then composing plain React components is a great way to keep things simple and there is nothing wrong with doing it as long as you separate the data operations from the display, the way your linked example showed. Have fun!