[alexey2020]

>Let's say you want to add a button somewhere that hides/shows another widget.

That's a good case. This is purely UI state, right? (we don't store it on the server).

For UI state we still need to depend on prop-drilling or State Management solutions.

In the article I'm mainly talking about the Data which exist on Backend (as you can also see from all the pictures). In my experience such Server data is 90-95% of all data in most UI applications and that data contributes the most to the complexity.

Pure UI state is often just a fraction of the the whole State and is's often synchronous, so managing it should not be complex. So this kind of coupling will still exist.

To clarify, I do not say Widgets should be 100% independent. We do not achieve complete decoupling. But moving Server Data under control of Widgets gives us closer to this.

[d--b]

Well, you're comparing things that are not quite comparable then...

The store approach is all about how the app handles local UI changes. Whether the action goes and fetches data from the server doesn't matter. What matters is that the store gives you a single source of truth that represents the state of the UI, and that this state gets one-way-synced with its actual dom representation.

[alexey2020]

>Whether the action goes and fetches data from the server doesn't matter

I tried to explain in the article why it matters.

If you are comfortable with putting all the data in a single Store and this works fine to you, then you may disregard the article.