4 ms·

I 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

I 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 ago
Encapsulate 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 ago
  Perhaps 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 ago
    I 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 ago
      Are you talking about using React, or some kind of home-rolled setState function on a simple object?
  - acdha 4y ago
    If 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 ago
      Interesting, 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 ago
  Unfortunately, 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 ago
    Things 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 ago
      There is definitely truth to this, I agree.
- whycombagator 4y ago
  That 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 ago
That 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)
- yawnr 4y ago
  “Monitoring and propagating” — aka one of the global state management solutions being discussed here? Redux state is “just an object” that does shallow comparisons to trigger re-renders
- symlinkk 4y ago
  So now you’re re-implementing React.
Beltalowda 4y ago
A 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).

I 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 ago

Encapsulate 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 ago
Perhaps 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 ago
  I 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 ago
    Are you talking about using React, or some kind of home-rolled setState function on a simple object?
- acdha 4y ago
  If 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 ago
    Interesting, 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 ago
Unfortunately, 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 ago
  Things 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 ago
    There is definitely truth to this, I agree.
whycombagator 4y ago
That 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 ago

That 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)

yawnr 4y ago
“Monitoring and propagating” — aka one of the global state management solutions being discussed here? Redux state is “just an object” that does shallow comparisons to trigger re-renders
symlinkk 4y ago
So now you’re re-implementing React.

Beltalowda 4y ago

A 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).