New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Performant way to using StateReader #168
Conversation
|
||
/** Not working */ | ||
@available(iOS 13, *) | ||
final class StateReaderTests: XCTestCase { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried.
but I could not run SwiftUI's view on XCTest.
@@ -0,0 +1,94 @@ | |||
// | |||
// ContentView.swift |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A demo application to check the behavior of StateReader
8e1d223
to
b9cc1ef
Compare
*/ | ||
@available(iOS 13, macOS 10.15, tvOS 13, watchOS 6, *) | ||
public struct StateReader<Value, Content: View>: View { | ||
public struct StateReader<Value>: View { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
StateReader is going to be new API
public var body: EmptyView { | ||
assertionFailure(""" | ||
Warning: StateReader still does not have a content-view. | ||
Please add a content by `.content()`. | ||
|
||
This issue comes from current auto-completion function doesn't work well. | ||
Probably, it's might be fixed with better syntax. | ||
""") | ||
return EmptyView() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
here is not cool part
public func content<NewContent: View>(_ makeContent: @escaping (Changes<Value>) -> NewContent) -> _StateReaderContent<Value, NewContent> { | ||
return .init(updateTrigger: observableObject, updateValue: updateValue, content: makeContent) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to call this to describe content view
/// - content: | ||
public init<Derived: DerivedType>( | ||
_ derived: Derived, | ||
_ map: MemoizeMap<Changes<Derived.Value>, Value>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Passing MemoizeMap causes the complexity of auto-completion and verbosity of signature.
In most of the cases, it's enough passing Derived object.
If we need to create chained Derived, pass the chained Derived from outside.
6896002
to
716ffcf
Compare
716ffcf
to
1f7da19
Compare
} | ||
|
||
@available(*, deprecated, message: "You're returning a value which is not a type of `SwiftUI.View`.") | ||
public func content(_ makeContent: @escaping (Changes<Value>) -> Never) -> Never { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This method is dummy just for Xcode
For better performance, to reduce creating view structure in body property as possible.
We suggest you use Derived object as possible instead of directly passing a Store into StateReader.
The derived object can focus on properties that you need inside StateReader, and emit events of request view update only their changed.
In using the store directly, StateReader also updates itself from the events of unused properties changed.
To solve:
#160
And It contains also writing issues in Xcode.
#165
Before
After