Model your application as a reactive, directed acyclic graph. A graph is composed of vertices. Hence the name (vertex + redux = verdux). Duh.
- The human brain is naturally wired to process tree-like structures
- UI applications are most intuitively respresented as hierarchical graphs
- Asynchronicity is an essential dimension of frontend apps, and the source of most accidental complexity
- Reactive programming is just too powerful a tool not to use
- Models UI application state as a flow of data streaming through a directed acyclic graph
- Allows better separation of concern, each vertex in the graph is self-contained and self-sufficient
- Is designed from the ground up to provide maximum type safety
- Embraces asynchronicity in its core using the power of
RxJS
- Reduces accidental complexity for most typical front UI cases
- Prevents unnecessary re-rendering, without any manual memoization
- Integration with vanilla
redux
andredux-toolkit
- Declarative data fetching supporting cascade loading
- Automatic refetching and error propagation
- Epics, just like
redux-observable
, our favorite redux middleware - Some other cool stuff
https://github.com/couzic/verdux-examples
A lot of people have complained about redux
, some with good reason. Many have been drawn to other state management solutions.
Don't throw the baby with the bathwater.
Although we agree there must be a better way than classical redux
, we are not willing to sacrifice all of the redux
goodness you've heard so much about.
Making redux great again !
npm install verdux @reduxjs/toolkit rxjs
Testing an action creator, a reducer and a selector in isolation.
"Looks like it’s working !"
Testing in redux
usually implies testing in isolation the pieces that together form the application's state management system. It seems reasonable, since they are supposed to be pure functions.
Testing in verdux
follows a different approach. A vertex is to be considered a cohesive unit of functionality. We want to test it as a whole, by interacting with it like the UI component would. We do not want to test its internal implementation details.
As a consequence, we believe vertex testing should essentially consist in :
- Dispatching actions
- Asserting state
In some less frequent cases, testing might also consist in :
- Asserting calls on dependencies
- Asserting dispatched actions