-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
feat: drift album page #19564
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
base: main
Are you sure you want to change the base?
feat: drift album page #19564
Conversation
alextran1502
commented
Jun 26, 2025
- feat: drift album page
- feat: page renderred
You spelled |
ad38340
to
0611f1a
Compare
0611f1a
to
b6ccf75
Compare
c81c707
to
d3b7fe0
Compare
dependencies: [remoteAlbumServiceProvider], | ||
); | ||
|
||
class RemoteAlbumState { |
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.
TBH, We do not need this as a provider at all. The idea for a provider is to use it when you have a common state that is shared across widgets. This one, however, is used only in the Albums page. Routes opened from this page do not need access to this so ideally, it would be best to move all the logic inside this provider to the Widget state and remove this one.
TLDR:
- State shared between widgets across different page / routes -> Providers
- State used in only one page -> Widget State
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.
I think we should follow the same convention everywhere for an expected development flow. Widget > Provider > Service > Repository. Additionally, if you include these logic within the page file, it will get pretty long with all the UI component code, then you would need to think about how to break out those logic into a separate file, so eventually we would come full cycle
fbb5ef1
to
c0b3c6c
Compare