react-juce: Hot Reload Hang on MacOS

Ahh yea sorry, I skipped right over the z-order question. So z-order is already sort of implemented based on literally the order of react children:

<View>
  <View />
  <View />
  <Modal /> // Move this to the top; the first child of the parent `View` will have the top-most z order
</View>

Implementing a proper z-index property implementation is on the TODO list, and should be quite straightforward: by default we continue with the default z-order behavior (based on the order of the children in the parent), but allow a z-index property (https://developer.mozilla.org/en-US/docs/Web/CSS/z-index) whose behavior is implemented by walking the parent’s list of children and moving the child appropriately using https://docs.juce.com/master/classComponent.html#a1b0cca8b9a9fea673aefc84a42602bcd.

Definitely happy to have you tackle #5 and #4. Same PR is cool with me. For #5 I want to dig into the React HostConfig a little more to see if there really is no “commit” callback, as if to say “we’ve now applied all property updates, commit the update transaction.” That certainly seems like the ideal time to do the layout. If not, I think we should use something like https://docs.juce.com/master/classAsyncUpdater.html to coalesce the updates. For example, if I set width: 100, we enqueue the layout callback via triggerAsyncUpdate. But then maybe another property change for height: 100 comes through and we call that same triggerAsyncUpdate, and if this is all synchronous then the previous pending update will still be sitting there and we get automatic coalescence. Mixing this into the updates from #4 and only triggering the async update if the set of properties changed involved layout-related properties seems like the big winner.

I’ll take a look at the PR now, thanks so much for digging into it. I want to spend some time as well playing with Duktape, lightfuncs, and exploring this GC thing and “transient” function stack objects. I’ll write back if I find anything

@nick-thompson,

No Problem! It’s been massively valuable to dig into this. I found the causes for my wasted reconciles. Indeed, I reckon the PureComponent idea might be worth spattering around my code base to assist when others make similar mistakes etc.

The idea around CanvasContext is interesting, I totally agree. I wondered about the whole “light function” thing and whether that is some we could somehow leverage but I’m still not sure yet. I did briefly experiment with having a single CanvasContext registered as a global property, it sort of worked with much odd behaviour, basically ReactApplicationRoot owned the instance and passed it into the CanvasView’s constructor. I don’t think that’s a particularly good idea though.

I’ll muse over the “transient” function objects idea too once I’ve gotten other tasks out of the way … that does feel like the right approach, maybe even coupled with the “light-function” facility. If we can distinguish these “transient” function objects it feels like light-functions might be a very good idea, I suspect they could improve performance for this sort of thing dramatically (if there is indeed no associated GC etc).

If we could workout someway for things like canvas onDraw calls running on timers to put less stress on the GC I think that would be a HUGE win. The performance is actually looking really good around all of this now.

I’ll get the unordered_set fix over to you and deal with #5 as a start.

😁 good luck! I haven’t had a chance to dig in yet; hope it’s not too gnarly