Clojurians Log v2
rum
@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
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