Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@lurch I've been reading about this for a full hour and I still don't see why CQRS would imply a single set of actions. It's mainly about structuring code for a single datastore, but if parts of your data are so independent they can have separate datastores, commands and queries and are only connected in the view that's surely preferable.
-
@lurch Not to mention that CQRS was mainly designed to fix scalability issues on the server, and it's a bit oversized for the client so the only universally accepted aspect seems to be that state should only be mutated by actions which bridge the problem domain with the solution domain and are isolated from the view. If a concept is isolated in the problem domain as well and not just in the solution domain then there's no reason it can't be a separate store.
-
@lbfalvy yeah that's a structure I agree with. Most apps I've worked with have data that's pretty modular. You have stuff that can be treated as pretty separate; like user-profile is separate from accounts are separate from payments are separate from posts are separate from messages... And so on.
The case can be made for substate if you have a deeply nested GQL model that is the basis of your app but most apps just don't justify that complexity. -
We're using ngrx (Redux, but for Angular) on a company project and I like it a bit and I can use it. During the development of a recent personal project we've also felt like we need some kind of reactive state management. So we've found out that Akita exists and since then Akita is my favourite, because it's just way simpler than the other frameworks -- and I usually work on smaller projects in my free time, so no need for complicated stuff.
-
For me, Redux is a bad implementation of state management because it promotes one global store which is "hey lets use one global state, but with extra steps. What could go wrong?". Thankfully with context hooks now redux is obsolete and you can ignore it and separate your state into proper multiple stores each having a responsibility of one logical piece of state.
-
@galileopy Reducers react to a particular action type, and are therefore monolithic. Ideally, a reducer that combines sub-reducers would have its own actions and take care of addressing the sub-reducers in such a way that they don't interfere. Unfortunately with Redux's typings it's near impossible to alter the actions of a sub-reducer and still have your action types work out without writing walls and walls of boilerplate.
-
@Lyniven I don't know, I'm just a lowly student applying the rules I learn on tech to understand the tradeoffs with my tools. Redux makes a very strong guarantee about repeatability, but they seem to have a problem where selectors are tightly connected to the state they expose but the tree structure which is an external element is pinned in between the two in the control hierarchy.
Here is a tutorial on how to create a contact form in React / Redux.
Redux is weird, and I don't like it because it violates the most basic principles of responsibility. The concept of expressing state changes as reducers is nice because it can be duplicated, saved and restored and compared for equality. So is creating isolated accessors and selectors. However, I really don't think a reducer should be aware of its own position in the hierarchy. When specifying an action you aren't addressing a reducer, you're addressing the tree. That the tree doesn't manage this addressing and expects reducers to identify themselves is a bit strange, especially considering that the whole point of having a tree is that reducers shouldn't be affected by their position in that tree because they're pure. Same goes for selectors, they should belong to the tree, not to any particular sub-reducer. Separating the slices is reasonable structure, but if you specify parts of the addressing in the slice and parts of it in the root you might as well just use separate reducers for each of your slices. It's functionally equivalent.
rant
redux