Difference between ScopedModel and InheritedModel? about scoped_model HOT 3 CLOSED

Hey there -- sorry my friend, somehow missed this one!

Overall, I think scoped_model might not be necessary, and InheritedWidget is often enough (this is really just a simple wrapper around the Listenable and InheritedWidget classes).

That said, I think ScopedModel can work really nicely if you want an imperative API. For example, you can wrap your Model's fields in Getters and Setters like so:

class CounterModel extends Model {
  // Private count
  int _count = 0;

  int get count => _count;

  // Every time the count is mutated, update the internal state and notify the listeners!
  set count(int newCount) {
    _count = newCount;
    notifyListeners();
  }
}

After providing this small amount of code, you can now update your model imperatively, and the scoped model will take care of notifying any components that are listening!

final counter = CounterModel();

// Print the latest count whenever the model changes
counter.addListener(() { print(counter.count); });

counter.count = 1; // prints 1, because the setter will notify Listeners

Overall, I think this is a really nice / simple pattern if you like the imperative approach and isn't so easily replicated with InheritedWidgets alone.

from scoped_model.

Thanks a lot!

I have another question, please: Suppose I have an AppModel that is composed of 3 classes:
user: (username, token, etc)
cart: (items list)
wishlist: (items list)

Now for some reason I get logged out. I try to call the API from the cart, in order to update it, but get a message such as "access denied". How do I update the user model, and set the token to null? This is quite easy to do in Redux, but I have no idea how this can be done easily in other state-management systems.

from scoped_model.

I think in that case you'd want to treat it the same way you'd treat a Redux action: Set the user as logged out and notify the listeners. You could even even throw an error if you try to make an API call using a null User.

Then, it's a matter of coordinating those calls: Why might you be making an API call to the Cart after the user has logged out and that information is required?

It sounds like there's a race condition: You're first logging out, then performing some API call sometime after. IMO, it's just a matter of clearing that API call when you know the user is logged out and it will produce an error.

from scoped_model.