So I had a design pattern question I guess for React SPA's (single page application). Right now, we're using redux state to track which "page" the user is on. Depending on that page, we're rendering different html/css using conditionals (switch/ifelse).
I feel like it's a waste to create new components for something that isn't changing that much and while the variance in html/css per component varies ... I'm wondering if theres a better or "right" way to do this?
edit: After speaking with a fellow engineer, I think it makes sense to just conditionally render separate components. Although the abstraction to me seems kind of overkill it will probably be more maintainable in the long run.
You can use react-router and react-router-redux.
https://github.com/ReactTraining/react-router
https://github.com/ReactTraining/react-router/tree/master/packages/react-router-redux
It can be connected with React and Redux. It offers an action creator (push) so you can dispatch router-like actions.
Related
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 am trying to create a blog application and I am a bit confused on the data flow patterns of React.
Should I be trying to use something like Redux to store all of my posts after fetching the posts? Do I use local storage?
How do I then tell a component to render the 'expanded' version of the post? Is it better to re-use a 'post' component or should I just create two seperate components, one for the title and one for the full post?
I know it's two questions in one, but they kind of go together. Thanks in advance
Here's what I've found out about these topics after 6 months into my self-taught React journey.
In my opinion, React built-in features are more than enough to handle state for a small to medium applications (especially if you're working alone as a single developer).
If you turn to Redux right away, you'll have to learn this whole new pattern of handling state in a single immutable store and how to connect your components to it.
Since you will be most likely fetching data asynchronously, you'll need a helper library to work async on Redux: redux-thunk or redux-saga.
So right from the start, you'll have to add:
redux
react-redux
redux-thunk OR redux-saga
That is a lot of documentation to digest. It's perfectly doable, but I couldn't agree more with this quote:
don't solve problems that you don't have
It will be hard to learn those tools, since you've never faced the problems that they solve. Problems that you don't encounter just yet when you're starting to learn React.
Read this (from Redux creator):
https://medium.com/#dan_abramov/you-might-not-need-redux-be46360cf367
So, my recommendation to you:
Learn basic React (with classes):
https://reactjs.org/docs/getting-started.html
Then learn React Hooks (and you can basically forget about class components):
https://reactjs.org/docs/hooks-intro.html
Build your project using only React at first. And see how it goes. Then you can read more about Redux and what it does, and will be able to make a better choice on if you really need it or not.
From what you've told us about your project:
Keep a state for all your posts in a component high in the tree. Maybe inside the <App/> component itself.
Build your functions to fetch and update post data and update the state with the response.
Render how many components as you wish. Displaying full info about the post inside a BlogPostComponent or simplified version inside a BlogPostThumbnailCard with just the thumbnail and the title, for example.
If you want to be ready for the next versions of React and have a shorter code, you should try the hooks and avoid Classes
https://reactjs.org/docs/hooks-intro.html
You can organize your code as you want, but this is more interesting to have scalability with your components and reuse them with different properties
I've just setup my Redux store in React native app.
I moved to initialize React navigation for my project, i though that, as long as i'm using Redux to manage my app state, then the default option is that redux also is taking care of Navigation, and it should be hooked up to Redux, i opened React navigation docs, it says literally:
"Think twice before you consider doing this, there is an incredibly good chance that you do not need to do t his!"
So, is it a good practice to manage navigation with Redux, or just implement basic navigation the normal way (outside Redux) ?
Thanks in advance.
React Navigation manages its own state internally (using its own redux store I think...). There's no real need to connect react-navigation state to your own app's redux store since they expose API to do everything you might need to even without the navigation prop. Also it looks like they're dropping support for redux integration in the next version so beware of deprecation.
This is one of those cases where people may introduce unnecessary complexity and research into the project just to be happy about how "neat" the code runs even when it doesn't offer any real deliverable.
I am new to React so please excuse me if this is a noob question but I really could not find the answer in the DOCs or elsewhere.
Let's say I have two buttons with a counter that share the state but are far away from each other in terms of the placement in the UI.
The documentation says the common owner component for both buttons should own the state. It makes sense if the components are next to each other like in the example but what if my buttons are each part of a different UI group and are far away in terms of nesting? My state holder would be the root of the document and I would have to pass a handler function down through many layers. And what if I need to add new component somewhere else that also needs to know the state? Would I have to modify all the parent components in the way to pass the state down? That is tremendously impractical.
Without React I would have some global Subscribe/Publish pattern like jQuery Observer and all UI elements could subscribe/publish to it regardless of their nesting position.
How does React solve this?
Related question: If I need to load/save the state to DB, how do I pass a reference of the controller (or Whatever) to each React component that stores the state?
1 for global state you may use REDUX
Redux is a predictable state container for JavaScript apps
for connect/subscribe component with that state ,you should use react-redux
If components are far away in terms of nesting, you may connect/subscribe them to redux store, and take only neccessary part of state. They will update if only neccessary part is changed.
article that explains how you can do your case
to learn how to use redux you can watch this videos from creator of redux (Dan Abramov)
1.getting-started-with-redux
2.building-react-applications-with-idiomatic-redux
3.I definitely recommend to you discordapp rectiflux channel. because you allways can ask any question online.(there you can find contributors of that tools)
2 alternative way that less verbose then redux is MobX
MobX is a battle tested library that makes state management simple and scalable by transparently applying functional reactive programming (TFRP). The philosophy behind MobX is very simple:
Anything that can be derived from the application state, should be derived. Automatically.
I suggest to look at the Flux stores. In short, stores are like model in your application. You can listen to change (subscribe) and also modify their properties (publish). You can see how it was done in example app.
A better option is to go with Redux.
Redux is enabling use cases like yours in a way simpler fashion :)
It will help you with all the state and make your life much easier.
Some good resources for learning:
The Redux Website
Video courses from Dan Abramov, the creator [Free]
Awesome course on Udemy [Not free]
Building Applications with React and Redux in ES6
And finally take a look at this youtube series [Free]
Managing state in the middle layers of your app should be avoided where possible. This data belongs in a store, which holds the global state of the app. Then each component accesses the state via its props.
The naïve approach to get the data down to the component is to pass the store through all the layers of your app "manually", i.e. through props.
Smarter alternatives exist, which use connected components, that access the global state through the context (as opposed to the props). Typically, the presentational component (your button component) is wrapped in a container component that handles this connection to the store, then passes the data in via props.
There are numerous frameworks that facilitate this process, links to which are already provided in the other answers.
If you are trying to share simple states, try this ( I am the author): react-provide-state
Otherwise I will recommend Redux. It has become the most popular tool for managing application states.
In the applications being working on, we use Redux to manage the main application states and almost all other states. But we use 'react-provide-state' for simple, UI only states like Modal, Checkbox states.
According to the react-router documentation doing a browserHistory.push() inside of a nested react component is the accepted way to change the current route in a react-router app:
https://github.com/rackt/react-router/blob/latest/upgrade-guides/v2.0.0.md#navigating-inside-deeply-nested-components
If a route change is considered a change of state, which I'm not sure whether it is or not hence why I'm asking, would't this be anti-flux?
If a route change isn't considered a change of state, then I guess the documented way is correct.
Can someone weigh in on this?
"State" is kind of an arbitrary term. Ultimately, flux gives you the flexibility to decide where you wan to store state when there are multiple possible places to track it. Some data is managed within its own component, and other data is managed in a flux type store to share with other components. And there are a lot of things that are managed by the browser that you wouldn't keep in your application state--for example, currently selected input box. You could keep them in your flux state if you wanted, or you could keep them in your component state. Or you could let the browser handle that and not worry about it. It all depends on how you want to make these data available across your application.
The URL location is an example of a state which can be maintained by the browser outside of the flux or component state trees. You can, however include it in your store and bind to it if you feel you need it in your application in a way that would be useful. react-router-redux specifically is an example of an implementation that brings the location bar in to the flux state for redux applications.
At the end of the day, however, its up to you to determine if having that information available in your flux state is useful or not. Pedantically speaking, yes, you should have all of your data in flux to have the most pure flux implementation, but that's not really what you should be optimizing for.
The documentation for react-router is perfectly correct to use in a flux application, but if you're using something like redux, it's at least nice to have a real react-router integration so that it doesn't become something of an exception on how your application deals with state.