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.