I have a application which allows users to add components (widgets) which means they can set certain filtering on that widget specifically or use a global filter which is set application wide. I have two questions:
How do I create the state for these dynamic components? I can't wrap my head around how I would even start to think about this so its more a little bit of direction is required.
Allowing components to use either the global filter state or isolate the widget and set filtering for that component specifically.
To give an example for context, the dynamic widgets are used in a dashboard and at the moment they are static tables, graphs etc which pull data from 1/2 endpoints and have a static state structure, and filtering is in the from on a date picker which allows you to specify a range to return data for. The next iteration requires the dashboard to have widgets which are added by the user and each widget could have its own date picker and pull from a separate endpoint if the user wants that.
Per-component state in the store is an area of open exploration in the Redux community. If you look at the Component State page of my Redux addons catalog, you'll see at least a dozen different libraries which approach the problem in different ways. You should probably be able to use one of them to solve your use case, or at least serve as an inspiration.
Related
I'm new to the web development.
For simplicity, let's assume there's one Textfield for setting the number of products (context information), and one button for submission (components that want to access the context information).
I'd like to log the timestamp and the number of products on the button click.
The button should be able to access the information from Textfield.
What is the best way to achieve this?
(in case it matters, I'm using google tag manager & their datalayer for logging)
The above example is simple, but in the real application, the components are multi-level nested, and the buttons are everywhere.
If I use useContext() or useForm(), it re-renders the components, but I don't really need re-rendering because it's only for logging.
Also it doesn't look good to make the components (e.g., button) dependent on the information they don't actually need for their functionality other than logging.
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
React app Scenario
I have 2 views, UserLister and UserViewer. Both are at different urls. UserLister is a complex table (third party using ag-Grid), with fields, and sort and filtering. UserViewer is an exceedingly complex view with a ton of functionality that takes a while to load up. I want to make it really performant and user friendly to navigate back to UserLister after viewing an individual User. I want it to display all the same sorts and the same information as the user has set up.
To put it another way:
I want the changes that I (or any person) uses on listing page 1 to be available if someone navigates away and then directly back.
Idiomatic way to accomplish this?
How can I accomplish this best in react? is there some function of react-router that would apply here? I would prefer not to have to manage the ?100s? of different states that the UserLister has for sorting/filtering/selecting data manually.
React-router is routing library which manages browser history. You need another tool to save and share state between components. The idea is to make both UserLister and UserViewer to store and access information from some kind of global storage. So each time user enters specific Route data persists.
There are plenty of ways how to do that. Most idiomatic way is to use useReducer hook and then implement "vanilla" Flux architecture (aka unidirectional data flow) in your app.
If you don't want to write all boilerplate by yourself (no judgement here), you can look at Redux, which will do most background work for you.
Redux still requires some good amount of boilerplating. If you don't like it and feel more like streams and observables guy, you can use MobX, which implements reactive programming patterns for state management.
I don't understand why we need Flux with React as React itself let's us maintain the state of the application. Every component has an initial state and the state can be changed by user actions or any other asynchronous JavaScript.
Why is React called as only a view library when it can let's us define state of the application and also update view whenever state changes. This is not what a view does....its what complete MVC does right?
For example: here is an Todo app build only with React and here is an Todo app build with Flux and React.
If we can build the Todo app with React only then why do we need Flux?
In theory you don't need flux.
In small applications you don't need flux for sure.
But what if your application consist of hundreds components? And one of your component is form. User populate this form and you send its content to server. And get response from server with new data.
And assume that this response data and data from form are necessary to other components.
Without flux:
You can move your data to root component and then distribute it down to all components. But if you need to distribute data from many other components too? This makes your application very complex.
with flux:
You move your data to stores, and all components which are interested about this data, can get it from there. You have better control on your application and source data.
I prefer redux (only one store and one source of truth)
edit:
Why is React called as a view library even if it can handle application state?
MVC is a software architectural pattern. It divides a given software application into three interconnected parts (models, views, controllers).
If we think about react and MVC it fit as View. But this is nothing wrong. It doesn't mean that you can use it only for views. It allows you to create normal applications.
But in other hand you can use it as view for other frameworks (for example you can use it with angular).
In other words it is very flexible library for many uses.
You don't NEED Flux the same you don't need MVC. They are both architectures and you can of course build something without using either.
Would you build a non-MVC app in 2016? Probably not, that doesn't mean that people didn't do it in the past.
Flux is awesome! But as most things in the tech industry is not always the right decision, things vary in a project requirement basis.
Probably the biggest selling point of Flux is that it tries to enforce the data flow in one direction, this means that you know for sure where the data is coming from. In a non-flux app the data for a component could be an own property, a property passed down the component tree, a local state variable, a state variable result of calling an API.
With Flux: "where does the data come from?". Answer: from the stores. Redux takes this further and only uses a single store.
Flux has been criticized because you need a lot of boilerplate code but again is a matter of tradeoffs.
At the end is always your call depending on your project needs.
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.