Skip to content

Introduce ModelFactoryProtocol#29

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

Introduce ModelFactoryProtocol#29
gordonbrander wants to merge 1 commit into
mainfrom
2023-03-28-modelfactory

Conversation

@gordonbrander
Copy link
Copy Markdown
Collaborator

@gordonbrander gordonbrander commented Mar 28, 2023

Allows models to be created from a static create function, which returns an update (allowing intial fx to be scheduled).

This also allows for full mocking of the environment for testing in cases where the model's initial state depends upon some synchronous property of the environment.

Encountered the limitation above with current ObservableStore while working on subconsciousnetwork/subconscious#473. Some properties of the app model are initialized from UseDefaults. Ideally, these would be exposed on the environment to allow for mocking in tests.

Fixes #28

Allows models to be created from a static `create` function, which
returns an update (allowing intial fx to be scheduled).

This also allows for full mocking of the environment for testing in
cases where the model's initial state depends upon some syncronous
property of the environment.
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.

Consider generating first state from a factory

2 participants