Flux-based architectures have been a wonderful boon to the development community. Frameworks such as Redux and Mobx offer a comprehensive way to wrangle complex state. But there’s often a cost: the complexity of the client side applications tends to explode. We are living in a world of front-end monoliths.
The solution? Break client side apps into smaller, pre-rendered applications with simpler or no state. Easy, right? The implementation is fairly straight forward, but knowing when and why to break up your application is where the magic happens.
Feel like your state is getting too nested on the client? That can be a good indication that the logical complexity of your application has grown and it might be time to start breaking it down into smaller pieces. Another common indicator is a rise in merge conflicts on teams as small as eight developers, even while working issues that are mostly in separate sections of the code base. This may indicate a deeper problem with CI/CD and the confidence and cadence of your deployments, but breaking apart the application will help alleviate the conflicts by reducing the surface area of largely isolated sections of the code interacting with each other. …
There are a lot of good techniques and best practices out there about how to write dry, scalable SCSS for when you are developing your website, but what about when you are done? What happens two years later when a new developer rolls on and gets a ticket to fix a “simple” UI bug on mobile, and has to sift through thousands of lines of SCSS to track it down? This article contains a couple of low-effort, high-reward techniques for making your SCSS easily debuggable to others. These techniques are particularly useful if your project: