Reputation: 462
I am using Redux-Thunk for Reactjs project. but I am not sure how I have to make a redux store. making the redux store for each web page will be good? now I made the stores for each object (maybe it is related to each database table) such as sites, rooms, sensors...
import { siteConstants } from '../_constants';
function sites(state = {}, action) {
switch (action.type) {
case siteConstants.GETALL_REQUEST:
return {
...state,
get : {
status : 'loading',
data : [],
}
};
case siteConstants.GETALL_SUCCESS:
return {
...state,
get : {
status : 'success',
data : action.sites,
}
};
case siteConstants.GETALL_FAILURE:
return {
...state,
get : {
status : 'failure',
data : [],
error: action.error
}
};
case siteConstants.GET_REQUEST:
return {
...state,
selected_site : {
status : 'loading',
data : [],
}
};
case siteConstants.GET_SUCCESS:
return {
...state,
selected_site : {
status : 'success',
data : action.site,
}
};
case siteConstants.GET_FAILURE:
return {
...state,
selected_site : {
status : 'failure',
data : [],
error: action.error
}
};
case siteConstants.ADDNEW_REQUEST:
return {
...state,
add : {
status : 'adding',
}
};
case siteConstants.ADDNEW_SUCCESS:
return {
...state,
add : {
status : 'success',
},
get : {
...state.get,
data : [
...state.get.data,
{
_id : action.site._id,
name : action.site.name,
description : action.site.description,
vectorMapUrl : action.site.vectorMapUrl,
}
]
}
};
case siteConstants.ADDNEW_FAILURE:
return {
...state,
add : {
status : 'failure',
error : action.error,
}
};
case siteConstants.DELETE_REQUEST:
return {
...state,
delete : {
status : 'deleting',
}
};
case siteConstants.DELETE_SUCCESS:
return {
...state,
delete : {
status : 'success',
},
get : {
...state.get,
data : [
...state.get.data.slice(0, action.index),
...state.get.data.slice(action.index + 1)
]
}
};
case siteConstants.DELETE_FAILURE:
return {
...state,
delete : {
status : 'success',
error : action.error,
}
};
case siteConstants.UPDATE_REQUEST:
return {
...state,
update : {
status : 'updating',
}
};
case siteConstants.UPDATE_SUCCESS:
return {
...state,
update : {
status : 'success',
},
get : {
...state.get,
data : [
...state.get.data.slice(0, action.i),
{
_id : action.site_id,
name : action.name,
description : action.description,
vectorMapUrl : action.vectorMapUrl,
},
...state.get.data.slice(action.i + 1)
]
}
};
case siteConstants.UPDATE_FAILURE:
return {
...state,
update : {
status : 'failure',
error : action.error,
}
};
default:
return state;
}
}
export default sites;
as you see, current there is only one store for sites CRUD on my web application project. but there are relations between data tables. for example
for this relation, what is the best store structure for React Redux
Upvotes: 2
Views: 143
Reputation: 1214
Redux stores are typically built around the concept of slices, where the entire data set is split into manageable units, with each unit being a property in the store object. This lets you code each segment one at a time, reducing the amount of code you have to manage in one place.
There are two schools of thought: sliced by data versus sliced by feature.
When a store is set up by data, you gain an advantage by having your data laid out in a cohesive manner, from a top-down perspective. For what you're describing, this makes sense, as you have a clear hierarchical relationship in your data. Actions can then be defined in a CRUD-like manner.
The one challenge is exactly how you manage different kinds of related data. If you have different data in different slices, yet have to maintain ID integrity across data sets, you might end up making multiple dispatches across different slices, which can get tricky. You can, of course, keep all your data in one slice, but that can get bloated.
When a store is set up by feature, each slice will be related to an activity in your app. This can make more sense if you have different "transactions," such as a retail site having profile management, shopping, and a community support blog. Slicing by feature lets you confine update concerns to a single slice, making each type of data associated with the feature more manageable. It also lets you put the sliced code for a feature in the same folder as the components for that feature, which makes for a nice comprehensive package.
The main challenge with slice-by-feature is deciding where data goes that could be impacted by multiple features. Shared or common folders, or determining a "home" folder, are different ways of managing this.
So what's the right answer? Of course, it depends. A lot has to do with how you want your app to flow. Is it heavily siloed? Then features might make sense. Is it mostly data access? Then data slices might make sense.
It's likely that you'll end up with a mixture of the two. You may have a primary "data slice," with additional feature slices. You might find that one kind of transaction flow makes it easier to manage data integrity than another, such as using a wizard-style entry path versus a free-form "add a node to a tree" style.
One last note: If you are looking to manage slices quickly and with some nice built-in philosophy and features, I heavily recommend checking out Redux Toolkit. It's made by the same folks who made Redux and implements the best practices they've seen in the wild to make reducer and action creator code manageable and self-documenting.
Upvotes: 2