Rethinking Separation of Concerns with React
And how it differs from Angular
Understanding the true nature of separation of concerns is one of those topics that separates newbies from the seasoned developer. There’s more to code than just getting the syntax right. Beautiful code is one that is modular, loosely coupled and extremely easy to maintain. I’ve been thinking about long term feasibility of React and SoC over the past few days since my original deep dive into the framework.
When Angular 1 came out, everyone was excited because of how easy it was to do things. But as projects grew, complications started to arise — especially when there are multiple people working on a single code base. One could argue that it is the nature of programming — and perhaps it is, but it doesn’t have to be. Angular 2 came out and forced a stronger separation of concerns through explicitly requiring different types of files for different functionality. HTML lived in one file. Your component logic lived in another file. Relevant CSS is automatically localized to a single file and your services in another file.
React challenges this way of thinking by encouraging you to put everything into one space.
What is separation of concern?
separation of concerns (SoC) is a design…
