Open hacker1024 opened 3 years ago
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.
I'm using Equatable libaray for comparsion rules. The real-word example below:
class _StoreMediator extends Equatable {
final String phoneNumber;
final void Function() openAccountScreen;
final void Function() openRegistrationScreen;
@override
List<Object?> get props => [phoneNumber]; // <---
const _StoreMediator(
{required this.phoneNumber,
required this.openAccountScreen,
required this.openRegistrationScreen});
static _StoreMediator connect(Store<RootState> store) {
return _StoreMediator(
phoneNumber: store.state.account.phoneNumber,
openAccountScreen: () => store.dispatch(NavigateToAction('/account')),
openRegistrationScreen: () => store.dispatch(NavigateToAction('/registration')),
);
}
}
this will ensure that only [phoneNumber] fields are compared
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?