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

Data: Avoid calling listeners on unchanging state #5339

Merged
merged 1 commit into from
Mar 5, 2018

Conversation

aduth
Copy link
Member

@aduth aduth commented Mar 2, 2018

Related: #5334

This pull request seeks to optimize the behavior of subscribe to avoid calling a listener except in the case that state has in-fact changed. This is a departure from Redux where subscribe is called on every dispatch, whether or not it results in a changed state. It's a departure I'd argue is warranted: listener callbacks don't and shouldn't have access to the dispatched action. That they are expected only to read from state implies that a subscriber react to a change, so an expectation better reflected in these changes.

Further, it would be difficult to introduce the desired optimization mentioned in #5334 to avoid running mapSelectToProps of withSelect without this change, as we don't know which store the mapping function will select from and to implement would require a shallow equality test on all stores (in some cases more wasteful than to just allow the mapping to be performed).

Testing instructions:

Verify unit tests pass:

npm run test-unit

@aduth aduth added Framework Issues related to broader framework topics, especially as it relates to javascript [Type] Performance Related to performance efforts labels Mar 2, 2018
let lastState = store.getState();
store.subscribe( () => {
const state = store.getState();
const hasChanged = state !== lastState;
Copy link
Contributor

Choose a reason for hiding this comment

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

Per curiosity, do we have a lot of use-cases where a dispatch is triggered without any change in the state?

Copy link
Member Author

@aduth aduth Mar 2, 2018

Choose a reason for hiding this comment

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

Many of the actions which incur side-effects often don't do anything to state on their own, e.g.

  • SETUP_EDITOR
  • INSERT_DEFAULT_BLOCK
  • AUTOSAVE
  • FETCH_REUSABLE_BLOCKS

Copy link
Member Author

Choose a reason for hiding this comment

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

For some of these, it could make sense to move the effect to be part of the action creator itself. We might not need a standalone INSERT_DEFAULT_BLOCK action type if the insertDefaultBlock action creator just returned the result of insertBlock.

Copy link
Contributor

@youknowriad youknowriad left a comment

Choose a reason for hiding this comment

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

LGTM 👍

@aduth aduth force-pushed the update/data-unchanging-subscribers branch from 4521b50 to 18ebadf Compare March 5, 2018 15:20
@aduth aduth merged commit c8e1444 into master Mar 5, 2018
@aduth aduth deleted the update/data-unchanging-subscribers branch March 5, 2018 16:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Framework Issues related to broader framework topics, especially as it relates to javascript [Type] Performance Related to performance efforts
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants