This allows immediately disposing the subcomposition which results in removal of the entire subtree without triggering recomposition of the parent composition.
* Create `Mosaic.layoutId`, unit tests for `ParentDataModifier` and fix for `Modifier`s
- New `Mosaic.layoutId` has been created that can be used to define child elements, for example, during the measurement stage
- Add unit tests for `Mosaic.layoutId`
- Add unit tests for `ParentDataModifier`
- Fix the handling of `Modifier`s that were inherited from several key `Modifier` classes (`LayoutModifier`, `DrawModifier`, `KeyModifier`, `ParentDataModifier`) with different handling
- Remove unnecessary call site generic parameter in `RealTestMosaic` and replace `coroutineScope` with getting `CoroutineContext` by `currentCoroutineContext()` function in `runMosaicTest`.
* Update CHANGELOG.md
* Rename
---------
Co-authored-by: Jake Wharton <github@jakewharton.com>
Co-authored-by: Jake Wharton <jw@squareup.com>
- Add `IntrinsicSize`
- Add `Modifier.width`, `Modifier.height`, `Modifier.requiredWidth`, `Modifier.requiredHeight` with `IntrinsicSize` as a parameter
- Add unit tests for intrinsic Modifiers
- Update `SizeModifier` for upstream (df20b2d700)
This now supports testing in all kinds of ways through a single mechanism and pluggable API. We no longer carry bespoke setups solely for testing but instead always use the test harness which is very close to the production behavior.
Rendering is for sending multiple frames to a VT-aware display, and its use only complicates the test harness. Our internal tests are the only ones which should ever need to test VT sequences.
Do not delay to space out frames. Instead, send frames as fast as possible and only render when something changes. This ensures we reflect changes as soon as possible rather than after an artificial delay.
* Launch different phases separately depending on need
A simple implementation that remembers the readings of the states when calling the layout, drawing blocks separately, and then with the help of a global observer checks which states have changed, if those that were read during layout or drawing have changed and composition is not going on now, then we run the layout or drawing phase separately.
Since composition does not occur in case of some changes, therefore, when completed in the `MosaicComposition#awaitComplete` method, we additionally expect one frame to be rendered, if necessary.
* Review fixes
* Back out AndroidX collections
---------
Co-authored-by: Jake Wharton <github@jakewharton.com>
Co-authored-by: Jake Wharton <jw@squareup.com>
Demand for this is low, probably 0. If someone wants for it they can file an issue and we can discuss support further.
Downgrade to Gradle 8.9 because of KT-70700.
- Rename `BaseMosaicComposition` to `MosaicComposition`, and `MosaicComposition` to `RenderingMosaicComposition` (with some changes)
- Use `RenderingMosaicComposition` in `renderMosaic` instead of `mosaicNodes`
- Use `runMosaicTest` in unit tests instead of `mosaicNodes`
- Remove `mosaicNodes`
- Create an `internal` `TestMosaicComposition` interface with the implementation of `RealTestMosaicComposition`
- Add unit tests for synchronous `renderMosaic`