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!
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 months ago.
Improve this question
Are there reasons why one would use both redux and useContext in their APP?
If so, what are they? Can you give examples of when to use either?
It is not suggested to use both redux and context api in single app.
Both context and Redux has advantages while developing the application in their own way. Depending upon the use case you need to decide whether to go with context or redux.
Context
If the application is smaller and you need to have a centralized store
that needs to store and access the datas. You can use context api. But the code
will not be that organised when compared to redux.
The below reference will provide you an outline on creating the context,
https://reactjs.org/docs/context.html#reactcreatecontext
The below will provide you the reference on using the context,
https://reactjs.org/docs/hooks-reference.html#usecontext
Redux
If the application you are developing is bigger or enterprise level
application. You can go with redux which provides more optimized code
structure compared to context api.
If you want to integrate and use redux. Use reduxtoolkit for simple and elegant usage.
Use the below link for reference,
https://redux-toolkit.js.org/introduction/getting-started
Both are excellent tools for their own specific niche, Redux is overkill just to pass data from parent to child & Context API truly shines in this case. When you have a lot of dynamic data Redux got your back!
To answer your question Yes you can use them both in the same react app but there is no reason to do so and it is recommended to use one of them depending on your needs
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 2 years ago.
Improve this question
I am trying to display a bunch of statistical information in a React page. I am using MongoDb, Express.js, React and Redux. Considering that I have to display a bunch of statistical information, I can do those in two ways. The first way is by making queries to the database for each one of the statistical information that I need and store them on Redux state, or I can make few queries and from there I can derive other statistical information. Which is the best way to do that?
If I follow the first way, I end up with a complex Redux state and not reusing some of the information provided by other queries. If I follow the second way I end up deriving complex information in the client side.
Which is the preferred way?
You need to show us some examples related to your data. What information are you going to show? How related those pieces of information between them? How complex those queries? How much time does it take to show a piece of information to a user? How fast your API results? Do you want to show those pieces of information asynchronous or sync?
To define your structure you need to make sure about your user story. So it depends on Currently, users are expecting to see information separately (async) with some content loader and do some actions in the same way. So it is good to divide your components into small pieces. So each big component (organism) makes API calls and shows information to a user with small components.
When it comes to state management if pieces of information are dependent on each other it is good to use Redux and define reducers actions etc. so you can keep track of your state in a bigger scope. If those pieces of information only need and auth key or user data, you can use react hooks in your organisms to make your API calls that get auth information from ContextProviders.
If you are capable of creating microservices (or if you have them), I would recommend you to try to react hooks. If you have different API's which shows different info use redux.
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.
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.