* [ASDataController] Add some assertions to clarify what queues things happen on
* [ASCollectionDataController] Optimize willReloadData
* [ASDataController] Minor optimizations, no functional changes
* [ASDataController] Always reload data on _editingTransactionQueue
* [ASDataController] Remove async data fetching option, deprecate callbacks
* [ASDataController] Not mutable
* [ASMultidimensionalArrayUtils] Use fast enumeration
* Optimize ASMultidimensionalArrayUtils
* Don't relayout as a result of clearing a traitCollection's context
I'm not completely sure this change is the best solution. Here is context:
An ASEnvironmentTraitCollection has a pointer to an optional context that an ASVC is the owner of. When the ASVC is dealloc'ed, we go through all subnodes of the VC and clear out the context so that the struct isn't holding on to a garbage pointer.
Setting the traitCollection on ASCollectionNode/ASTableNode causes the cells to relayout if the trait collection changed (this is a special case for these two nodes since their cells are not actually subnodes). Setting the context to nil registered as a trait collection change and was causing a layout even as we were dealloc'ing the VC.
The logic I'm implementing here is:
If the trait collection changed AND the displayContext did not, then we should relayout.
If the trait collection changed AND the new displayContext is non-nil then we should layout
In the case where the trait collection change was caused soley by the displayContext going from non-nil to nil, then we should NOT layout.
```
// At this point we know that the two traits collections are NOT equal for some reason
BOOL needsLayout = (oldTraits.displayContext == currentTraits.displayContext) || currentTraits.displayContext != nil;
```
Is there a better place/safer way to do this?
* removed extra setNeedsLayout call
* Fix some concurrency problems detected by Xcode 8's new Thread Sanitizer.
Some of these changes are arguably just to silence the warnings from Thread Sanitizer.
* Fix several memory leaks in the unit tests.
A number of the unit test source files are compield with `-fno-objc-arc`. This was clearly overlooked when writing several of the unit tests.
Fixed by (mostly) switching to use of `-autorelease` for the problem code.
NOTE: This commit doesn't fix all the memory leaks found. There's still at least one leak in `-[ASDisplayNodeTests testSetNeedsDataFetchImmediateState]`, and several leaks in `ASBasicImageDownloader.mm`. I wasn't able to find a trivial cause to these, unfortunately.
Currently within `ASCollectionView`, there is an assumption that there will always be a static number of supplementary views per section—even when additional items are added or removed from that section. This is evidenced by the fact that when you invoke -[ASCollectionView insertItemsAtIndexPaths:], the data source method -[ASCollectionDataSource collectionView:nodeForSupplementaryElementOfKind:atIndexPath:] is not invoked, preventing consumers from specifying a new number of supplementary nodes for the new set of items.
With this change, the set of supplementary nodes for a section is now recalculated not only on section-level mutations, but also on item-level mutations as well. This adds item-level counterparts to the section-level `-prepareFor...` subclassing hooks in `ASDataController+Subclasses.h` to make this possible.
This should fix#1278 and #1322
This has been tested in my project and seen to fix the assertion. Open to suggestions on how to test in a more universal way.
* 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
- Mutating a dictionary using -enumerateKeysAndObjectsUsingBlock:
can have unintended consequences.
- Using a copy of the keys to iterate over the values inside the
dictionary instead.
