PCreations
commented
7 years ago I put here the comment by Sebastien on the PR thread :
thanks for your contribution (was on holiday sorry for delay)
Like the idea of takeLocal in sagas, that seems related to my idea of "2 mailboxes".
Code is complex and involves some boilerplate but it's still pretty easy to follow. Not sure it could be made much simpler anyway. Don't really like to have to lookup things by strings in context, but maybe with types it could be more convenient on refactors.
As far as I understand each modux can declare its default initial state, and this can always be overridden from the outside right? (as long as it exports a init method).
I'm not really fan of new-gif-counter-and-button.js. If one day someone else come with a new business requirement that involves the button, what would you do? For sure we don't want this file to grow over time and become a mess that hold all the business rules that involves the button, but rather split the different unrelated business rules in different modux. Then comes the question on which of these modux is supposed to export the button view.
Effectively I don't remember why I created the new-gif-counter-and-button.js file, I edited the solution without it.
Hello there ! Here's my 2 cents, modux-js is born from this challenge. The main goal was to be able to write vanilla redux. The modux-js library only introduces some higher order functions and factories to keep redux ducks (or module, redux + module = modux) encapsulated.