@cjsauer To be precise about that, since we are aligning with React itself in this regard you'll still get stuff like this https://codesandbox.io/s/silly-faraday-mb94d?file=/src/App.js

@roman01la are you referring to the use of hooks? Scanning thru the PR. I’m noticing the use of rum/use-state in the examples, which I honestly had no idea even existed! I opened up a PR adding descriptions of those wrappers to the readme: https://github.com/tonsky/rum/pull/209 I also see you’ve implemented request-render in terms of .setState. Does Rum actually make use of (.-state component), or does this simply “trick” React into scheduling a render?

no not hooks, but how the caret jumps to the end of input in that example

Ahh yea, I see now. I opened on mobile initially.

I’ve had this issue in the past. Will be great not to worry anymore.

well this one in particular is just the way how inputs work on the web

but issues like skipped characters or jumping caret when typing in text won't be a thing in rum anymore when we merge that pr

> you’ll still get stuff like this Ah I misread. I see what you meant now.

> I also see you’ve implemented request-render in terms of .setState. Does Rum actually make use of (.-state component), or does this simply “trick” React into scheduling a render? That's just to schedule an update, yes. We might change this a bit in future, but the idea is that we should schedule updates using React's usual mechanism.

> Scanning thru the PR. I’m noticing the use of rum/use-state in the examples, which I honestly had no idea even existed! I opened up a PR adding descriptions of those wrappers to the readme: https://github.com/tonsky/rum/pull/209 Thanks. I'll merge this after https://github.com/tonsky/rum/pull/205

There's a high possibility that Rum could easily adopt Hooks and Suspense w/o breaking existing users, which is exciting

I've already added Suspense component and lazy loading support for code-splitted components

I have not been able to rationalize suspense so far

and I am saying this as someone who has been using concurrent rendering since like 2016

and hooks are the best thing that happened to react, imho, but I still don't like using functions that are effectively Views, to manage state

Yeah React gets complex and I'm not sure I like this, it becomes harder and harder to integrate with it

Afaik, calling in concurrent mode render on the root node with a full state is not different from just calling this.setState

the event system assumes those are low level updates

so I am going to hook up datascript one day to it, and see how far I can push it, because I think it goes all the way 🙂

I've been looking into useMutableSource, no opinions atm

> Afaik, calling in concurrent mode render on the root node with a full state is not different from just calling this.setState Is there anything to read about this somewhere?

That would be good news

https://twitter.com/dan_abramov/status/691301224541503488

found it 😄

it might've been true even before Fiber

someone even answered there, maybe you see who 😄

funny, this life 🙂

https://twitter.com/dan_abramov/status/1143206952148918272 this is also relevant

looool 😄

How that would work with subscriptions deep in UI tree + memoized components?

I guess this is just two different models of propagating updates

perhaps React context can be used in such cases

the naiv thing is just to pass props, it's trivial if you attach static query props to components, I am not sure if rum does this? I think om next works like that

context is the idiomatic react way, but it's surprisingly slow

yeah, I never used it actually in cljs

The thing is, as long as you want locally managed state, it's going to be difficult. The component's scope needs to access the data which means that either through an argument, through the hidden argument called .this or through a global.

or, of course, as a local variable to that scope, but then good luck sharing it with children or - even worse- other parts of the application

https://reactjs.org/docs/lifting-state-up.html this part of the react docs is the biggest admission of failure (and don't get me wrong, I quite like React, probably would use it even when it's not necessary 🙂 )

after all, the idea of local state is built on the idea of encapsulation from OOP, but if you start moving state up, you by definition break all kinds of OOP principles