Fix double re-render in LiftWrapper and migrate it to PureComponent

[KatSick]

what was done:

• migrate LiftWrapper to PureComponent
• move LiftWrapper logic to namespace
• slight refactor Render{One,Many}
• eliminate double re-render (because of setState)
• bonus: added focal bench to React + @grammarly/[email protected] benchmark krausest/js-framework-benchmark#889

Context

In the previous LiftWrapper, we used setState method to re-render our component when we subscribe to new props AND initially render our component.
As an example: during the very first render, we start rendering our renderCache as null and then synchronously re-render it via setState . Since by design Focal does need sync observable emit, I optimized first render to render initial observable value without invoking setState reconciliation (via refs).

todo before merge:

• add MR description about the issue and the fix (and change title)
• [not that easy :(]add unit tests for re-renders (currently only renderToStaticMarkup is in unit-tests)
• [no results] investigate, how to test "waste render" in react via unit-tests (see screenshots)
• perform benchmarks
• [it works, but hard to compare values between runs, since they are too small and there is a lot of deviatiosn] investigate elm benchmark

Double re-render fix demo:

Screen.Recording.2021-07-26.at.11.19.14.mov

[Wenqer]

@KatSick benchmark results look awesome! thanks!

@blacktaxi what do you think about those changes? Are we safe to merge it now, or you have any other objections?

[oleksiilevzhynskyi]

Does it make sense to check equality with !structEq(this.renderCache, cache) as well? Just prevent rendering of the same state twice? This probably should be handled by React itself, but for some reason, we do that in the latest version. https://github.com/grammarly/focal/pull/82/files?diff=split&w=1#diff-71010d1ee0e73a76461ec411a47605c1207b1982317b93bd4fdc7c35fb7c6b1fL403

[oleksiilevzhynskyi]

Is it possible to move subscribe into constructor to avoid dependency on legacy lifecycle?

In the article Update on async rendering React team provides two examples about pre-fetch and subscription.

When supporting server rendering, it’s currently necessary to provide the data synchronously – componentWillMount was often used for this purpose but the constructor can be used as a replacement.

The Adding event listener suggest to use componentDidMount with initial value - it's not our case. But, they ok with using componentDidUpdate instead of componentWillReceiveProps

@KatSick what do you think?