Skip to content

Model factory start#31

Closed
gordonbrander wants to merge 1 commit into
mainfrom
2023-03-29-modelfactory-start
Closed

Model factory start#31
gordonbrander wants to merge 1 commit into
mainfrom
2023-03-29-modelfactory-start

Conversation

@gordonbrander
Copy link
Copy Markdown
Collaborator

This PR illustrates a conceived-of solution to #28. The notion is to implement a ModelFactoryProtocol that implements a static start(state: Self, environment: Self.Environment) -> Update<Self>. Essentially an opportunity to "decorate" a model and produce effects.

However, the approach may not be ideal because models that initialize properties from environment still be required to have initial values for initializing BEFORE passing to start. Its really not too different from the init(state:action:environment:) convenience initializer in this way.

gordonbrander added a commit that referenced this pull request Apr 3, 2023
Introduce `init(create:environment:` convenience initializer.

Remove `init(update:action:environment:` convenience initializer.

This is an alternative to #29 for cases where we need to initialize store from an `Update`. Instead of introducing a `ModelFactoryProtocol`, we introduce a convenience initializer that takes a `create` closure.

An advantage here is that we do not have to create a `flags` type for customizing the model construction process. Instead, because we can choose which factory function is passed to `create`, we can create one-off closure factories that set the necessary properties on the model for a given view.

Additionally, this approach does not require us to specify the type signature of the Store, since Swift is able to infer the store type from the function's return type.

Fixes #28

Alternatives considered:

- #31
- #29.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant