salvoravida/redux-first-history

First LOCATION_CHANGE does not trigger saga

Opened this issue · 4 comments

I use a saga called locationSaga to listen to LOCATION_CHANGE and for each LOCATION_CHANGE, look at the path and decide what redux actions to fire off to start loading the data needed by that path.

This means that I can lazy-load the data needed for that path.

However this does not works for reloads.

The first redux action as seen in redux devtool is a LOCATION_CHANGE with path /ukelonn/users (the path reloaded on)
image

However that LOCATION_CHANGE does not trigger this saga

Navigating to a different page and navigating back, triggers the saga:
image

One difference I can see is that the first LOCATION_CHANGE, the one that doesn't trigger the saga, is a pop() while the one that triggers the saga is a push()?

Or is it a timing related issue?

Should I have a saga that waits a couple of seconds and then fire off a push() to the current location?

Versions from package.json:

        "@reduxjs/toolkit": "^2.2.3",
        "axios": "^1.6.8",
        "delay": "^6.0.0",
        "js-cookie": "^3.0.5",
        "qs": "^6.12.0",
        "react": "^18.2.0",
        "react-dom": "^18.2.0",
        "react-redux": "^9.1.0",
        "react-router-dom": "^6.22.3",
        "redux-first-history": "^5.2.0",
        "redux-saga": "^1.3.0",

Turns out firing off a PUSH LOCATION_CHANGE to the current router location at the react app startup in index.js, was enough. steinarb/ukelonn@dacca76

The PUSH LOCATION_CHANGE was picked up by the locationChange saga, the propert path was detected and the necessary redux actions for data required by the current location were dispatched (on an app reload of the path).

But even though I now have a workaround, it is still interesting to me to understand why the pop LOCATION_CHANGE wasn't picked up by the saga?

I guess because your saga started after the first dispatch of the action, so the saga middleware was not yet loaded with your saga to propagate the action

That sounds right. The dispatch of a LOCATION_CHANGE (i.e. my workaround) is done after I have set up the saga(s).

Thanks for responding! 😄