Add basic guards to avoid firing observer unnecessarily
See original GitHub issueFor example, we don’t need to recalculate all queries when a QUERY_STOP
action happens, and this can be easily detected by ===
the data
field.
Issue Analytics
- State:
- Created 7 years ago
- Comments:8 (8 by maintainers)
Top Results From Across the Web
ATP 3-09.30 Observed Fires - Army Publishing Directorate
ATP 3-09.30 applies to the Active Army, Army National Guard of the ... The firing platoon is the basic firing element of the...
Read more >RANGER HANDBOOK
(i) Avoid unnecessary duplication. (j) Provide for safety of friendly forces and installations. (k) Provide for flexibility. (l) Furnish the type of fire...
Read more >Tactics, Techniques, and Procedures for the Field Artillery ...
A firing chart is a graphic representation of a portion of the earth's surface used for determining distance (or range) and direction (azimuth...
Read more >Guide to Oracle Data Guard Fast-Start Failover
This document will guide you through configuring Oracle Data Guard Fast-Start Failover (FSFO) using a physical standby database.
Read more >NTC TRENDS and TTPs, 1& - GlobalSecurity.org
TREND 1: Use of maneuver observers within the task force to request fires. ... commander's decisive point and each essential fire support task...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Currently, broadcastQueries is called every time there is a change in the Redux store.
This then iterates over all of the query listeners, and calls those (defined here).
That ends up calling
readSelectionSetFromStore
if certain conditions are met, like if there are no errors, and the query is not loading, etc.That calls observer.next, even if the query result is the same as before, which could end up re-rendering react components, etc.
The end result is that every time there is a Redux store change (even one that didn’t affect apollo at all), we re-run
readSelectionSetFromStore
and re-fire thenext
on any observable subscribers currently active.However, the actual query results change pretty rarely! For example, if
state.apollo === previousState.apollo
, then we shouldn’t run anything at all. Ifstate.apollo.data === previousState.apollo.data
, then we don’t need to update any query results that we have already sent, etc.This task is about adding some simple equality checks in the process to avoid firing every single query observable on every store change.
Solved in #226