Hello, React.js

You’re the popular figure on the Internet now and frankly, I felt rather unsure when I was first introduced to you. Your style seemed quirky, especially how you seemingly went against the holy grail of engineering advice, encouraging us to break the principle of maintaining a separation of concerns.

Strangely, our initial interactions went well, in fact, a little too perfect I must say. It was easy adapting to this unconventional style you call JSX, and I started to see the additional values you provided through multiple lifecycle hooks.

But alas, as our relationship grew deeper, I fell into my comfort zone and ended up dropping the ball on several occasions. I drew upon my experience with others and tried applying the same principles to you, and that was a foolish decision since everyone operates in a different manner.

Even though I managed to salvage the situation and repaired the damage over time, I couldn’t help but feel that all these could have been avoided altogether if I had let go of my inaccurate expectations developed through previous experiences.

Thus, if I were to start over with you again, here are some of the important pitfalls I would avoid repeating.

Stores are not Models

React.js integrates well into this design paradigm known as Flux and within it, there exists a concept known as Stores — the source of truth for our application’s logic.

Stores bear a close resemblance to Models, but they shouldn’t be designed in the same way.

Models are collections of objects, each representing a single record of data that may be shared across multiple domains of logic. Stores, on the other hand, represent the application state for one particular domain within our application.

I made the mistake of designing Stores as if they’re Models, staying close to my database schema, and haphazardly applied my experience with the latter within a Flux application.

Things may have worked, to a certain degree, but not without a series of unnecessary frustrations and struggles which would have been avoided if I hadn’t tried to force it to adapt to a familiar concept from a different design paradigm.

Bottom line is, don’t be afraid to deviate from your database schema even if you end up with duplicated subsets of data across different stores. It’s still better than having multiple domains share data objects which may be inadvertently modified, causing unintended state changes to unrelated components.

And after all, Stores are not Models.