Remove 'navigateFallback' behavior from default SW config
jeffposnick opened this issue · 6 comments
I wanted to move my latest comments from #2398 (comment) into a specific issue to discuss them separate from the larger meta-conversation around service workers in create-react-app
:
Here's one possible change that could be made short of removing service worker generation: by default,
index.html
is used to handle all navigation requests for URLs that aren't precached (config).This behavior is in there to support SPA-style offline usage, where users might navigate to URLs that don't correspond to underlying HTML files. That being said, many developers don't fall into that category.
What we could do is remove
navigateFallback
/navigateFallbackWhitelist
completely from the default configuration. Offline usage forindex.html
and any other files that exist as part of the Webpack build will still work. Offline usage for SPA-style routing will continue to work ifhash
-based routing is used (as opposed topushState
routing).The drawback is that getting offline support with
pushState
routing working would require aneject
and re-addingnavigateFallback
to the config, but at least there's a specific place in the existing documentation for this use case, where we can clearly spell out the changes that are needed.
Given that it would break the "navigate to a random URL and expect it to work" offline experience for any SPAs that have gone through the steps to support the History API's pushState()
, I think that if we move forward, it needs to wait until the next major release of create-react-app
.
@chee has put together #3024 which would be sufficient in terms of a code change, but we'd need to accompany it with changes to the docs explaining how to eject
and re-enable that behavior for SPAs using the History API (which I'm happy to write).
CC: @Timer @gaearon @addyosmani for their thoughts.
The drawback is that getting offline support with pushState routing working would require an eject and re-adding navigateFallback to the config
That sounds like a deal-breaker, no? We expect that the vast majority of apps are built with client side pushState
routing, not hash based one. If anything, I expect people want it more than service workers.
If the default experience is broken, it seems like the majority would be better served by disabling service workers than by breaking client-side routing out of the box.
Do I misunderstand the proposal?
Your understanding of the proposal sounds correct, though I want to clarify what broken means in this context.
Removing navigateFallback
would mean that apps using client-side pushState
routing would require a network connection to fulfill the initial navigation to a non-/
or /index.html
URL.
The offline experience for those pushState()
ed URLs would be broken, but navigations to those URLs would work as expected under this proposal whenever there is a network connection.
The benefit of going with this approach vs. disabling service workers entirely is that navigations to /index.html
would still work while offline under all circumstances, and that's the entry point for anything added to an Android device's homescreen.
If folks are not a fan of this proposal, then earlier proposals, like #3024 (comment) are still viable ways addressing some of the same pain points that this tries to solve.
Okay, this sounds reasonable. Thanks for explaining!
i wouldn’t have minded the burden! i love burden
but it’s now closed in favour of yours
thanks! it looks like a good move.