Skip to content
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

Extract NotificationList state #2185

Merged
merged 4 commits into from
Jun 18, 2020
Merged

Conversation

askvortsov1
Copy link
Member

Refs #1821 #2144

Changes proposed in this pull request:

  • Extract NotificationListState into its own state class

Reviewers should focus on:

  • Anything I missed?

Confirmed

  • Frontend changes: tested on a local Flarum installation.
  • Backend changes: tests are green (run composer test).

@askvortsov1 askvortsov1 mentioned this pull request May 24, 2020
65 tasks
@dsevillamartin
Copy link
Member

Why are we passing the app global? I don't understand the purpose of this. If it is to allow for extensibility, wouldn't that require the extension developer to create their own whole Application class anyway with the data that this state requires?

@askvortsov1
Copy link
Member Author

@datitisev As per the discussion in #2150 (comment)

@dsevillamartin
Copy link
Member

Hm I see. It doesn't seem right to me.

@franzliedke
Copy link
Contributor

@datitisev Would you prefer to see the actual dependencies (e.g. the store and the session) being passed in instead of the entire app?

@dsevillamartin
Copy link
Member

I think so, yeah.

Copy link
Contributor

@franzliedke franzliedke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I can see, this one is a bit different than other "state" PRs. The notification state does not seem to affect (or be relevant to) other parts of our application, so I do not see a reason to move it up to the application.

Instead, moving it from the NotificationList to the NotificationsDropdown would be enough - the dropdown component is the "highest" component that needs this data (no siblings or parents need it), and it could pass relevant data down to children (the NotificationList component) as props where they need it.

What do you think? Am I missing something?

@askvortsov1
Copy link
Member Author

Instead, moving it from the NotificationList to the NotificationsDropdown would be enough - the dropdown component is the "highest" component that needs this data (no siblings or parents need it), and it could pass relevant data down to children (the NotificationList component) as props where they need it.

I would agree with this.

@askvortsov1
Copy link
Member Author

I would agree with this.

Actually, scratch that: NotificationsPage also uses it.

Copy link
Contributor

@franzliedke franzliedke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved in a three-people call 😃

@dsevillamartin
Copy link
Member

dsevillamartin commented Jun 18, 2020

Breaking changes:

  • app.cache.notifications is now app.notifications.getNotificationPages().
  • methods for modifying app.cache.notifications are now available through app.notifications instead of the component

@askvortsov1 askvortsov1 merged commit 65f2d5f into master Jun 18, 2020
@askvortsov1 askvortsov1 deleted the as/search_source_state_extraction branch June 18, 2020 21:08
franzliedke added a commit that referenced this pull request Jun 26, 2020
Needed for pusher extension.

Refs #2185.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants