using javascript globalThis for state management

Question

It seems like a crazy idea, but is there any problem if I use globalThis to store the global state of my browser only SPA.

I am thinking of something like this

globalThis.state = {...initialStateData}; // attach a property to globalThis and initialize
//later in any component, mutate the value
globalThis.state.counter = 45;
//yet in some other area, access and display the value
console.log(globalThis.state.counter);

This can be taken further by introducing proxies into the mix and create something like a light weight redux.

I tested this in chrome, and it works (by works I mean chrome had no objection on me attaching my data to globalThis).

My question is, is it a crazy idea and should not be used in a production app because of some standards that I might be violating in ignorance?

Or perhaps, behaviour of globalThis is gonna change over time and browsers will not allow user-attached attributes to this specific object?

EDIT: This question is about pure vanilla JS and not about redux or react or even typescript.

How to define global variable in Deno? will be the closest match to the current query

Answer 1

Modifying the globalThis or the window object of browser is quit non-conventional & it would create some issues that'd be hard to debug or fix.. Also this is one kind of object pollution & eslint/jshint will also complain about & typescript will throw Compile Time Error.. Don't do this in production as it'd be very bad in the long run.. One of them is conflicting property names & there are many problem that will arise. I don't know each & every one of them but you can easily read some medium books/articles about this behavior. Also that's why modern npm packages doesn't touch these objects as globalThis doesn't allow the idea of modules... Try using globalThis/window as read-only objects.. Don't mutate the props of it..

Hope you understand what I said..

Answer 2

It is generally not recommended to modify globalThis (or window) for the following reasons:

• Naming Conflicts with 3rd party code: If another script also modifies globalThis and chooses the same name, you're in trouble, though this applies more to libraries than the main page's logic.
• Naming Conflicts with Javascript: New built-in javascript utilities tend to get added to the global object - if they ever added one with the same name you're using, it'll cause issues, both in your page, and any library you use that expects that utility to be there. However, as long as your name is unique enough, this really isn't a big issue.
• Versioning: If you're developing a library, there are unfortunately scenarios where you might have multiple versions of the same library loaded at once. This is not possible if they use global state. Again, this doesn't really apply to use as you're not developing a library.
• Traceability: It's difficult to know what sets the global state and what modifies it.

So, in all honesty, you can probably get away with using global state and not face any of those negative consequences. I don't want to just tell you not to use it simply because that's the recommended advice. In fact, back in the day, it used to be more common for websites to put all of their data and modules into one giant global hierarchy. However, I would still recommend avoiding global state for one other reason - A better solution exists that's less magical. Javascript now has a standard module system that can be used in place of global state. Just create a module to hold whatever shared state your application has.