How state stores are different from "global variables"?

Question

Context: I am developing an amateur web application (with Vue.js), made up of components, and when reading about state management, the recommended solution is to use a store that gets updated by the components.

Over the last 30 years, I have been reading how using global variables is bad design, and I understand that, having slowly appreciated the functional aspects of building a function that is not dependent on the external world, and that gets what it needs as parameters (broadly speaking).

How is the store (or bus) approach different? How does this not breaks maintenance and reuse of components?

It is certainly easier to have one shared store and not worry about passing data in, and handling emitted messages out of components but, again, I have concerns about long-term maintenance.

Answer 1

So javascript SPA frameworks have a couple of problems for which global state is an easy solution.

1. They are not directly in control of the objects rendered by the browser. They have to go through HTML encoding first and then the browser has to render the HTML.

2. The goal of these frameworks is to make things simple and webpages don't tend to need a lot of logic.

Considering point 1. Pages consist of components and components can have sub components. The alternative to global state requires events that get passed back "up the tree" from sub components to the page and then back down again to other sub components.

If you are rending a window in directx at 60fps and each component reads its values from memory this is pretty simple. Hook up your events and you are go. If you have to calculate all the changes, render virtual HTML, check of differences with the last frame, alter the HTML, write the altered HTML to the DOM, wait for the browser to render the new HTML you may have performance issues.

Also its hard to write the framework. If you have global state you can change it and redraw once from the top down.

Considering point 2, global state is easy to understand and program. I don't need events or call backs or mediators, I have one, one way, draw loop. Do I need more for 90% of webpages?

But yes, I agree its not good practice and for complex web applications it makes things awkward and highly coupled. However. Another rule of programming is don't try and fight the framework. Maybe vue is not suitable for complex interfaces and you should go with a canvas and pure js, or web asm