Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I need to implement a SPA whose components are going to interact with their local state and are minimum the cases in which these state is going to be nedded by other components. For example: the employee component contains state about an employee that only will be shared with the employee's component children but not from other different component in the site. Until now my idea is to create 'stores' in the parent component (Employee for example) implemented with hooks and Context Api, for achieving max development speed and clarity in code. What do you think?
This is ultimately subjective, and it sounds like you're already leaning towards using the Context API. We made a similar decision on our current project; the amount of data that needs to be shared across the application is quite small, so adding the additional code, dependencies and file structures for Redux did not seem worth it.
But if you are using Context, make sure you have thoroughly plotted out the data flow of all parts of your application, as it's easy to overlook something and run into a situation where getting the data outside of a particular module can become very difficult. Also consider its size. If it's a large application, the benefits of centralizing your state changes for easy testing and debugging are not negligible, and Redux can also help boost performance by automatically memoizing connected components.
Again, this is ultimately opinion-based, but I think it's a concrete and common enough concern with React apps that it bears some discussion, though this might end up being closed.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I am a student trying to learn web development along with the ReactJs library. But I have a huge struggle selecting between React Context and Redux state management. I have never worked on real-time huge projects. So everyone is suggesting I should go with React context. Even my friend who is working on a real-time project in the IT field is using React Context instead of Redux in their project. So he suggests I should just stick with React Context. But I think Redux was there even before React context and is really suitable for huge projects. So a lot of the older projects may be using Redux. But Redux is really hard compared to React Context.
Can anyone give me a suggestion on whether I should just stick with React Context or I should learn Redux?
Depends on the scope of your project. There can be some problems with React Context with high frequency updates, but if it is mostly low frequency ( theme changes, authentication ) then just use React Context because it's simply better if you plan to use the data only in ReactJS and it's additional packages
Actually it is a good idea to know both. I would start with React context which is much smaller and easier to grasp, and out of the box.
Then you can switch to redux - and do some work with it. You will learn both since both are not that difficult.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Working on my personal project and want to use hooks inside.
I've seen a global state implementation using hooks and my question is:
which one is better to use? Redux vs use-global-hook ?
It seems super easy to manage with the global hook, but what about performance? What are advantages, disadvantages over redux?
I've built apps using both methods and didn't notice any difference in performance; although Redux bindings are supposed to prevent unnecessary renders, I'm not sure how much of an impact this would make on the final performance of the app. Furthermore, Redux offers a time travelling debugger as well as a middleware API. The following article discusses this topic in more depth:
https://frontarm.com/james-k-nelson/when-context-replaces-redux/
If you're planning to build a sizeable project of any complexity, Redux is going to provide a feature-rich store and state management via a unidirectional flow, actions, reducers, middleware, asynchronous thunks, etc. Redux is a mature pattern (based on Flux) with a great deal of "road-testing" and a thriving community. Also with Redux you'll be able to use fully stateful React class components and leverage the component lifecycle.
Global state hooks seem like a great upcoming solution for simpler components and problems where you want to keep your components functional and pure. I don't see any signs the performance would be any different, the only way to tell would be via empirical profiling.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have a big application with different features. What I want to know exactly is that should I overwrite all setState() functions that I have used with redux ? or in some cases I have to use redux instead ?
I mean is it bad to use redux for a simple setSate action ?
It is ultimately up to you, but Redux is pitched as "global state management", which I interpret as "the state of the app".
Generally, the way I would build my state out would be to have Redux handle the data of logical/business structures (e.g. data coming from APIs), and as such I would pass in props to the components that use said data.
Once inside the component, I would use the component state to allow the component to manage its own logic for the things that it is concerned about, such as logic needed to conditionally render things or optimistic updates.
Some have even completely removed Redux from their applications with the advent of GraphQL + Apollo, allowing them to have server-side computations for what the UI would traditionally display (e.g. providing a boolean like hasComment) so that the UI doesn't have to perform that computation (backend is usually faster at these computations, too) and simply state {hasComment && <Comment />}. Another advantage of this approach is that other UIs could use hasComment without needing to implement duplicate logic.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
My workplace has recently switched to developing 12 factor apps. Along with this we have been encouraged to adopt new tools and techniques. I'm trying to choose the view engine for a dynamic frontend. I'm contemplating ReactJS. However, as I'm fairly green, I'm concerned using ReactJS state breaks the stateless requirement of 12 factor apps?
React state refers to components, components hold the state they need to draw themselves. Keep in mind that the render method of a component needs to be able to draw it at any point, and for that it needs to know the current state of the component. A good example is a input field, a component that holds one input field needs to hold the value of that input field as current state to be able to redraw the field at any point of time.
Another common topics in react apps is application state kept in stores, however this is not what you would think as well. This refers to the state of all the components in the application, and is usually gathered/formed and changed from 2 sources, either responses from the server, or user interaction with components. Keep in mind that this state is meant to persist for one session, and it doesn't make the application stateful.
In summary I would say it is quite safe to use React to build a 12 factor app, we are using React to do the same for a cloud based ERP system, and so far it is going great!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
From a maintenance/architecture/performance perspective, when writing a react application, is it better to put all components in a super/parent component and bind it once to a page, or to have multiple mount nodes on the page for each piece of functionality?
My current approach is to have multiple mount nodes on the page so I can have a more flexible design. Basically like a bunch of 'component boxes' in different parts of the page, that way I can easily move an entire box to another part of the page and everything still works the same without being dependent on each other.
Is there a "best practice" for this (in terms of future maintenance), or has react not been around long enough to establish such a thing?
The most common practice I've seen is a single mount point for a the main react render. This has a few advantages
Keeps the HTML minimal and simple, this reduces potential confusion about what's handled by the DOM/HTML and what's handled by React/JSX.
Reduces the interface boundary between the root HTML and React. Fewer places where props need to be passed from outside React.
Simplifies the reasoning about what happens when. For example it can sometimes be tricky to determine when React applications are done rendering. Having multiple render operations makes this more difficult.