-
Notifications
You must be signed in to change notification settings - Fork 4
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
Page not found #5
Comments
First and foremost, you should do that on the server so that you get a proper 404 HTTP response. On the client though... I'm guessing you're either successfully matching a route pattern, in which case you can check the validity of the route arguments when they are matched, or you're not matching any route pattern, in which case the click handler won't match the url to a path and will let the request go through to the server, which will result in a 404. |
I think something is wrong in this assumptions. Server is API + answer-with-frontend-app-to-any-route universal endpoint. // no info to answer 404 withing the routes corresponding to Frontend application
router.get("*", function (req, res, cb) { app
if (req.path.startsWith("/public/")) {
return cb();
} else if (req.path.startsWith("/api/")) {
return cb();
} else {
...
return res.render(...);
} So in the frontend-first architectures server has no knowledge about unexistance of routes unless frontend grants him with that information (isomorphic apps). So this
is either impossible to implement or this thing can (and should) be at the frontend first. We have to catch "click handler found no match" events and handle them by displaying "Page Not Found". This is not a strict equivalent of Server 404. In old-school backend-first architectures there could be two types of "404 Page Not Found". First: no route matched. Second: route matched, params parsed but id (or other thing) does not correspond to any database model. Only first situation is applicable to frontend-first architectures. Second case translates to server responds with 404 inner event and we commonly represent this as notification. Not as "Page Not Found". |
Sorry my bad, you are right. So I guess I don't really understand what you want then. I mean, presumably you've got a route listener in there somewhere, and upon receiving a message that the route has transitioned, you're looking at the route parameters and using that to judge what content to load, right? Is the "navigate" method what you're looking for? (i.e. targeting an error route, such as |
For what it's worth, I'm nearly finished completely rewriting the router, and there will be a number of significant breaking changes. The changes to your code shouldn't be significant though. |
As I said, there is two common possible situations. Let's call them page-not-found and data-not-found. The case you've described is data-not-found. And this case is already working. I can react to 404 HTTP server response in a number of ways. This is not strictly connected with cycle-router5, maybe worth only documenting. So page-not-found is left. And let's suppose this is not isomorphic app, for example it has Python or Java on backend. Saying that, I'm experementing with Router5 and have discovered a number of issues. For example, I can't hook to anything to possibly get into "Page Not Found" state.
That's great. |
router5/router5#22 is fixed and now we have two (at least) approaches to implement page-not-found. Note: the code below corresponds to pure Router-5, not Cycle-Router5. Make
|
How to implement?
The text was updated successfully, but these errors were encountered: