4 ms·
Good ol’ {} Add anything you want to keep to it, store it in the window with window.app = {} You can mix local storage in with it too if you want to write a
by gabereiser 4y ago
Good ol’ {}
Add anything you want to keep to it, store it in the window with
window.app = {}
You can mix local storage in with it too if you want to write a class that checks its existence with a key.
Why must state management need a complex solution?
I’m sick of frameworks and modes where they abstract away the simplicity of javascript in favor of their way which is very economically driven.
- Ambolia 4y agoI assume the idea is for changes in the data to trigger changes in the UI? If you just keep the raw data on an object you still need an additional mechanism to synchronize the data on the screen.
- swagasaurus-rex 4y agoEncapsulate it into two functions: window.getState(); window.setState(); You could even use document.querySelectorAll() to go through all the elements on your page, and update them based off values in the state, whenever window.setState() is called. This is basically all front-end frameworks in a nutshell. You've invented reactive programming in the browser.
- tomduncalf 4y agoPerhaps my way of thinking is React-centric but this feels like a pretty inefficient way to do it. Feels a bit like reinventing the wheel poorly when things like MobX exist, sure it’s simple to start off but then you hit performance issues or issues with dependent state etc. etc. and you realise why, for all the derision they sometimes get, libraries exist to solve this problem and they are useful. But for a simple thing built with JS that isn’t going to need to scale to a large codebase or whatever, sure, keep it simple!
- Kiro 4y agoI build games where I run a global setState on the root component 60 times a second and even with deeply nested components it's not even a factor in performance.
- sibeliuss 4y agoAre you talking about using React, or some kind of home-rolled setState function on a simple object?
- acdha 4y agoIf you don’t have the overhead of React you have multiple orders of magnitude more headroom. That’s enough to push common UI idioms as far as they can go in many cases - for example, interactive tables with at least 10^5 rows perform well in modern browsers so using the DOM means you can keep things simple and fast without having to struggle with the scrolling, text selection, accessibility, etc. concerns that custom widgets entail. An awful lot of applications exist where you need more than hundreds of records but fewer than millions.
- tomduncalf 4y agoInteresting, I wonder if the overhead of updating UI based on state “efficiently” (eg MobX style tracking of what should re-render when certain data changes) would actually be slower than brute force updating everything in this scenario? A bit like I’ve heard people talking about just rendering the UI to a canvas, a whole new render 60 times a second, is actually the most efficient way to update a UI for certain cases like really big stock ticker displays (versus selectively re rendering bits of HTML)
- sibeliuss 4y agoUnfortunately, it's not so simple! For anything non-trivial you'd have to add some kind of listener or tag to every node, find said node, and then update (ideally in a performative way). Said updates cannot destroy existing state, but must patch it. Updates must also not break existing attached event listeners. The list goes on and on.
- Olreich 4y agoThings are faster than you’d expect. Tables with millions of items don’t work in any framework, but tables with a hundred items work in all of them. Since no one has really cracked the nut on performant UIs with lots of things going on, anything homegrown will be simpler and performant enough compared to the major competition.
- sibeliuss 4y agoThere is definitely truth to this, I agree.
- whycombagator 4y agoThat is one way to do it, albeit a seemingly naive way. I can’t imagine the entire page is linearly searched to update a UI element these days. Perhaps an entire component in some frameworks? I don’t know and can’t easily find out the time complexity of things like React setState(), but would hope that for frontend code bases where there is a build step(s) and/or for typed frontend languages we could achieve better than linear (especially if N is every element on the page)
- whycombagator 4y agoThat assumes the rendering is done on the front end. However, you could attach event handlers for state change monitoring & propagation. I’m curious to know how scalable an object GP described would be for UI state (assuming it needs monitoring & propagating)
- Beltalowda 4y agoA lot of state either never or rarely changes, so one must wonder if you really need a lot of complexity to manage all of that. Some state does change a lot, and for that: sure. But if you just have currently logged in user or some such (which is quite often the case): meh, it just seems like a complex way to set a global variable. This week I spent some time removing the Vuex state management in favour of window globals and it made everything a lot simpler and the bundle size a lot smaller (the other option would be to migrate to Pinia, which is significantly smaller than Vuex, but then I'd probably have to update to the next incompatible version in 2 years, and this seemed more robust).
- spiffytech 4y agoStoring state in plain objects is a nice way to go when you pick a framework that doesn't care about state management. Forgo, Mithril, and Crank all require explicit commands to rerender, unlike React and friends, which need visibility into everything that could ever trigger a rerender so they can handle it automatically. You'd think manual rerenders would be a big pain, but I find it a small price for allowing by state to just be regular ol' variables. It makes everything feel simpler, like I'm just using the language instead of expressing my business logic through the framework.
- candiddevmike 4y agoMithril isn't necessarily explicit, rerendering happens on various user interactions by default.
- kevinfiol 4y agoMithril does full rerenders by default on event handlers and upon requests made with its request util. Normally, this would be a no-no in React land, but Mithril is fast enough that it's a non-issue, and it greatly simplifies state management (POJOs work great for global state, and closures enable a simple way to make stateful components).
- P5fRxh5kUvp2th 4y agoFunnily enough, that's where I'm at too. Just don't use a state manager at all. There may be times when it's worth the cost, but otherwise just hang it on the global state and move on with your life.