This situation is relatively uncommon. If a user manually uses -[UIView addSubnode:], the convenience category method,
and then calls -[ASDisplayNode removeFromSuperview] -- we would bypass performing the actual removal as no supernode pointer
is set. After further consideration, the special handling here to support divergence between the supernode pointer and
the view / layer hierarchy is not something we need to maintain going forward, and removing it makes addressing this easy.
I looked into the internals of UIImageView a bit. I would recommend to not fixing this in a universal way. UIImageView is specifically optimized for performance and does not use the usual way to provide the contents of the CALayer that backs the UIImageView.
Furthermore we cannot trigger a recreation of the contents of the UIImageView layer as if it get’s cleared and we call setNeedsDisplay on it it goes trough the normal flow to assign the contents to a layer via the CALayerDelegate methods. Unfortunately UIImageView does not do it, it actually does not implement some of the methods at all, so nothing will show up. It’s getting better, by calling setNeedsDisplay on an UIImageView layer it actually clears the contents and nothing is visible anymore. So we have to be careful to not calling that too.
Unfortunately I didn’t find a way yet to trigger a recreation of the UIImageView layers content except calling the private _updateState method.
That said it’s different for layers of other UIKit components like UILabel for example. Clearing the contents of a UILabel layer and calling setNeedsDisplay on the layer usually recreates the contents of the it and it will show up again.
This commit prevents to clear the contents of a layer for all wrapped UIKit and instead only NOT clear the content if the node wraps a UIImageView otherwise we should clear the contents of the layer to reclaim memory as usual.
If a developer makes this error, it would prevent calls to key lifecycle methods, such as -layoutSpecThatFits:.
Although the superclasses of ASDisplayNode do not implement +initialize, a super call is added here for consistency.
Normally measure will be called before layout occurs. If this doesn't happen, nothing is going to call it at all. An experimenting developer probably added a node to the hierarchy directly. We simply call measureWithSizeRange: using a size range equal to whatever bounds were provided to that element. This make initial experimentation using layoutSpecs much easier. Furthermore added logging if no size is given for the node before layout occurs.
* make variable naming reflect ASEnvironmentTraitCollection vs ASTraitCollection
* move trait propagation to cell allocation instead of via a nested block
* move trait propagation when setting a displaynode's supernode instead of when adding a subnode
* fixed misspelling of "colection"
* Fixed bug in `ASEnvironmentMergeObjectAndState`
* New ASLayoutSpec methods for `setChild`/`setChildren`/`setChild:forIdentifier:` have been added to take in a trait collection.
* Added `setChild:`-like methods for ASLayoutSpecs take a traitCollection
* Fixed instances where nodes in a data controller were not getting their trait collections
* propagate traitCollection in ASDisplayNode on insertSubnode or addSubnode
Initial attempt to get display traits working with ASEnvironment.
To get proper ASDisplayTraits support, you must use an ASViewController. The ASViewController implements UITraitCollection-related methods (`traitCollectionDidChange:`, `willTransitionToTraitCollection:withTransitionCoordinator:`, viewWillTransitionToSize:withTransitionCoordinator`) to update the internal ASDisplayTraits and propagate them to subnodes.
ASTableNode and ASCollectionNode don't actually have their cells as subnodes, so a little bit of trickery is involved (on `setEnvironment:` the table/collection node gets its data controllers completedNodes and propagates the new traits. see `ASDisplayTraitsCollectionTableSetEnvironmentState`). The data controller also passes the current display traits when creating new cells.
ASViewController also supports the ability to return a custom set of display traits. So if you have a modal dialog that should always be told it is in a compact size class, you can set the override block before displaying the VC.
A new example, called Display Traits, has been added. It shows how display traits can be used in a ASViewController with a normal ASDisplayNode as its root, as well as in ASViewControllers hosting table nodes and collection nodes. There is also an example of overriding the default display traits of a VC.
Please provide feedback!
