https://kotlinlang.org logo
#compose
Title
# compose
g

Guy Bieber

06/03/2020, 3:50 PM
The world needs more magic. Put @Model back in.
😄 6
l

Leland Richardson [G]

06/03/2020, 3:57 PM
i sense the joking tone here, but i’m also curious, is there something you’re missing about it?
🙂 1
g

Guy Bieber

06/03/2020, 3:59 PM
It’s way cleaner than the new approach.
Just because Swift does it that way, doesn’t make it better. Let’s be swifter than Swift.
l

Leland Richardson [G]

06/03/2020, 4:08 PM
i agree it’s more ergonomic. but IMO it has too many downsides for the tradeoff to make sense.
you could always write an @Model plugin yourself and open source it 🙂
1
g

Guy Bieber

06/03/2020, 4:10 PM
What are the perceived downsides?
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.
l

Leland Richardson [G]

06/03/2020, 4:15 PM
👍 4
g

Guy Bieber

06/03/2020, 4:26 PM
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.
Also, BTW, great job on this framework. You are taking on some tough challenges. We are grateful.
🙏 1
l

Leland Richardson [G]

06/03/2020, 4:34 PM
thanks for the feedback, it is appreciated. i’ll try to provide a more complete response some time soon…
👍 4