Replies: 3 comments
-
|
Hey @ericlewis, thanks for the suggestion. We agree that what you have proposed would be nice to have, but at the same time we have been trying to reduce the number of overloads on certain methods because we believe it is causing compilation problems with very complex SwiftUI views. For example, just recently we renamed an overloaded version of However, this is the first time we have heard of the Thanks again! |
Beta Was this translation helpful? Give feedback.
-
|
@mbrandonw thanks for responding and I totally understand, half of the purpose for opening this issue instead of a PR was so that people could use this idea with the attribute if they wanted- it is used somewhat extensively I think even in SwiftUI itself. I am not necessarily an expert at benching any of this stuff, so any help is appreciated and I didn't feel comfortable pushing a potentially changing API into TCA itself (but do think SwiftUI's usage of it is warranting of paying attention). Edit: it is used extensively https://twitter.com/harlanhaskins/status/1348748033438089216?s=21 |
Beta Was this translation helpful? Give feedback.
-
|
Going to move this to a discussion since it's not a bug. We're still open to make this change in the future, but since it's additive and possible to define it in your own projects, we would want to have folks kick the tires a bit more before making the call. |
Beta Was this translation helpful? Give feedback.
-
Describe the bug
Not exactly a bug, but in some cases would be better if we could curry the
sendto a given viewStore.Usually, when using TCA you must write the following:
or given width requirements:
But it would be nice if you had the option to write the following:
To Reproduce
N/A
Expected behavior
It would be nice to be able to curry sends without the compiler complaining much.
Screenshots
N/A
Environment
N/A
Additional context
The basis for this idea is actually a really simple extension, meaning anyone can go ahead and start using it with the caveat that the attribute is not "stable" in swifts eyes. Below is the extension used:
Most of the work is done by
@_disfavoredOverloadwhich essentially tells the compiler to prefer the normal function over this overload, but when the overload is used the compiler has no qualms using it since the type signatures match and it is now "favored". I have already tested this in my own application and it seems to work well. I do propose it is included natively to TCA, but an extension works fine as well considering the "unstableness" of the attribute.I don't think this really mystifies anything going on, just makes the API simpler and either way works. But I haven't studied the impact to debugging that could occur either.
Beta Was this translation helpful? Give feedback.
All reactions