#71 Modelling MobX state as in Redux
this week's favorite
MobX is easily my favourite JS library. There’s no library out there which would excite random people as much as MobX does. It’s slowly catching up to Redux’s popularity, but it isn’t a silver bullet to all your state management problems. Most troubling is a lack of recommended practice.
The main goal of this article is to show you how to create and setup a few useful services to improve the life cycle of your app, to authenticate a user and access protected resources.
Today, we’re open-sourcing Redux-Doghouse, a library for Redux that helps you create Scoped Actions and corresponding Scoped Reducers. This pattern is useful for creating components with Redux which can be reused multiple times in multiple contexts, but with a scope that prevents them from conflicting with one another.
So you've decided to try out Redux as your application state manager. Or perhaps you're investigating better options. Good for you. With Redux the good news is your application will enjoy a productivity boost from the simplicity of knowing precisely where data logic lives. However, Redux alone cannot protect you from a fashionable, spiced-up spaghetti mess. How does it fit into a multi-tiered application composed of several orders of widgets and components that each rely on asynchronous data? In order to save yourself from this ugly monster you'll need a higher order architectural convention.
We are in the process of migrating our front end from server rendered views with jQuery and Knockout (KO) sprinkled on top to TypeScript and React. It’s been a few months now since we started going down this path and we’ve shipped some big updates in our new stack. We’ve learned a lot and are excited to share our experience adopting this tech because we know it’s something a lot of companies are evaluating right now.