The world needs more magic. Put @Model back in.

# compose

[Guy Bieber]

The world needs more magic. Put @Model back in.

[Leland Richardson [G]]

i sense the joking tone here, but i’m also curious, is there something you’re missing about it?

[Guy Bieber]

It’s way cleaner than the new approach.

[Guy Bieber]

Just because Swift does it that way, doesn’t make it better. Let’s be swifter than Swift.

[Leland Richardson [G]]

i agree it’s more ergonomic. but IMO it has too many downsides for the tradeoff to make sense.

[Leland Richardson [G]]

you could always write an @Model plugin yourself and open source it 🙂

[Guy Bieber]

What are the perceived downsides?

[Guy Bieber]

The main downside I have seen is that certain types cause a compiler dump if marked @Model. Like Arrays, ByteArrays, sometimes unsigned types, etc. This seems more like growing pains than a reason to dump the whole approach.

[Leland Richardson [G]]

I tried to include our justification in the commit: https://android-review.googlesource.com/c/platform/frameworks/support/+/1311293

[Guy Bieber]

I appreciate that. Here are my thoughts (for what they are worth):
Rationale includes but is not limited to:
- Reduces API surface area and concepts we need to teach GB> Not sure this is true.
- More closely aligns with other comparable toolkits (Swift UI, React, Flutter). GB> Again let’s be better.
- Reversible decision. We can always bring @Model back later. GB> Yes please do!!!
- Removes corner-case usage and difficult to answer questions about configuring @Model as things we need to handle
- @Model data classes, equals, hashcode, etc. GB> Not sure about the details here.
- How do I have some properties “observed” and others not? GB> This seems like a developer issue. You model should contain the model only.
- How do I specify structural vs. referential equality to be used in observation? GB> Not sure about this one.
- Reduces “magic” in the system. Would reduce the likelihood of someone assuming system was smarter than it is (ie, it knowing how to diff a list) GB> Seems like you handled that with ModelList and ModelMap.
- Makes the granularity of observation more intuitive. GB> I handle this by passing in the Model to my components. There is an overall app model and the part of the model the widget understands is passed in.
- Improves refactorability from variable -> property on class GB> There were some weird restrictions between data class, class, abstract class, etc. that I had to workaround.
- Potentially opens up possibilities to do hand-crafted State-specific optimizations GB> probably other ways to handle this via overriding.
- More closely aligns with the rest of the ecosystem and reduces ambiguity towards immutable or us “embracing mutable state” GB> Seems I can use it either way, by replacing an object reference or changing object values.

[Guy Bieber]

Also, BTW, great job on this framework. You are taking on some tough challenges. We are grateful.

[Leland Richardson [G]]

thanks for the feedback, it is appreciated. i’ll try to provide a more complete response some time soon…