You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
myFunction may be accidentally used in a == or hashCode implementation, which would be incorrect as the closure would be non-identical with every new ViewModel
More RAM usage (maybe?)
Why is that the recommended approach, compared to something like this?
Agreed -- your approach is a bit better for the reasons you state!
I was originally playing around with some ideas of creating the ViewModel more in the build function, where it's nice to be able to define those callback functions.
However, as I began to realize it's actually nicer to create the view Model in a static factory / normal class constructor, it now makes less sense.
In many examples (including the TODO architecture sample), ViewModels are created like so:
This (IMO) has the following problems
myFunction
may be accidentally used in a==
orhashCode
implementation, which would be incorrect as the closure would be non-identical with every newViewModel
Why is that the recommended approach, compared to something like this?
The text was updated successfully, but these errors were encountered: