Reputation: 1389
I was starting to use Flux, I checked Redux and Facebook Flux. The idea is very nice but I felt some boilerplate code there with lots of calls.
I understand for a big-size project those boilerplates will help in the future but for small-medium sized projects I was thinking can't we get rid of actions and dispatcher and just use the store with setters and getters inside the store, also allowing to subscribe to the store for changes?
For a chat application:
{
unreadMessages: 0,
messages: [{
from: myUser,
to: toUser,
text: "hi"
}, ...],
hasUnreadMsgs: () => { unreadMessages !== 0 },
newMsg: (fromUser, toUser) => {unreadMessages++; -and insert msg-},
getMsgs: () => messages,
subscribe: (callback) => {...}
}
Only drawback I see is this object might get too big. To resolve that issue we can easily separate the store into multiple objects then assign them back with Object.assign(). For example we can have UserStore and MessagesStore separately then merge them back before initializing our store.
I understand that for a big project like Facebook having multiple stores make sense, then a single action might update multiple stores so actions should separated.
But as far as I understand Redux has a single store and single store works well. So why should we not get rid of actions and dispatcher and just use that single store for a small/medium sized project?
Upvotes: 1
Views: 563
Reputation: 838
For small size project you can manage even without using flux architecture. Removing Dispatcher from flux means you are no longer using flux.
Flux applications have three major parts: the dispatcher, the stores, and the views (React components).
If project is small, I would suggest not to maintain separate store too. Just maintain state inside parent components as we would do without using flux architecture. We did small project using this approach and it works great.
Note: Sometimes we need to communicate between component having no common parent. For such scenarios we have to use dispatcher or can use small pub-sub library.
Simplest pub/sub implementation can be like:
var Notifier = (function() {
var callbacks = {};
return {
subscribe: function(name, cb) {
callbacks[name] || (callbacks[name] = []);
callbacks[name].push(cb);
},
notify: function(name, data) {
if (!callbacks[name]) {
return;
}
callbacks[name].forEach(function(cb) {
cb(data);
});
},
unsubscribe: function(name) {
if (!callbacks[name]) {
return;
}
delete callbacks[name];
}
}
})();
But if it is a med or large size project I would suggest you start with some type of pattern. Flux or redux both are great to start. Using redux or flux may force yuu to write some boilerplate, but it will definitely help you in the long term. Also different pattern might come with different conventions and good practices which will help large team in making quick choices and follow the same set of conventions app wide. This will also facilitate easy onboarding of new team member in the project.
Also large numbers of people, have adopted flux and redux and if you use them you would get a great ecosystem (plugins/extensions build on top of this architecture).
At last everything boils down to the personal choice.
Upvotes: 1
Reputation: 2158
Because the dispatcher updates the store and whenever a store is updated it also sends callbacks which lets components know they might need to update. If you have one store where you manually patch in data you yourself are responsible to notify all components that might need to change.
But by all means if you have a way to solve your problem in a simpler way go ahead and write it like you want. Nobody forces you to use anything.
Maybe something like MobX might fit your programming style better? It's like what you describe but it has a way to detect what changed and notify all interested parties.
Upvotes: 1