-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor state.dart (part 2) #596
Conversation
MLCommons CLA bot All contributors have signed the MLCommons CLA ✍️ ✅ |
// All methods in AppState should have the following properties: | ||
// - Public methods: return type `void`, public methods must not be awaited | ||
// - Public methods: exceptions are never thrown | ||
// - All methods: notifyListeners() call outside of `state` setter is forbidden | ||
// - All methods: if notifyListeners() is needed when `state` field doesn't change, | ||
// the class that contains the data that requires UI update should implement ChangeNotifier instead | ||
// - All methods: complex logic should be moved to other classes, methods in AppState should only manage `state` | ||
// | ||
// Any methods or getters that don't satisfy these requirements should be subject to refactoring. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@anhappdev, the #556 issue and this whole PR in particular was for these rules.
Other changes may be subject to discussions, but I think these few lines are very important.
Everything else in this PR was changed to make this possible. Even though there are still few little things left in this class that don't obey these rules, now it will be easy to fix it.
…ctor-state-2 # Conflicts: # flutter/lib/state/task_runner.dart
Kudos, SonarCloud Quality Gate passed! |
close this for now. We prefer piecemeal changes. Maybe we can cherrypick some small ones from this huge one later. |
Closes #556
This is a huge pull request, which is not ideal.
If I had enough time I would split it into several small PRs which would be much easier to review.
However, I think it's very important to merge it. I believe that this PR contains a significant code quality improvement (which I was thinking about for the last several months).