Question: optimisation of the render cycle for stateless components about render HOT 3 CLOSED

Hello! Really happy to know that Render works for you guys.
I've pushed 799385a today that should mirror React's shouldUpdateComponent.

You should be able to skip the component reconfiguration by simply adding override ovveride var shouldUpdate: Bool { return false } in your UIComponent subclass.

note: The render method is still going to be called per se, but just to keep the vdom in sync, no UIView hierarchy manipulation will take place.

from render.

Just had a read through and a go with the shouldUpdate implementation - the main aspect I can see it lacking against the React equivalent is that it doesn't necessarily catch the props on the way in for a comparison.

What I've done with a couple of components is add a property observer to the props which sets and stores an Optional of the last props we saw - shouldUpdate then is overridden to return a comparison from the last props vs the current ones. As said - we aren't strictly dealing with equatables in the props so this gives us a chance to do more complex logic to determine whether we should(n't) update.

Given the structure that could be easily added into the Component classes, but I've yet to properly test and see if we are actually saving time and update counts as a result. I'll let you know when I have something.

For consideration too - I've been looking at whether it would be simple to implement a means for a child to update in isolation. I'm thinking of the trivial things like a button which changes colour on a state change and then calls setNeedsRender on itself - isolating prop changes to children could be easy but layouts might be harder given a child may grow. Is there any optimisation around that which I've missed? My goal is to not have to do a layout() run over the whole view if I can be sure its not needed.

from render.

Just to let you know where we got to with the new shouldUpdate - we were hoping that we'd be able to completely isolate a section of the tree from the layout aspect more than anything - our cycles currently have layout taking ~10x the time of diff/reconcile.

Edited: Urgh no - apologies. My debugger stack pointed me in some odd directions there. I can see a non-root component returning false for shouldUpdate and all the children reporting false, as they should. This should mean that even though markDirty should not be being called for this node and its children, it appears that Yoga still spends time doing the layout on them (as we only see improvements to layout time when the node is completely omitted from the tree).

I might read up on Yoga and how it handles its own updates before asking any more silly questions

from render.