My website has 3 pages, e.g. www.example.com.au/invoices, www.example.com.au/customers and www.example.com.au/suppliers.
In this case, how to organize the global Redux state, I mean the structure.
should it look like below?
state = {
invoices: {
//invoices related data
},
customers: {
//customers related data
},
suppliers: {
//suppliers related data
}
}
That looks a good start. I find it's a good idea to try and keep the state as normalized as possible - try thinking about it as a relational database.
This is a great article:
https://medium.com/javascript-scene/10-tips-for-better-redux-architecture-69250425af44#.9c678jwib
as is
http://redux.js.org/docs/recipes/reducers/NormalizingStateShape.html
state = {
invoices: {
//invoices related data
},
customers: {
//customers related data
},
suppliers: {
//suppliers related data
}
}
this looks good.
If you're on invoices page and if you won't be accessing state.suppliers or state.customers, then you don't need to combineReducers all of them together.
You can lazy load reducers (dynamically and use store.replaceReducer to inject them into store). This saves you some bytes ;)
Some tips:
Separate business logic from views (components) and reducers.
Identify core reducers (those which are needed throughout the app) and others. Only create initial store with core reducers.
Split reducers and action creators into different files and lazy load reducers as required.
It is up to you on how to store. But a more convenient way to do is, having separate file for each of them and combine them as a single store.
i.e, your folder structure looks some what like this,
reducers/
|---- index.js
|---- customers.js
|---- invoices.js
|---- suppliers.js
Inside each of customers.js, invoices.js and suppliers.js, write their own reducers in each of them and combine them to a single large store in the index.js file using combineReducers() method from redux
Basically the flow is,
Write separate small-small reducers.
Import all the reducers in a single file(index.js).
Using combineReducers() combine them into a single large reducer and export it to store.
Hope it helps! :)
Related
My tech lead has given me a challenge to engineer a way only load only parts of the store that is needed for the UI that is loaded in a single page application. This is a big data application so that is why this is important. The idea is that entire store does not need to be loaded because the amount of data.
I implemented similar recently and found How to dynamically load reducers for code splitting in a Redux application? which features a link to http://nicolasgallagher.com/redux-modules-and-code-splitting/ where Nicolas describes how they did it at Twitter.
TL;DR You want lazy-loaded reducers for this. The approach described there is to have a class as a "reducer-registry". You register your reducer/s when you need to use it/them. The registry then calls a listener with a combined reducer which includes all the currently registered reducers. You attach a listener to the registry which calls replaceReducer on your store to update it's reducer.
My implementation is here.. https://github.com/lecstor/redux-helpers/blob/master/src/reducer-registry.ts
In your mapStateToProps you can select the keys of the redux store you need in your component.
For eg.
function mapStateToProps(state) {
const { key1, key2 } = state;
const {subKey, ...restKeys} = key1;
return {
remainder: ...restKeys,
subKey,
key2,
};
}
Now this data can be accessed in the component with this.props.remainder or this.props.subKey or this.props.key2
At the moment I'm creating actions and then a reducer to handle different parts of my app... the different domains.
My app lists classes and pupils.
Currently I have an action that the app has loaded so that I know when to remove the loading spinner, I have actions for classes and pupils. My problem is that I find I need to execute several actions in a row and am not sure if this is a valid way to use redux.
Here is an example function that dispatches several actions after the data is loaded:
/**
* Callback used by readAppData.
*
* #param object ioResult An object: {success: boolean, errorObj?: object, data?: string}
*/
dataLoaded(ioResult: Object) {
if (ioResult.success === true) {
this.props.dispatch(appActions.appHasLoaded());
if (ioResult.data !== '') {
const jsonData = JSON.parse(ioResult.data);
this.props.dispatch(classActions.replaceClasses(jsonData.classes));
this.props.dispatch(pupilActions.replacePupils(jsonData.pupils));
}
} else if (ioResult.errorObj.code === 'ENOENT') { // File doesn't exist.
writeAppData('', this.dataSaved);
} else { // Some other error.
this.props.dispatch(appActions.appHasErrored());
}
}
I was thinking about putting the jsonData.classes and jsonData.pupils into the appActions.appHasLoaded() call and just have a new case for APP_HAS_LOADED in my classes and pupils reducers.
Is this a better approach? To reduce it down to one action? Having separate actions makes it easy to see what is happening... maybe in 6 months time I will have to look through my code to work out exactly what happens on APP_HAS_LOADED if I use it in other reducers. Also the data that is loaded on app start is going to expand beyond just classes and pupils so if I don't combine the calls there could soon be many more dispatches to make - maybe I can store the data in separate files and load each one one at a time which would also fix my problem of having to call mutiple actions in a row.
Is it OK to call dispatch multiple times?
Yes, you can.
From Redux creator Dan Abramov:
Many reducers may handle one action. One reducer may handle many actions.
Referenced in Redux Docs
also, there is a conversation on github about this.
Consider this:
I have an application that is going to end up being pretty large. It is a dashboard which will give you access to various utilities, one of which being a todo app.
If I was just going to build just a todo app, then my state object would look like so:
{ todos:[], completed:false, todoInput:''};
todoInput would be tied to a form field and and upon clicking add, it would alter the todos array and toggle the completed field. So my combineReducers() function would look like this.
combineReducers({todos,completed,todoInput});
This would make sense because all the state is relevant to the todo App because there is JUST a todo app.
Now because I am building a much more complicated application which also has a todo app, this is how my state would potentially look like:
{
otherState:'',evenMoreState:[]',evenMore:{},
todo:{ todos:[], completed:false, todoInput:''}
}
As you can see I have separated todos into a separate object now, so it is encapsulated and more organised. So I have 2 questions.
1) Is this a good idea? It seems like the logical move because my application will grow in size and I don't want all the pieces of state floating around as properties to the main state object. Have I gone about this correctly?
2) My combine reducers (as far as I know) cannot take a nested object. So it will now look like this.
combineReducers({ otherState,evenMoreState,evenMore,todo})
so now my reducer compositions will have to be done inside the reducer which handles the todo state. Is there a better/different way to do this?
Thanks
Yes, you're absolutely on the right track. It's also worth noting that you can use combineReducers multiple times, such as:
const rootReducer = combineReducers({
otherState : otherStateReducer,
todos : combineReducers({
todos : todosReducer,
completed : todosCompletedReducer,
todoInput : todoInputReducer
})
The overall todos section could be be defined separately, and imported and referenced in the top-level combineReducers call if desired.
});
You may want to read through the Redux docs section on "Structuring Reducers" for more information on ways to organize reducer logic, as well as the Redux FAQ on organizing nested state. In addition, the Redux Techniques and Redux Architecture sections of my React/Redux links list have links to a variety of articles about building real-world Redux applications.
I want to ask the community about an ideological problem.
Lets imagine todo-list on react/redux, you have single state where todoItems array is served. But now lets imagine I want to have few components on the page that are render todoItems with different UI. And I need to update each these components on CRUD of todoItems. What is your architectural approach of this issue? Don't forget we have a large database and we can get todoItems with pagination only.
Update:
Lets make it clear. When we implement redux life cycle with this UI we have 2 options:
1) Serve one array of todoItems into singleton redux state object.
Advantages: all our components will updates by object changing.
Problems: we can't get ALL data from our database, but have to show different paginated/filtered data, so we can't implement pagination/filtering on frontend-side. We have a few different components and the have to render different objects collection. So it doesn't fit.
2) We can use different keys into our global redux state.
Advantages: we can independently get data for each component
Problems: other components will not feel when object changing in one of them. In this case we have to write custom code.
I just want to know maybe I'm missing something and we have other option or maybe someone have good architectural approach to this problem.
I bet your complications come from the point of view which unfortunately quite common among redux community: trying to keep redux shape as close to UI shape as possible.
Try no to think about redux state as a substitute for the Component states. What redux should know about is actual todos only (id, title, date of creation, etc.). Let Component-specific data like pagination stuff live in Components state. When user goes to next page in one of the Components what should be updated is this Component state (pageNumber, from, to, amount, etc.). redux should be updated only in case necessary todos are missing.
The useful analogy is to thinking about your redux as good old SQL-database: redux store state is data itself, selectors and actions are queries and stored procedures, React Components are views with selected data.
Update: Ok, seems like what you are looking for is state normalization. Separate todos details from the lists of ids. This way updates of todo fields will be sensed by all the Components. On the other hand you'll be able to keep separate collections of todos in different Components. Namely make state look like this:
{
funnyTodos: [ 'id1', 'id2' ],
boringTodos: [ 'id3', 'id4' ],
recentlyDoneTodos: [ 'id1' ],
todos: {
id1: { name: .... },
id2: { name: .... },
id3: { name: .... },
id4: { name: .... },
}
}
Implementing pagination in this case is just a matter of getting list of todos ids for the next page from back-end and then loading missing todos for given ids.
I am currently developing an analytics dashboard in React/Redux that is similar to this:
Users of the dashboard will be able to add and remove tiles to customise the dashboard to their own needs, and the configuration of the tiles is stored and retrieved in an API.
The storing of the data for the configuration of tiles seems to fit well with the global state model:
On load, the dashboard component dispatches a 'loadTiles' action
The action fetches the tiles data and passes it to the 'tiles' reducer
From there it goes into the store/global state.
In mapStateToProps, the data is accessed from state.app.tiles
However, a problem arises when populating the data for each tile. The number of tiles and nature of the data is dynamic, so reducers can't be set up ahead of time.
This could be solved by each component managing their own state (as in pure/traditional React using componentWillMount etc) but this will violate some of the architectural principals that have been laid out for the rest of the project (ideally everything is to be managed in global state).
The only way I can see of storing the data is global state would be to have an analytics with a dynamic array of the various data sets, which sounds messy to me.
Is local component state the best solution here? or can this be done in global state cleanly? Are there any example of Redux using queries that are dynamically specified?
One thing you can do is the usage of an ID for each Tile. So your state could look like that:
{
tiles: {
tile1: {},
…
tile100: {}
}
}
Than, in the mapStateToProps() function you can use own props like so:
function mapStateToProps(state, ownProps) {
//test if it exists
if (state.tiles[ownProps.id]) {
return { tileData: state.tiles[ownProps.id] }
}
else
{
return { tileData: <default state> }
}
}
The important part is to hand over a unique ID for each tile, when those are created, one way could be that:
<Tile id={uuid()} other="stuff" />
whereby the uuid() method can be created as described here
I once had an similar issue, have a look here if you want to see a more complicated solution using an higher order component (its my own unaccepted answer). All in all, the above is the simplest solution IMHO.