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
Similarly to Android Architecture Components, the UI layer should introduce a well defined UiState class.
The use of a UiState class has many benefits, as it allows a clear declaration of what is part of the UI state, it helps reasoning about it and it helps handling it, without having the code scattered into another class.
Here one example of a generic UiState class I use (with freezed):
The UI state class doesn't necessarily need to include the loading and error, but keeping them included helps to represent better the formula:
UI = f ( state )
because anything that change the UI has to originate from a change in the state, including the loading state where we usually want to show a loading indicator and the error state where we usually want to show a snackbar.
Having them included in the UiState class helps to reason in terms of a (in)finite state machine:
All the material taken from here, where you can find also a code repository, a video and the slides.
Expected fix
Adding a section titled "Defining the UI state" or similar.
Additional context
No response
I would like to fix this problem.
I will try and fix this problem on docs.flutter.dev.
The text was updated successfully, but these errors were encountered:
Page URL
https://docs.flutter.dev/app-architecture/guide
Page source
https://github.com/flutter/website/blob/main/src/content/app-architecture/guide.md
Describe the problem
Similarly to Android Architecture Components, the UI layer should introduce a well defined UiState class.
The use of a UiState class has many benefits, as it allows a clear declaration of what is part of the UI state, it helps reasoning about it and it helps handling it, without having the code scattered into another class.
Here one example of a generic UiState class I use (with freezed):
The UI state class doesn't necessarily need to include the loading and error, but keeping them included helps to represent better the formula:
because anything that change the UI has to originate from a change in the state, including the loading state where we usually want to show a loading indicator and the error state where we usually want to show a snackbar.
Having them included in the UiState class helps to reason in terms of a (in)finite state machine:
All the material taken from here, where you can find also a code repository, a video and the slides.
Expected fix
Adding a section titled "Defining the UI state" or similar.
Additional context
No response
I would like to fix this problem.
The text was updated successfully, but these errors were encountered: