Originally published at: https://michel.codes/blogs/ui-as-an-afterthought

A question people ask me regularly: “How do all the new React features (context, hooks, suspense) affect how we build (web) apps in the future? Do they make state management libraries like Redux or MobX obsolete?”

With this post, I’ll try to answer that question once and for all! To truly understand the question, we’ll need to do a little groundwork. Let’s step back, and leave React, Redux and MobX alone while we answer a more fundamental question.

What is a web application? For the purpose of this post: A web application is a user interface…

In the first part of this blog post series we discussed the advantages and disadvantages of snapshots, patches and actions when building applications in which we want to distribute state changes.

In this blog post we are going to build a simple distributed system that plays with these concepts. The goal of this exercise is not to build the best system possible, in fact, the system we are building is pretty naive and much better algorithms exist. The example is just a mental exercise to train ourselves in thinking in terms of terms of patches, actions and snapshots.

The examples…

Link to Part 2: Distributing patches and rebasing actions using Immer

Managing state in a client-side only application is relatively simple in JavaScript. There are few constraints in place that make this easy: JavaScript is single threaded, which avoids an entire set of problems. And there is only one actor in play: the user that interacts with the application.

However, things get quickly more tricky when server (or p2p) interaction comes into play. Especially if that results in multiple users, or actors, interacting with the same data. …

(this blog has a Korean translation here)

In the many projects I have maintained so far, sooner or later I always run into the same issue: circular module dependencies. Although there are many strategies and best practices on how to avoid circular dependencies. There is very little on how to fix them in a consistent and predictable way. Usually, people move import statements or blocks of code randomly around until “it suddenly works”. As it turns out, I am not the only one running into this problem, given the responses to this tweet:

Luckily, as I will demonstrate…

TL;DR: MobX 5 changelog and migration guide

Princess Proxy looked down at the crowd approaching the balcony of the throne room.

“Be careful, they are after your values.” Her father had warned her. “But don’t worry, you’ll be ready for it.”.

But today, on her coronation day, she couldn’t help but feel nervous. Her father had told her this day would come almost three years ago. But back then she couldn’t fathom it. And now the day is here.

A hand was placed firmly on her shoulder. Her father. The king.

“Go, my daughter. Beloved Proxy. You are ready. …

I’m proud to announce that a new major version of MobX has been released! The changelog is quite long and includes a migration guide. So, in this blog post I’m just going to highlight the most compelling new features. Btw, if you are not familiar with MobX yet, make sure to check the free egghead.io course!

TL;DR:

• Decorators without decorator syntax
• Dynamically extend observable objects
• await when and flow to further simplify asynchronous processes
• onBecome(Un)Observed to automatically fetch data sources
• Dedicated production build. Smaller & faster.

All of the new features mentioned in this blog post are demonstrated in the…

Immutable, structurally shared data structures are a great paradigm for storing state. Especially when combined with an event-sourcing architecture. However, there is a cost to pay. In a language like JavaScript where immutability is not built into the language, producing a new state from the previous one is a boring, boiler-platy task. To prove the point: The Redux-ecosystem-links page alone lists 67(!) packages to help you to deal with immutable data structures in Redux.

And still; most of them don’t solve the root problem: lack of language support. For example, where update-in is an elegant concept in a language like…

Many words, talks and articles have been dedicated to the question “should I be using Redux or MobX?” Even React books tend to discuss both nowadays. Yet there is no ‘winner’ and nor will there be (off-topic: it is even highly questionable if there is anything to ‘win’ in OSS in the first place). The reason for this is simple, both libraries yield completely different benefits. So your preference will be determined by your requirements and values rather than the intrinsic quality of either of them.

Now, since that has been settled, let me share why I like Redux.

First…