Learnings from React and Flux

To people who immediately say I'm an idiot, then you're probably a good programmer, but a terrible mentor. True that React + Flux is efficient and makes sense, but for the people like us who have not been taught The Right Way™ of creating apps, it's somewhat a big leap. jQuery has helped people a lot, but it has created monsters out of developers. Architecture-less applications, stateful HTML and all those stuff. So here, I outline where I have been, what I did, and what I learned off of these adventures. Hopefully someone will stumble across this and be of help to them.

HTML should be stateless

I never understood this at first. I mean, how could HTML have state? A few months into component development, there I realized what they meant by "stateful HTML". Direct to the point, it's HTML inputs that keep state. That's how forms are able to send data, by persisting that state before submission.

Now imagine you're stepping into the 21st century and in some super complex SPA where an input's value is being depended upon a number of other UI elements. You CANNOT have that state in the UI. Otherwise, pulling out that UI element will break the others. What should one do?

Easy, keep state in a cache layer, and have the UI render whatever the cache stores. This means the UI should report any action to the logic, and whatever the logic stores to the cache, the UI renders. This means that the checkbox should not check itself immediately after clicking. It should inform the logic about the click first, then have it decide what the cache should look like after, then the cache informs the view of a re-render if required.

In summary, HTML should be "dumb". Don't keep counters in data-* attributes, don't keep count using numbers inside the HTML. Keep them in a cache, HTML should just be the representation.

A single, immutable source of truth

I have always wondered before why data is "passed by reference", unknowingly siding myself to immutability. Along with that, I always wonder what's the purpose of return if I just mutated some memory space and have nothing to return? Fast forward college, where I was working with microcontrollers, instructors have "fortified" the idea because copying was a waste of memory.

Fast forward to the modern web development days, I carried this practice to the web world because I was under the impression that the browser carried the same symptoms like slow operation, constrained memory and all that. But that was about to change when I had to build a web app.

Data was mutated everywhere, with code that you didn't create. Data just mutates by itself as if it had life. You input a value somewhere, something else comes out. And nothing was consistent. The problem was because JS objects were mutated across the app. One component didn't know what the other did with the data. Two-way binding also made it worse, causing the library to throw initialization errors because there were 2 competing declarations for the same data, one in the instance, the other downstream.

Too many chefs spoil the soup. There should only be a single source of truth, regardless if the consumers believe otherwise.