Closed AlttiRi closed 1 month ago
Interesting idea! It does sound like you could use the hash history. Note that you can still store other data with a virtual hash property. You do lose the CSS :target
property as a tradeoff.
You mention 3 other advantages, but the first two apply to the hash history as well, and the last one isn't a concern in a web extension.
In any case, this can be built as a standalone library outside of vue-router (that was one of the advantages of extracting the histories 😄). I don't think this kind of history should be included in vue router because I wouldn't recommend it over the other histories (for the reasons mentioned above), but I would love to see it as a standalone open-source library! It shouldn't be too hard by copying an existing history and replacing the way it handles the path, so you should definitely give it a try. FYI: I offer consultancy for anybody needing help with their products
What problem is this solving
As the documentation says, both
createWebHistory
andcreateWebHashHistory
have disadvantages.createWebHistory
can not be used if the underlying server can't handle the required paths in some specific way.Since, by default, when a server sees
pathname
like this/users/123
it tries to return a file with name123
from theusers
directory even while only theindex.html
is in the working directory. Trying opening such URL will fail with the 404 error.❌ So,
createWebHistory
can not be used when there is no ability to configure the server behaviour. In particular, in web extensions.On the other hand, using of
createWebHashHistory
don't allow to use thehash
for common things as scrolling to an element withid
same as in thehash
, and/or styling the element with:target
CSS selector, also for other things like using hash for storing local data, for example:https://play.vuejs.org/
)https://mega.nz/
)❌ Thus, using
createWebHashHistory
limits the use of the hash to only store the route and nothing else. It's bad.Proposed solution
The very simple alternative is just to store the route path as a key's value of
searchParams
.This:
hash
for your own purposes,createWebHashHistory
(using of
seachParams
for navigation is the older thing than "REST API-like" URLs ofcreateWebHistory
).It should look like this:
And the URLs will look so:
/index.html?route=/users/123
/index.html?route=/admin
For both URLs
/index.html
and/index.html?route=/users/123
any server will return the same "index.html" file with no problem. Then the router will parse the input URL and do the things.Also, it makes sense to allow to specify the
searchParam
's key name (if the defaultroute
is already used for another purpose):/index.html?vueRoute=/admin
I sure it's easy to implement. You just only need to parse/write the route path from/to the specific
searchParams
' key instead ofpathname
, orhash
. That's all.createSearchParamsHistory
will be definitely better thancreateWebHashHistory
.Describe alternatives you've considered
No response