The question of the application architecture.
Suppose there are a lot of components (look at the picture) (mains) on a page.
What better use to switch the main children's components (active / not active)?
And pages (1, 2, 3, next)?
Can I use react-router for both tasks?
P.S.: I use ReactJS for rendering
I would not use react-router for results filtering. Since you are using Redux, you can split your reducers in to main sections and keep the state of active/not active as well as current page per section all in one store.
I think you should not need use react-router in this page.
You should control the state (active/not active,1,2,3,next) by reducer,just like below:
case NEXT_PAGE:
return {...state, list:[{active:0, ...others},{active:1, ...others},...], page: 1};
And you can get the data that you want to display on this page from props.
mapStateToProps(state) {
return {
list: state.xxx.list,
currentPage: state.xxx.page
totalPage: state.xxx.total
}
}
The key is the use case. If you have following use cases:
A user to copy paste the link of filtered result and page and share with others
A user a bookmark a filtered result page, and come back to it later.
Then definitely I would say use the react router.
You can have a route like this:
<Route path="main/:status/:page" component={Main}/>
Then the params object would be injected as props to your Main component.
If user click on the buttons, you would use the push from react-router to change the route or the simply Link from react router. (instead of using dispatch action with redux or using this.setState if you stored as local state).
I think it isn't more difficult than storing it with the redux or local state, with the additional advantage of more use cases above.
If you want a solid and scalable application architecture I'd suggest using a starterkit.
The wiki of a good starter kit will describe the chosen design principles.
One of my favourite starter kits to combine with a headless backend is React Redux starter kit.
So you want to do routing with your Redux app. You can use it with react-router-dom. react-redux will be the source of truth for your data and react-router-dom will be the source of truth for your URL.
Handle data with state management using react-redux (create actions, reducers ...) and navigation with react-router-dom.
Usage with React Router
Related
We will be doing our first project using React.
It will not be a Single Page App, but a Multiple Page App.
What I'm trying to figure out at the moment is : what's the difference between a component and an app.
If I only use components, can I still use Redux to have some state management on the current page ? Or do I need an app for this ?
Thanks for the information you can bring !
THoma
There is no special object called "React App". React Components build an "React App" by coming together.
But React Components are formed like tree structure. That means each component have a parent component so you can create a React Component that named "App" and can put another components inside it.
You don't need redux for state management in React Components.
I hope the answers have helped.
Your app may contains a single component and still it will be a react App. If you are using multiple components in a page you can still use react-redux. Redux is basically a container for your states and let suppose you need some state from one component to be consumed in another, Redux provide you a mechanism to make the communication efficient and predictable.
You can also look at the React Context APIs as an alternate to Redux.
An app is simply a component that holds the root of the work you are trying to do. For example an App may have the navigation menu, testimonials, adverts, content, login avitar etc.
If you are making a single App per page (For example a testimonial) then you would still have a SPA. For example, adding testimonials, searching, editing.
You should only use Redux if you are using a SPA with lots of different parts with data in common. If you are making a one-app-per-page and there is no cross over in data then you can simply using Reacts State/Props to hold your data.
Redux is good, but it forces you into a complex path your should try to avoid. If you find yourself wanting data from different domains (customers address and a list of testimonials) then you should use Redux.
If this is a new applications (green) then I strongly recommend you build the whole thing within a SPA using React-Router to control components. you can use frameworks like Next.JS to ensure the site remains small in size (dynamically loading script only when required).
I have read the official Redux documentation regarding React Router and investigated react-router-redux, redux-router and redux-little-router. I also agree with the rational for redux-little-router: React Router has strong architecture consequences on a React app, and they somehow conflict with Redux.
My feeling about routing is that it has too much importance in the React+Redux ecosystem, whereas it should be treated as a second class citizen. When designing a single page app, we often don't need URLs at all. We still support them to preserve the Web experience (SEO, bookmarking...), but we certainly don't want them to drive the app structure.
What I am thinking of:
External navigation: a route-to-state mapping, with the classic reduced action mechanism. In other words, navigation triggers an action that is dispatched and processed by a custom reducer (with just some help for route mapping and parsing). Once the state is updated, this is React as usual. In particular, there is no mapping between routes and React components, unlike what React Router's Route does and a bit like redux-little-router does.
In app navigation: the current URL is derived from the state, a bit like the view. A kind of renderURL function a Redux middleware is aware of. If a state update generates no change in the URL, well, nothing happens. But if the URL is now different, the middleware reflects the change by pushing it to the history.
With this approach, there is no more Link component. There are only regular Redux actions and a middleware to take care of the navigation as a side effect. Actually, this solution does for navigation what React does for the DOM: a (super-straightforward) URL reconciliation, with the state as the single source of truth.
To illustrate this, consider the Redux Todo list example:
When visiting /SHOW_ALL, an action containing the URL is dispatched. A regular, navigation-dedicated reducer sets visibilityFilter to VisibilityFilters.SHOW_ALL in the state, possibly with some route mapping/parsing helpers. As an alternative, the navigation action could be turned into a SET_VISIBILITY_FILTER action, which is then dispatched and reduced as usual.
A fancy renderURL function is registered at store creation as part of a middleware. It returns "/" + state.visibilityFilter. Again, some route management helpers would be welcome for real life apps.
Now there is no change in the original Todo app. We only add some new code to support a new feature.
The problem is: I can't find anything that support this vision. No article, no react-redux-something package. As a React beginner, either I am a genius or there is something I don't get. Since the later is the most likely (to my uttermost dismay), I would appreciate:
Feedback regarding the "Redux-driven React routing", or whatever it should be named. How is it flawed?
Hints about how I should consider Redux and routing, like relevant articles.
I got a question while working with React-redux/redux-form.
I build SPA using React-Router.
React-router uses redux as you know.
What I want to know is the render-flow when you change redux-form-field.
1. user inputs text in redux form field
2. redux form updates redux store
3. Then, all components connected with store are re-rendered.
(It means that all page is refreshed in my case, because I use react-router)
React uses virtual-dom, so twinkles can't be notified.
I'm sorry that I can't express my thinking due to lack of English.
I look forward to hearing your opinions
I have a React app, using Redux & Redux Sagas.
Currently I have a fairly standard search page as in :
User enters value via form input, magic happens behind the scenes, an api is consumed and my redux store is populated with the results.
These results are then surfaced via the view layer.
Using React Router 4, if I then navigate away to another page, on returning to the search page, my previous results are still shown. I guess this is expected as my redux state still contains this data.
My Questions is should this state be cleared on navigate away? I am very new to Redux / React / React Router and am trying to understand if I have implemented this correctly or in fact unless I instruct the store to clear that state, it should persist.
tl:dr
Should a redux store be cleared if I navigate away from the page or is it ok to leave that data on the view?
Using React Router 4, if I then navigate away to another page, on
returning to the search page, my previous results are still shown
In React & Redux epoch you web application is SPA, and tools like isomorphic react-router-dom helps with this task, including seamless SSR support for URL router.
Of course, you can use react-router-redux instead, and in this case navigation to different pages will appear as actions, so them can be catched in saga, and then load new initialstate for redux store.
Library and example can be found here: https://github.com/jfairbank/redux-saga-router
guys. When I go through the documentation of redux-router, I just cannot understand why do we need it?
Here is what the documentation is trying to explain:
React Router is a fantastic routing library, but one downside is that
it abstracts away a very crucial piece of application state — the
current route! This abstraction is super useful for route matching and
rendering, but the API for interacting with the router to 1) trigger
transitions and 2) react to state changes within the component
lifecycle leaves something to be desired.
It turns out we already solved these problems with Flux (and Redux):
We use action creators to trigger state changes, and we use
higher-order components to subscribe to state changes.
This library allows you to keep your router state inside your Redux
store. So getting the current pathname, query, and params is as easy
as selecting any other part of your application state.
As far as I can understand, it is trying to say redux router can keep router state inside redux store so that we can get route info more conveniently.
But within react-router, I can also easily do it.
Like path="messages/:id", I can use this.props.params.id to get the params.
Can someone explain in what scenario redux-router bring its benefit?
Redux (and in general, the flux pattern) is all about having the entire application state stored in one central place. This has the benefit of easier debugging and makes it easier to implement certain features.
If you've ever used the redux-devtools in a react app with react-router, you'll notice that its only of limited use, because you can't replay the entire lifecycle of the application. When the user changes routes, that's not recorded in the redux store. Redux Router keeps the route state in the store.
You could use this for debugging, you could serialise the entire store history and log it elsewhere to replay user sessions. You could hook into it to implement full undo, or log analytics events.
redux-simple-router is a library which could help you understand how to use react router in a redux application.
It is a very simple library stores the URL in redux state and keeps it in sync with any react-router changes.
redux-simple-router compared to redux-router is:
Much smaller and simpler. You don't need to learn another library on top of everything else.
Encourages direct access of react-router APIs. Need server-side rendering, or something else advanced? Just read react-router's docs.
Only stores the current URL and state, whereas redux-router stores the entire location object from react-router.
Follow one of the these 2 examples to get up and running:
redux-simple-router-example
redux-frontend-boilerplate