-
Notifications
You must be signed in to change notification settings - Fork 44
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
Shared + map #138
base: main
Are you sure you want to change the base?
Shared + map #138
Conversation
Hi @arnauddorgans, thanks for exploring this! However, it should not be necessary. extension Child.ID {
subscript(equals other: Self) -> Bool { self == other }
}
$selectedID[equals: id] // SharedReader<Bool> Can you give that a shot and let us know how it works out? |
@mbrandonw hey, yes it works, today I have this extension in my app public extension Equatable {
subscript(isEqualTo other: Self) -> Bool {
self == other
}
} But it feels so unnatural to write a subscript to be able to use it with the library Plus, we can't extend |
@arnauddorgans One wrinkle is that the This means that these 2 shared references are equal: @Shared(.key) var value1
@Shared(.key) var value2
$value1.prop == $value2.prop // true But because the transform function above is not hashable, the implementation uses the object identity, instead, which will not be shared: This means that mapped references will never be equal: @Shared(.key) var value1
@Shared(.key) var value2
$value1.map { $0.prop } == $value2.map { $0.prop } // true It's possible this isn't a big deal with shared readers, but at the same time it's a subtle enough difference from all the existing shared references that it should be carefully considered. I wonder if you can come up with some more edge cases to test and explore considering this mismatch? One other thing that would be good is to get coverage on some actual observation, since that's probably the entire point of such a shared reader. Both tests on |
@stephencelis I don't think the object comparison is a big deal, it is already done for Plus, the Hashable constraint is annoying because it only constrains us to use ![]() I'll try to write some additional tests when I have the time 👍 |
@arnauddorgans The difference is that In the case of |
3198220
to
7640e07
Compare
@stephencelis in my last commit, I deleted the This way I think that everything is working as all the existing shared references So it is totally legit that @Shared(value: 0) var base: Int
@SharedReader var lhs: Int
@SharedReader var rhs: Int
_lhs = $base.map { $0 * 2 }
_rhs = $base.map { $0 * 3 }
#expect(lhs == rhs)
#expect($lhs == $rhs)
$base.withLock { $0 += 1 }
#expect(lhs != rhs)
#expect($lhs != $rhs) |
Adding a
map
method to both Shared and SharedReaderMotivation
Avoid sharing parent feature logic with a child.
E.g.
Note
It could also be cool to add a writable map method, but I don't see the use case today