Both React’s incremental reconciler and Angular’s digest cycle have the property that additional work will be scheduled outside of the consumers control.
Arguably with React this has always been true and the incremental reconciler is simply another layer for scheduling work.
To date, React’s reconciler has been an implementation detail that I’ve never had to consider while developing applications. Neither have I ever heard someone say “well that’s just how the reconciliation works” or “fighting the reconciliation engine”. Contrast this to angular where the digest cycle is a constant thorn the developer must be aware of and combat excessively.
My question/concern is will the incremental nature of the new reconciler leak through to the consumer? Will this continue to stay a black box that just works or will public APIs and components need to account for this in some capacity?
This was the initial thought experiment I had while considering possible correlations between the digest cycle and the incremental reconciler.
Will the incremental reconciler make certain properties of React’s initial mounting unpredictable? I do not currently hold any reservations about the incremental reconciler’s impact on scheduled reconciliations in response to user actions.
Use cases:
- ReactResolver recursively resolves all
ReactDOM.renderToStringcalls to do server-side rendering once all side-effects of mounting have been resolved. - RUM tracking when the initial render is complete.
Regarding server-rendering with ReactResolver (and similar solutions), this may be drastically simplified or improved. ...especially if there is overlap between the incremental reconciler and streaming server.
Regarding the RUM tracking, this is also likely no different than the case today where you need to measure this based on all the leaves being rendered which is difficult to do statically. Rather, marking when major segments of the UI are rendered likely makes more sense.