Closed TobyEalden closed 7 years ago
No response at all?
Took some time and effort to put together that example. That's an hour of my life I'll never get back!
For what its worth Toby, I thought your example was wonderful. =P
I'm sure the team is just super busy.
Hope you get an answer soon.
@TobyEalden Sorry for the late answer. We know this will be fixed with 2.x See: https://github.com/kadirahq/react-komposer/issues/123
This is fixed with v2 and I've released it. Check the section on Performance.
See https://github.com/TobyEalden/komposer-weirdness for example/reproduction.
I may have misunderstood the intention of composeAll, but even if that's the case, it appears to behave differently on the first render compared to when a property changes.
It seems that after the initial render, any property change will re-run ALL composers and the final component before the onData is called.
This means that when a property is updated, the top-level composer will run and so will the next level composer and so will the render method on the component, all BEFORE the onData of the top-level composer has run. When the top-level composer is ready and calls onData, the next level composer will run again and the component will also render BEFORE the composer calls onData. Finally when the last composer calls onData the component will render again - that's 3 times for one property change.
When first run, the output below is produced as expected.
After hitting the update button, which triggers a prop change, the output becomes:
It's possible to add shouldComponentUpdate to avoid the extraneous renders, but there's no clean way to prevent the last composer from running multiple times (and potentially duplicating expensive data fetch operations, e.g. http.get instead of setTimeout) without breaking the pattern.
A workaround is to call onData twice from composer2 - initially passing null as the c2Data value, and changing composer1 to check for null before calling setTimeout (fetching data).
e.g.
I'm guessing this is by design given the fundamental nature of it, but am I missing something?