Skip to content
This repository was archived by the owner on Feb 5, 2021. It is now read-only.

[DNM] Introduce ViewFactoryTransformer with vibrating demo effect. #28

Draft
wants to merge 28 commits into
base: weekend-features
Choose a base branch
from

Conversation

zach-klippenstein
Copy link
Collaborator

@zach-klippenstein zach-klippenstein commented May 17, 2020

Adds a ViewRegistry wrapper that will apply a Compose Modifier to each ViewFactory in the original ViewRegistry. These modifiers can be animated, so this also includes a simple vibrating effect that randomly vibrates each factory. But this technique could be used to create a 3D "exploded" view of all the layers, like this demo.

ezgif com-resize

@zach-klippenstein zach-klippenstein force-pushed the zachklipp/factory-transformer branch from 66a9c80 to 87afb4f Compare May 18, 2020 16:43
zach-klippenstein and others added 27 commits May 18, 2020 12:21
…ComposeViewFactoryRoot.

This ensures that the root will be applied in all code paths:
 - Entering the Compose world through a `WorkflowViewStub`/`ComposeViewFactory`.
 - Already in Compose, showing a rendering from a `WorkflowContainer`.

This change also ensures that if the `ComposeViewFactoryRoot` is changed above where it's applied,
the new wrapper will be applied. Adds tests for this and other logic.

Fixes #20.
Make ViewFactory.showRendering function responsible for applying the ComposeViewFactoryRoot.
Most of the tests in this repo are UI tests, so it would be really nice to not build the entire codebase twice to start running them.

I decreased the timeout as well since test shards no longer need to re-build.
Update README with dependency instructions for v0.29.0.
…nnecessary intermediate Views.

This is effectively the logic of `WorkflowViewStub`, but translated into Compose idioms.
This approach has a few advantages:

 - Avoids extra custom views required to host `WorkflowViewStub` inside a Composition. Its trick
   of replacing itself in its parent doesn't play nice with Compose.
 - Allows us to pass the correct parent view for inflation (the root of the composition).
 - Avoids `WorkflowViewStub` having to do its own lookup to find the correct [ViewFactory], since
   we already have the correct one.

Like `WorkflowViewStub`, this function uses the `ViewFactory` to create and memoize a `View` to
display the rendering, keeps it updated with the latest `RenderingT` and `ViewEnvironment`, and
adds it to the composition.
Inline WorkflowViewStub logic in ViewFactory.showRendering to avoid unnecessary intermediate Views.
Rename bindCompose to composedViewFactory.
…dering

Bug fix: Make ViewRegistry.showRendering update if ViewRegistry changes.
…n function.

Fixes #21, see that issue for rationale.
Rename showRendering to WorkflowRendering and make it not an extension function.
…mplementation.

The root is now applied via a `ViewRegistry` wrapper that wraps individual factories
to apply the root, instead of having this logic hard-coded inside `ComposeViewFactory`.

This approach is more flexible in general (could be used to do other tricks), and decouples
the rooting feature from the rest of the code.
Renames ComposeViewFactoryRoot to CompositionRoot and decouples the implementation.
…ent.

This narrows the scope of `WorkflowContainer` to be only for showing a workflow's renderings
using a `ViewEnvironment`. This elimnates the need to have separate overloads for workflows
with rendering type `ComposeRendering`, and is more idiomatic – the old `WorkflowContainer`
wasn't a "container" in any Compose-y sense of the word, and it was really weird that it took
a content function. Now this composable is actually a container for all workflow-related
composables, and so I think the name is actually appropriate (closes #22).

To render a workflow without a `ViewEnvironment`, `renderAsState` is now public. This is also
much more idiomatic, as it resembles APIs like `Flow<T>.collectAsState` and
`Observable.subscribeAsState`.
Make renderAsState public, make WorkflowContainer take a ViewEnvironment.
@zach-klippenstein zach-klippenstein force-pushed the zachklipp/factory-transformer branch from 87afb4f to d6a15f2 Compare May 30, 2020 02:33
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant