Centralized states can be a disaster.

Anyone who is an experienced application developer understands that if your application is not the typical todo app, you have at least a few states that are application wide (they conceptually exist regardless of how they are implemented/handled). There are lots of powerful ways to maintain states well (like routes, singletons, storage and so on). But it all boils down to how you define them and use them.

Why disaster?

Centralized states can be a disaster for the very reason why global variables can be the same. When there is a central/global state, it can affect different parts of the application and at the same time it can be modified by different parts of the application. Trying to understand how a specific part of the application works, will depend on any global states that are affected by it or modified by it. This also means one specific part of the application will be bound to another part of the application by these states. As the application grows it becomes harder and even impossible to understand how different parts of the application are affected. In a really bad case, the application could run into issues that are virtually impossible to fix without a rewrite.

They are a necessity.

Like I said, they conceptually exist in an application regardless of how they are implemented. Take for example in Creately a selected shape. Creately is built to be highly contextual. Your current state affects pretty much every other feature. When a shape is selected, there are different other parts of the UI (outside of the canvas), that provide contextual features and feedback. Such state change is a necessity and must be implemented gracefully so that the context change is affected by a single state that is managed centrally.

Application platforms and frameworks provide various ways to manage central states. Most of them well implemented and widely used. The problem is not at the framework level though. It is in the way states are defined.

What is a central state?

This is the most important part to remember: It is not an implementation detail but a design decision. The problem is in how you decide what a central state is in your application and what it is not. The classification is not well defined as such. When deciding what a central state is, it has to be done with the full knowledge of all different parts of the application it affects and it is affected by. This, most of the time wont change drastically. So it has to be defined well.

• A state is a singular thing and it cannot represent two concepts or more.
• It has to be named in such way it clearly represents its singular state/purpose.
• It should be well documented so that the use of it is clear to anyone who uses it or modifies it.
• Use of it should be programmatically validated if that is possible.

While I have tried to outline the proper use of central state in an application, my post does not do justice without clear examples. Will try to do a followup post with good examples. Lets talk more in the comments.