-
Notifications
You must be signed in to change notification settings - Fork 959
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
Allow changing forceRefresh #614
Conversation
+1 This is also useful for react-router for site force fresh. |
Thank you for the detailed demo, @stipsan! Very nice. I don't think I realized that Still, I wonder if Maybe it'd be better to expose this behavior in wdyt? |
Just following up here: this issue has been on my mind for a while now. I'm thinking we can maybe address it in v5 with a new history.push(`/gallery`, /* state */ null, /* reload */ true); I have a What do you think, @stipsan? Would that work? |
Hi @mjackson, can we have an additional option to switch to global force refresh mode too? This can be useful when server push a "new version available" signal to the web app, and the app will refresh automatically during next navigation. |
Re-implementation of: remix-run#614 Includes the built artifacts so that we can use it in from `package.json. Issue: remix-run#614 Test plan: It should now be possible to call `setForceRefresh` and dynamically change this setting!
Re-implementation of: remix-run#614 Includes the built artifacts so that we can use it in from `package.json. Issue: remix-run#614 Test plan: It should now be possible to call `setForceRefresh` and dynamically change this setting!
Allow changing forceRefresh Re-implementation of: remix-run#614 Includes the built artifacts so that we can use it in from `package.json. Issue: remix-run#614 Test plan: It should now be possible to call `setForceRefresh` and dynamically change this setting!
This was unintentionally closed because I deleted the |
Hello folks! Was just looking into the ability to change the What we've done in the meantime is extend import { Action, History, Location } from 'history';
export interface RefreshingHistory<T> extends History<T> {
setForceRefresh(val: boolean): void;
}
export default function hardRefreshable<T>(
h: History<T>
): RefreshingHistory<T> {
let forceRefresh = false;
h.listen((loc) => {
if (forceRefresh) {
window.location.href = h.createHref(loc);
}
});
return {
...h,
// We need to do a bit more work to proxy the non-method properties
get length() {
return h.length;
},
set length(l: number) {
h.length = l;
},
get action() {
return h.action;
},
set action(a: Action) {
h.action = a;
},
get location() {
return h.location;
},
set location(l: Location<T>) {
h.location = l;
},
setForceRefresh(val: boolean) {
forceRefresh = val;
},
};
} |
TL;DR - Are there any caveats of implementing this? Do we just have to make the changes in the component rendering Thanks for posting the workaround. I have used this particular snippet in the following way. However, every now and then I stumbled across inconsistencies of the path not being updated swiftly. I will have to click a few times to make it work. In my app, I've imported
Sometimes I get this warning in the console EDIT: I seemed to have solved the issue by memoizing |
TL;DR https://codesandbox.io/s/n77x71v6x4
This has been discussed in #477. The suggestion then were to use
window.location.reload
when the user clicks on a link. Having tested this solution in production I feel this topic is worth a revisit 🤔The codesandbox demonstrates the difference between using
window.location.reload
and having the option to setforceRefresh
by callinghistory.setForceRefresh
itself in a typicalreact-router
setup.Since the call to
window.location.reload
is async the page usually unloads after rendering the same route that is being navigated to, making it look like something went wrong to the end user:Compare it to
forceRefresh
:I tried my best to find alternative solutions but doing something the equivalent of:
Turned out to be surprisingly difficult. As was trying to wrap every
<Link />
and<Redirect />
with custom logic that overrides events and essentially reimplement whatforceRefresh
inhistory
does to achieve the same result. But as it turns out there's more logic than react components that might trigger a navigation events so this too is fragile (and a lot of code compared to just rendering a component somewhere wrapped inwithRouter
that callshistory.setForceRefresh(true)
and that's it).What do you think?