Today we (Verizon Digital Media Services/Volicon) released the new version of our JS frontend framework based on React and two technologies we developed in-house — Type-R for the state management and NestedLink for the two-way data binding. It’s called React-MVx.
React-MVx is an MVVM (Model-View-ViewModel) framework which follows an exactly opposite approach to Facebook’s recommendations regarding an application architecture with React. Because, we respectfully disagree.
- Layered incapsulated state preferred to the “single source of truth”. The same technique for managing the local and global state is better than different or “no local state at all”. And we accept no excused about “the large boilerplate”. There’s must be no any extra price you have to pay to “do things right”.
- Regular classes with deeply observable changes used to manage the state instead of immutable data structures. All state is automatically serializable to JSON with no additional effort.
- Pure render optimization works with mutable data. You may heard that it’s impossible, but in React-MVx it’s enabled with the single line of code.
- State synchronization is not an anti-pattern, not it has to be complex. In React-MVx, this is the recommended pattern to implement the editing the list item, and the synchronization itself is a one-liner.
- Mixins are not considered harmful but as a useful abstraction. In React-MVx, they work perfectly together with ES6 classes and inheritance. You can even define your own mixins member’s merge rules.
- Two-way data binding does not have to violate the unidirectional data flow. In React-MVx, two-way data binding is functionally pure and is very helpful in managing complex forms.
- Forms validation and generic I/O are considered important enough to address directly out of the box. Validation is implemented in the way that you don’t see it in the React Component; you kinda have it for free.
We wouldn’t give you recommendations like “use this state management technology for the small app, and this one for the big”. First of all, you never know if the small app will eventually become the big one; it may happen if you’re lucky (our application of 200K SLOC evolved from quite a small one). But the main point is that we believe that if the technology is not the best choice for the small program, it probably means it’s just a bad technology which most likely will make the large program just awful. React-MVx is developed with the vision described above: it’s designed to make it pleasant to write and read code no matter do you have 100 or 200K SLOC in your app.
The long story short, the design choices made in React-MVx are really opposite to those which are commonly advocated these times in the React community. If you don’t like the “traditional React way”, try ours.
But be warned. You may like it.