-
Notifications
You must be signed in to change notification settings - Fork 34
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
First LOCATION_CHANGE does not trigger saga #126
Comments
Versions from package.json:
|
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! 😄 |
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](https://private-user-images.githubusercontent.com/691728/327953198-90ee1336-ae51-4965-8a30-ab962dbe314e.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjU3NzQ0NTgsIm5iZiI6MTcyNTc3NDE1OCwicGF0aCI6Ii82OTE3MjgvMzI3OTUzMTk4LTkwZWUxMzM2LWFlNTEtNDk2NS04YTMwLWFiOTYyZGJlMzE0ZS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQwOTA4JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MDkwOFQwNTQyMzhaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1hMzhkMTAwNzQ0NzlmZWQzNGM3YTU4OTNmNzFiMjQyY2M2MTk3ZDZmMzEyOGUxZTcyN2I3OTIyMmEzMjZiZDk2JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9.x0WWeSCPnf95CPqTdV7V0fPZwL7vgeAbbRNxG2BR0Bs)
However that LOCATION_CHANGE does not trigger this saga
Navigating to a different page and navigating back, triggers the saga:
![image](https://private-user-images.githubusercontent.com/691728/327953455-618c4673-aaa5-4e45-b816-36abb620b744.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjU3NzQ0NTgsIm5iZiI6MTcyNTc3NDE1OCwicGF0aCI6Ii82OTE3MjgvMzI3OTUzNDU1LTYxOGM0NjczLWFhYTUtNGU0NS1iODE2LTM2YWJiNjIwYjc0NC5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjQwOTA4JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI0MDkwOFQwNTQyMzhaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1jZWYxN2M0MGQ3OTY2NDQzOThjYjlhZTJkYjJkNTdiOWY0MzIzN2RhNDYyMWUyNzEwMmNlMzg3ODU1ODU4NzdmJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZhY3Rvcl9pZD0wJmtleV9pZD0wJnJlcG9faWQ9MCJ9.Kx5AC_D0hBI07knWKPcrDbunSODTMr2dbbLEb88zdg4)
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?
The text was updated successfully, but these errors were encountered: