salvoravida / redux-first-history

Redux history binding support react-router - @reach/router - wouter - react-location
https://wvst19.csb.app/
MIT License
450 stars 34 forks source link

First LOCATION_CHANGE does not trigger saga #126

Open steinarb opened 6 months ago

steinarb commented 6 months ago

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?

steinarb commented 6 months ago

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",
steinarb commented 6 months ago

Turns out firing off a PUSH LOCATION_CHANGE to the current router location at the react app startup in index.js, was enough. https://github.com/steinarb/ukelonn/commit/dacca7669584278dd532c68a29f2fdaea4024c1f

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?

salvoravida commented 6 months ago

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

steinarb commented 6 months ago

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! :smile: