Stepping back and taking a look at it, the reason behind so many iterations probably indicates that we have yet to “solve” the Single Page App (SPA) architecture. In my opinion, that’s something to be excited about! We get to watch the evolution of big part of our industry evolve as it takes important steps towards an ideal architecture. It’s also the perfect time to be a part of something big! No wonder so many new libraries are popping up.
A bold prediction
I’m going to level with you. I’m not the type of person to make definitive statements about the evolution of software architecture. Frankly, I just don’t think I’m qualified. I am, however, comfortable making a prediction:
Backbone is here to stay!
Flux is here to stay!
So let’s talk about some of the principles behind the Flux pattern and why they are valuable.
One-Way Data Binding
I remember first learning the concept of two way data binding and think it was so obviously the best idea to come out in a long time. If the data changes from the back, load the new data for the user. If the user changes the data in the interface, send it back to the store. This was one of those theory vs practical application predicaments. The theory behind two way data binding was great, but the application of it left something to be desired. This was further realized when Angular 2 appeared on the scene and moved to one-way binding.
For anyone that used AngularJS to develop a bigger application, it became very evident that maintaining the state of data was, for lack of a better term, a shit show. Abstracting to services worked, sort of, but overall the state of state management (pun intended) was lacking a consistent standard.
Clones are unethical!
Just like our data has one source in our database (excluding replication) it’s important to maintain one record of data on the front-end. Making changes to data that exists in more than one location can create undesirable outcomes. Which one is accurate? Perhap both? Perhaps neither? This is particularly true in an asynchronous environment.
Actions are events and more!
Actions allow us to create reusable application logic that can be tied to both browser events and other pieces of application logic. A user clicks the logout button? Dispatch the logout action. An API returns a response you weren’t predicting? Dispatch the same logout action and be guaranteed the same results. It’s clean, effective, and DRY.
Reducers are reliable, events aren’t
Reducers create predictable and reliable data outcomes for unpredictable events. UIs are crazy! You never know what to expect. Directly tying events from the UI to our data is just irresponsible. With reducers, you can always expect the same outcome for a dispatched action.
Testing (Wah Wah Waaaah)
To some this won’t matter but with Flux, unit testing is easy. If you’ve ever attempted unit testing in Angular, you’ll know why this is valuable. Making unit tests easy to write is key to getting people to actually write unit tests. Better test coverage gives us better software.
Do I think Flux is the precipice of state management for SPAs? Likely not. It does, however, provide us with solutions to many of the primary problems we’ve uncovered through the trial and error development of SPA architecture.
Of course, the comment section for this post will remain open so that anyone reading this may feel free to come back a year from now and drop a big fat WRONG in the comments. Upon which time I’ll make another bold prediction about the future of the web stack.
Thanks for reading!
Pingback: 1 – Learn Flux because it’s most likely here to stay