-
Notifications
You must be signed in to change notification settings - Fork 249
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
Incorrect root detection #138
Comments
Finding the root URL was always tricky. The 5.x versions actually have a better route matching but maybe that part with guessing the root is not working the same way. I'm considering making that root parameter mandatory and we always have to provide it. In most of the cases the developer knows where the app is located. Can you please post here your route definitions so I can reproduce your problem. P.S. |
It can be used in most modern browsers, i think.
|
I think this issue is super serious because it basically kills the route initialization itself whenever is not home, If you want to support older browsers, location origin can be easily covered by combining |
So I started refactoring the router to use P.S. |
Hi @krasimir, I agree with the drop-in view you have about a router, no matter how deeply nested the route is. I think that is a big differenciator from other solutions, however I feel that nested path should be specified by the developer so the router works as expected when the application doesn't start from home. For example, I have a web app with two routes, I think that taking Cheers! |
I'm in a constant battle with myself about how to design the router. What you just described is the second variant. The first one is how the router works now. Last couple of months I'm thinking about a rewrite of the whole thing and I may change it indeed as you are suggesting. It's just with the current code base will be nightmare. There are so many things that will break if we start using |
Yeah, I agree it will mess up with a lot of stuff. Probably a re-write would be best, and check current features as you tackle them in the new version. Either way, breaking changes and semver exist for something 😄 |
This suggestion of The documentation says we should set the entry point on And thanks for the router :) |
@jpenna What I meant by entry point was the |
@krasimir What I am saying is that it should be written here:
I am using |
Ok so, 3+ years later I'm almost done with the re-write :) . The new version 8.0.0 (you can get it atm via const router = new Navigo("/schedule");
router
.on("/:id", (match) => {
console.log("The id is " + match.data.id);
})
.resolve(); meaning that:
The example is here https://github.com/krasimir/navigo/tree/big-rewrite/examples/138 |
I use last version 5.1 and webpack dev server with these settings
devServer: { contentBase: path.join(__dirname, "build"), compress: true, host: "0.0.0.0", disableHostCheck: true, port: 9000, historyApiFallback: true }
I init Navigo with default parameters (root= null). In previous version 4.8 after reload page Navigo detects root path well and show me right page. But now, after page reload, it shows me my home page again.
For example when i start page with URL "http://localhost:9000/schedule/3304" it thinks that root path is "/schedule/3304". But it is not correct.
I think this function has error:
_getRoot: function () { if (this.root !== null) return this.root; this.root = root(this._cLoc().split('?')[0], this._routes); return this.root; },
UPD: To fix this problem i should init Navigo with first parameter location.origin. I think u can add it to code to fix it too.
The text was updated successfully, but these errors were encountered: