Previous change (35ff5d33dd) started using ComponentDidMount to keep
track of component mount order. This affected the order in which this
was called, previously ComponentWillMount was called the first for
parent components and then for children. ComponentDidMount was called
first for children etc. To work around this, the mount order was
reversed when updating components after ratom updates.
Problem with this is, that when only some components are rerendered,
they get new numbers, but their parents don't:
(given components c, b, a)
**0.8.1**
c 1 > b 2 > a 3
a rerendered
c 1 > b 2 > a 4
b rerendered
c 1 > b 5 > a 6
**35ff5d33dd**
c 3 > b 2 > a 1
a rerendered
c 3 > b 2 > a 4 (BROKEN)
b rerendered
c 3 > b 6 > a 5 (BROKEN)
Best way to fix this is to revert back to old way, where parents get the
smaller number, this was re-rendering children doesn't change the order.
To implement this the mount-order can be stored in component
constructor, which seems to work similarly to ComponentWillMount.
> The constructor for a React component is called before it is mounted.
> UNSAFE_componentWillMount()... Generally, we recommend using the constructor() instead for initializing state.
- separate getInitialState and constructor, they work differently
- getDerivedStateFromProps and Error
- getSnapshotBeforeUpdate
- Improved docstring for create-class
WillMount lifecycle method is being deprecated. DidMount can also be
used to capture the mount order. WillMount is called first for top-most
component and last for the children. DidMount is the reverse, first for
children and last the top-most component.
There doesn't seem to be any reason to export this function, and nothing
else is exported. Exporting function also prevents DCE, though in this
case this function probably only adds few bytes as the code include
is anyway used by Reagent applications.
If jsprops was nil before key oset call, oset created a new object for
the jsprops, but because the return value from oset was not used, the
object was lost.