Clojurians Log v2

Having a blast with concurrent mode. Heads up - the latest builds prefixed everything with unstable_ because apparently people are already using this in libraries with polyfills 🤦

I need to find some demo code that would exhibit tearing without useMutableSource just to see what it looks like. Hard to evaluate this stuff in trivial apps.

@orestis can you help me a bit with my experiment? : )

https://github.com/ashnur/sierpinski-cljs-fiber-demo this one

One very very very interesting pattern which emerges is the useTransition hook. You are supposed to wrap state changes that will trigger a suspense with this. They demo this by putting in directly in a click handler, but that seems the wrong place. But dispatching a reframe-like event feels also the wrong place to deal with that, if you’re doing sync state updates as I’m doing. So it feels like the event router needs to know which events might trigger suspense.

I think I need to build a proper application with this to get a proper feeling. Any suggestion public APIs I can use to get interesting dummy data and images is welcome.

the app I’ve been using to experiment is a hacker news reader

in the spirit of https://hnpwa.com/

@ashnur I have a holiday long weekend ahead with family stuff so no promises :) one obvious thing I see is that you’re calling render on the root to step forward the simulation. That seems wrong (though I’m not sure). I’d use a useEffect on the top level component to start the loop and a setState call to let React rerender as needed.

I just need someone to check for obvious mistakes why the code is slow

@lilactown meh, hacker news :) in this period I want something with baby goats

hahahaha fair

Baby goat api in google doesn’t give promising results :)

@ashnur see above, that’s the first thing I’d try.

thanks

afaik, calling render on the root should not make a difference compared to calling this.setState on the root

and the original was written in this style exactly

Some context in what you trying to test might be useful :)

I just want to make the demo go fast at this point in time : D

Yeah but for what? Testing CLJS performance, react performance? CLJS will be always slower than JS for sure. By how much, well, 🤷

Ok, I think I understand your question. It's a series, one built on the other. First, I subscribed very early on CM and would like to know if it is still as good as it was in 2016, so I would like to see the same performance benefits demonstrated with latest experimental code, otherwise it might've been a one time fluke. Second, I also believe that most of the performance, if React is still as good as it was 4 years ago, comes from the reconciler and I should be able to just feed global state to it without slow down, but this will require custom code that I need to still write, after the first step is over. Third, well, that's even more work, it involves a lot of specs.

The sierpinski stuff shouldn't be any slower even in cljs, I don't know anything that would warrant it. Sure, if I use complex datastructures then the overhead might be significant, but that's a question for future me.

Ok that makes it clearer :) I’m on my phone so can’t do much analysis. Why are you creating fragments around the children of the triangle? Wouldn’t passing in the text as a prop make things clearer?

I mean you probably don’t need fragments anyway

good point

I haven’t used helix yet so I can’t comment much more without actually running the code locally...

oh, I thought you had, sorry about that

What’s the js version look like? Perhaps something will jump out on direct comparison.

in the public dir, there is fiber.html that has the original version, but you can check it here too https://claudiopro.github.io/react-fiber-vs-stack-demo/

original returned an array, but I don't know if I can just do (vector ($) ($) ($))

as for the children, I probably was too tired

That fiber is probably using a much older version of React. You need to wrap the three returned triangles in a fragment, but their children shouldn’t be wrapped in a fragment.

In the fiber demo the triangles use key (left right center) which can impact performance greatly.

Finally I’d double check the memo wrap - not sure if it works out of the box, I’d add some debugging there to see what it does.

it doesn't appear to do anything. You are right about the keys, I forgot to add them

what I don't understand is the createRoot thing, I am afraid I still re-create it too often. Because at every update for the text in the dots, the animation freezes a bit, exactly like in Sync/Legacy mode

I was just reading about keys in react, I always thought it’s just for arrays but apparently not. https://kentcdodds.com/blog/understanding-reacts-key-prop

yeah, it's a bit like the order for hooks

You only create the root once. I think I saw warning when calling render multiple times, might be a recent thing.

Recent: today’s experimental build.

dunno, I have code to check if the root doesn't exist so I can create it again, I think 😄

let me check again, I just started

I might remember wrong. I need to log off now. If I have time over the long weekend I might play around.

thanks for helping out!

well, if what I got now is not tearing, I don't know what 😄 I have two versions rendered at once, both wrong

yea this has saved me a few times in cases where components were poorly composed and had to make sure they rerender

so, I cut some corners too early, I should update my code

but, good news, I found it in the official repo https://github.com/facebook/react/blob/master/fixtures/fiber-triangle/index.html bad news, 2 years old 😄

so, one thing is sure, you can still block react experimental while using createRoot API, more than one way. With the old API afaik you could block the window but not react