WorkflowContext.compose shouldn't have to know child workflow's state type. #213
Assignees
Labels
Milestone
Comments
zach-klippenstein
added a commit
that referenced
this issue
Mar 26, 2019
zach-klippenstein
added a commit
that referenced
this issue
Mar 27, 2019
zach-klippenstein
added a commit
that referenced
this issue
Mar 27, 2019
…orkflow (now StatefulWorkflow). Closes #213.
This was referenced Mar 27, 2019
Factor out a common parent interface for StatelessWorkflow and Workflow (now StatefulWorkflow).
#219
Merged
zach-klippenstein
added a commit
that referenced
this issue
Mar 27, 2019
zach-klippenstein
added a commit
that referenced
this issue
Mar 27, 2019
…orkflow (now StatefulWorkflow). Closes #213.
zach-klippenstein
added a commit
that referenced
this issue
Mar 27, 2019
…ow (now StatefulWorkflow). tl;dr: - `Workflow` -> `StatefulWorkflow` - `Workflow` is an interface, `StatefulWorkflow` and `StatelessWorkflow` are abstract classes that both implement `Workflow`. This change makes it much easier for consumers of this library to define public APIs with private implementations. The public API is an interface that extends `Workflow`. The private implementation is a class that subclasses either `StatefulWorkflow` or `StatelessWorkflow`, depending on whether it needs to keep track of any state. Either way, the workflow's state type is kept as a completely private concern. `interface Workflow<I, O, R>` ----------------------------- This is the main currency of this library. `Workflow`s can compose other `Workflow`s. A `Workflow` is anything that can be expressed as a `StatefulWorkflow`. It has a single method, `asStatefulWorkflow()`, that is responsible for expressing the workflow in terms of a `StatefulWorkflow` – a workflow that has an internal state. This commit renames what used to be `Workflow` to `StatefulWorkflow`. `abstract class StatefulWorkflow<I, S, O, R>` --------------------------------------------- This is what you subclass to write a `Workflow` that has internal state that persists as long as the workflow is active in its parent. It knows about things like initial state and snapshotting/restoring. `abstract class StatelessWorkflow<I, O, R>` ------------------------------------------- This is what you subclass to get a `Workflow` that only has a single `compose` method. It can compose children workflows, transform inputs/outputs/renderings up/down the tree, and listen to external events and subscriptions, but it has no state. Closes #213.
zach-klippenstein
added a commit
that referenced
this issue
Mar 27, 2019
…ow (now StatefulWorkflow). tl;dr: - `Workflow` -> `StatefulWorkflow` - `Workflow` is an interface, `StatefulWorkflow` and `StatelessWorkflow` are abstract classes that both implement `Workflow`. This change makes it much easier for consumers of this library to define public APIs with private implementations. The public API is an interface that extends `Workflow`. The private implementation is a class that subclasses either `StatefulWorkflow` or `StatelessWorkflow`, depending on whether it needs to keep track of any state. Either way, the workflow's state type is kept as a completely private concern. `interface Workflow<I, O, R>` ----------------------------- This is the main currency of this library. `Workflow`s can compose other `Workflow`s. A `Workflow` is anything that can be expressed as a `StatefulWorkflow`. It has a single method, `asStatefulWorkflow()`, that is responsible for expressing the workflow in terms of a `StatefulWorkflow` – a workflow that has an internal state. This commit renames what used to be `Workflow` to `StatefulWorkflow`. `abstract class StatefulWorkflow<I, S, O, R>` --------------------------------------------- This is what you subclass to write a `Workflow` that has internal state that persists as long as the workflow is active in its parent. It knows about things like initial state and snapshotting/restoring. `abstract class StatelessWorkflow<I, O, R>` ------------------------------------------- This is what you subclass to get a `Workflow` that only has a single `compose` method. It can compose children workflows, transform inputs/outputs/renderings up/down the tree, and listen to external events and subscriptions, but it has no state. Closes #213.
zach-klippenstein
added a commit
that referenced
this issue
Mar 27, 2019
…ow (now StatefulWorkflow). tl;dr: - `Workflow` -> `StatefulWorkflow` - `Workflow` is an interface, `StatefulWorkflow` and `StatelessWorkflow` are abstract classes that both implement `Workflow`. This change makes it much easier for consumers of this library to define public APIs with private implementations. The public API is an interface that extends `Workflow`. The private implementation is a class that subclasses either `StatefulWorkflow` or `StatelessWorkflow`, depending on whether it needs to keep track of any state. Either way, the workflow's state type is kept as a completely private concern. `interface Workflow<I, O, R>` ----------------------------- This is the main currency of this library. `Workflow`s can compose other `Workflow`s. A `Workflow` is anything that can be expressed as a `StatefulWorkflow`. It has a single method, `asStatefulWorkflow()`, that is responsible for expressing the workflow in terms of a `StatefulWorkflow` – a workflow that has an internal state. This commit renames what used to be `Workflow` to `StatefulWorkflow`. `abstract class StatefulWorkflow<I, S, O, R>` --------------------------------------------- This is what you subclass to write a `Workflow` that has internal state that persists as long as the workflow is active in its parent. It knows about things like initial state and snapshotting/restoring. `abstract class StatelessWorkflow<I, O, R>` ------------------------------------------- This is what you subclass to get a `Workflow` that only has a single `compose` method. It can compose children workflows, transform inputs/outputs/renderings up/down the tree, and listen to external events and subscriptions, but it has no state. Closes #213.
zach-klippenstein
added a commit
that referenced
this issue
Mar 27, 2019
…ow (now StatefulWorkflow). tl;dr: - `Workflow` -> `StatefulWorkflow` - `Workflow` is an interface, `StatefulWorkflow` and `StatelessWorkflow` are abstract classes that both implement `Workflow`. This change makes it much easier for consumers of this library to define public APIs with private implementations. The public API is an interface that extends `Workflow`. The private implementation is a class that subclasses either `StatefulWorkflow` or `StatelessWorkflow`, depending on whether it needs to keep track of any state. Either way, the workflow's state type is kept as a completely private concern. `interface Workflow<I, O, R>` ----------------------------- This is the main currency of this library. `Workflow`s can compose other `Workflow`s. A `Workflow` is anything that can be expressed as a `StatefulWorkflow`. It has a single method, `asStatefulWorkflow()`, that is responsible for expressing the workflow in terms of a `StatefulWorkflow` – a workflow that has an internal state. This commit renames what used to be `Workflow` to `StatefulWorkflow`. `abstract class StatefulWorkflow<I, S, O, R>` --------------------------------------------- This is what you subclass to write a `Workflow` that has internal state that persists as long as the workflow is active in its parent. It knows about things like initial state and snapshotting/restoring. `abstract class StatelessWorkflow<I, O, R>` ------------------------------------------- This is what you subclass to get a `Workflow` that only has a single `compose` method. It can compose children workflows, transform inputs/outputs/renderings up/down the tree, and listen to external events and subscriptions, but it has no state. Closes #213.
zach-klippenstein
added a commit
that referenced
this issue
Mar 27, 2019
…ow (now StatefulWorkflow). tl;dr: - `Workflow` -> `StatefulWorkflow` - `Workflow` is an interface, `StatefulWorkflow` and `StatelessWorkflow` are abstract classes that both implement `Workflow`. This change makes it much easier for consumers of this library to define public APIs with private implementations. The public API is an interface that extends `Workflow`. The private implementation is a class that subclasses either `StatefulWorkflow` or `StatelessWorkflow`, depending on whether it needs to keep track of any state. Either way, the workflow's state type is kept as a completely private concern. `interface Workflow<I, O, R>` ----------------------------- This is the main currency of this library. `Workflow`s can compose other `Workflow`s. A `Workflow` is anything that can be expressed as a `StatefulWorkflow`. It has a single method, `asStatefulWorkflow()`, that is responsible for expressing the workflow in terms of a `StatefulWorkflow` – a workflow that has an internal state. This commit renames what used to be `Workflow` to `StatefulWorkflow`. `abstract class StatefulWorkflow<I, S, O, R>` --------------------------------------------- This is what you subclass to write a `Workflow` that has internal state that persists as long as the workflow is active in its parent. It knows about things like initial state and snapshotting/restoring. `abstract class StatelessWorkflow<I, O, R>` ------------------------------------------- This is what you subclass to get a `Workflow` that only has a single `compose` method. It can compose children workflows, transform inputs/outputs/renderings up/down the tree, and listen to external events and subscriptions, but it has no state. Closes #213.
zach-klippenstein
added a commit
that referenced
this issue
Mar 27, 2019
…ow (now StatefulWorkflow). tl;dr: - `Workflow` -> `StatefulWorkflow` - `Workflow` is an interface, `StatefulWorkflow` and `StatelessWorkflow` are abstract classes that both implement `Workflow`. This change makes it much easier for consumers of this library to define public APIs with private implementations. The public API is an interface that extends `Workflow`. The private implementation is a class that subclasses either `StatefulWorkflow` or `StatelessWorkflow`, depending on whether it needs to keep track of any state. Either way, the workflow's state type is kept as a completely private concern. `interface Workflow<I, O, R>` ----------------------------- This is the main currency of this library. `Workflow`s can compose other `Workflow`s. A `Workflow` is anything that can be expressed as a `StatefulWorkflow`. It has a single method, `asStatefulWorkflow()`, that is responsible for expressing the workflow in terms of a `StatefulWorkflow` – a workflow that has an internal state. This commit renames what used to be `Workflow` to `StatefulWorkflow`. `abstract class StatefulWorkflow<I, S, O, R>` --------------------------------------------- This is what you subclass to write a `Workflow` that has internal state that persists as long as the workflow is active in its parent. It knows about things like initial state and snapshotting/restoring. `abstract class StatelessWorkflow<I, O, R>` ------------------------------------------- This is what you subclass to get a `Workflow` that only has a single `compose` method. It can compose children workflows, transform inputs/outputs/renderings up/down the tree, and listen to external events and subscriptions, but it has no state. Closes #213.
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
This was only required back when we internally keyed off of the tuple of type parameters. Since we use the actual
KClassofWorkflowimplementations now, we don't need to care anymore.The text was updated successfully, but these errors were encountered: