Definitely comes down to preference – I'd rather not have the machinery there if I'm not planning on using it. (Although, in practice this is what I'm forced to do.)
The other big issue is that you can't retroactively add Observable to an existing class/3rd party library.
Hmmm, I'm not sure it's so clear cut! The alternatives are to a) create a regular EnvironmentValue and force unwrap the reference, or b) Just conform your service to Observable anyway and then hope you remember to opt-out of observation where necessary (which seems equally foot-gun prone!)
Yes, I think we're talking about slightly different use cases. I'm talking about something like this:
gist.github.com/tcldr/965510...
(To be clear, I’m talking specifically about types/dependencies where you don’t intend to observe any state, just call methods on or pull state in the context of an action.)
Shouldn’t do, because even with an Observable reference, changes to the environment reference do seem to cause the view to recompute. AFAICT, this has nothing to do with the Observable type, just the Environment property wrapper doing its job.
I’m still not quite sure why we can’t use this mechanism for non-observable reference types, too.
They baited the industry flawlessly. Hats off to Jaguar. One for the marketing textbooks.
Everyone wetting their pants about a not great Jaguar teaser can eat sh*t (The Daily Mail can drown in it). They made you look tho, didn't they, so whose the sucker!? This vision for the future of electric vehicles is beautiful and bold. Proud of British design. www.youtube.com/watch?v=Zqt7...
Product Designer Mike Lee has open-sourced all his SwiftUI explorations, which is very valuable. github.com/mikelikesdes...
So, let’s see how this platform goes.
