Skip to content

Conversation

@mbrandonw
Copy link
Member

This PR builds upon #200 (which we will merge soon) in order to start making use of @Shared throughout the code base. The main thing left to do is fix tests.

@mbrandonw mbrandonw requested a review from stephencelis April 8, 2024 20:57
@mbrandonw mbrandonw changed the base branch from main to observation-beta April 8, 2024 21:05
Base automatically changed from observation-beta to main April 9, 2024 19:20

public init(config: ServerConfig = ServerConfig()) {
self.config = config
}
Copy link

@lukeredpath lukeredpath Jul 11, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just an FYI, but after experimenting with this approach of wrapping some shared state in a property wrapper in my app I did find a serious issue with this initializer - it can trigger an infinite view body render loop if invoked from a view body.

This can be easily done, for example if you have some child feature that uses it:

@Reducer
struct Child {
  struct State: Equatable {
    @ObservationStateIgnored @ServerConfig_ var config
  }
}

Then you initialize the child state in a view (e.g. to pass to NavigationLink(state:)), and that view's state also uses the property wrapper, this causes the property wrapper on the child to initialize, which in term updates the shared state, which triggers the parent view to update, which calls body and the loop begins.

I think its better to provide just an empty initializer.

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.

4 participants