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
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.
Component could be plain JS object with some private React properties,
and it is not easy to check for this. Instead just allow all value for
:> but check that React will throw error from createElement.
Fixes#369
Custom HTML element property name code accidentally modified cache
object for normal HTML elements, which can cause Reagent to lose correct
mappings for properties like className, htmlFor and charSet.
This removes the interop macros which used aget/aset and prevented
Closure naming mangling, now normal property and method access is used
where possible, and goog.object used when using variable keys. Further
testing is needed to ensure this works correctly with Closure, as there
are some properties that are used with goog.object in one place, and as
property in another.
Fixes#324