[isubasinghe]

Hey thanks for reaching out, that's very nice of you :), I have no specific concerns atm but will reach out I do need help.

Issues with thunks are maybe(?) due to our implementation again, but we have way too many dispatches being called (100s of lines of dispatch calls for one action sometimes). It becomes quite hard to trace what happens when a certain business logic is executed because of this.

For example, say we have an action to delete a domain level entity, lets say this is a book, well books can have paragraphs, paragraphs can have sentences and sentences can have words (normalized state, terrible example I know, but all I could think of atm). Well the action to delete a book, has dispatches to delete all children entities as well. These dispatches actually may have other dispatches as well for ui stuff etc. Doing redux this way really didn't scale well for us, but I suppose we have very very unique, complex business logic compared to other projects.

The style guide looks excellent, I think this would have made the codebase easier to follow. I will defs be following this for my personal projects.

Thanks

[acemarke]

Yeah, it sounds like the issue here is that you are trying to dispatch a single action per tiny state update. This is why we now recommend "modeling actions as 'events' instead of 'setters'". See the links I posted in this sibling comment for suggestions on how to change your conceptual approach:

https://news.ycombinator.com/item?id=21853160

Also, note that our new Redux Toolkit package will at least help simplify your existing logic, and you can begin migrating to it incrementally:

https://redux-toolkit.js.org