-
Notifications
You must be signed in to change notification settings - Fork 42
Add RTK listenerMiddleware #2828
base: main
Are you sure you want to change the base?
Conversation
Preview this change https://demo.audius.co/sk-listener-middleware |
omg |
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.
Hype!! Maybe worth setting this up on web as well? Have we thought at all about how shared/common listeners will work?
export const addListeners = (startListening: AppStartListening) => { | ||
startListening({ | ||
actionCreator: setTheme, | ||
effect: async function setThemeEffect(action, listenerApi) { |
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.
curious, is there a reason this is a named fn instead of an async (action, listenAPI) => ...
?
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.
It makes the callstack nicer when debugging!
Yeah I def think worth it for web too. Shared listeners should be similar to how we do sagas currently, can be defined in common and then a root level file in web/mobile can call each listener file with the appropriate |
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 absolutely love these changes! so this is just RTK addition, not a RTK-Query thing yeah? if so id say lets def move forward with this generally. itll probably cover 90% of usecases and be much simpler to understand. Do you think the queue stuff could theoretically be built with the middleware, or is that a large enough of a process we'd need a "saga" like approach? guessing with all the cancelleation and minutae it would still be needed? potentially though we could still use listener middleware for over 50% of current offline stuff though
Yes exactly! I'm honestly just a little hesitant to bifurcate the codebase further though lol And yeah cancellation is one of the cases it doesn't support, but offline is one of the few/only places we need that |
yeah i think we should figure out what we are using for fetch layer first, but this changes that calculus |
Description
An example of using rtk listenerMiddleware instead of sagas. Some nice benefits:
Just a draft for now, would love to hear people's thoughts!
Dragons
Is there anything the reviewer should be on the lookout for? Are there any dangerous changes?
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide repro instructions & any configuration.
How will this change be monitored?
For features that are critical or could fail silently please describe the monitoring/alerting being added.
Feature Flags
Are all new features properly feature flagged? Describe added feature flags.