-
Notifications
You must be signed in to change notification settings - Fork 26
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
Write tests/fix "not found" behavior for evaluateCurrentRoute #63
Comments
Example case:
|
i've tried to solve this issues in 2 ways (i'm using it with Riotjs).
The code above will load the state: route_not_found , which is defined below:
But there is a problem: the current route now is 'not-found-page' , and if press the back button it will go a the route "#/some-invalid-route" and then again will load the 'route_not_found' page I've tried to fix this, by removing the route atribute, but this will load the default state:
My second solution: on the event : routeNotFound(route, parameters) i will call have this code:
This will load the proper component but when i hit the back button it will not load the previous state. |
You can get that first example to work reasonable if you pass in the stateRouter.on("routeNotFound", function(path,params){
stateRouter.go("route_not_found", { replace: true })
}) This will replace the invalid url with your route_not_found page in the browser history, and keep the back button from being broken. "Not found"Since writing this issue, and issue #62, I've thought a bit more about the difference between "404 not found" and other state change errors. I think that any time an invalid url is visited (a url with no state matching the route), a full-screen 404 state should be displayed. This would never happen when someone is clicking through your app, or if you're making programmatic If you call Now, trying to call There are cases where it makes sense to show an error screen as a child state of other logged-in-menu states, but I don't think an invalid url in the location bar is one of them. Those other cases aren't exposed awesomely by the abstract-state-router either, but I think the resolution of #62 will probably be "any time we knew what state to try to load, but weren't able to display it for some reason, you should be given the chance to display an error message to the user there or otherwise recover". Next stepsI think the hash-brown-router needs to change its default/not found behavior to make this possible to fix in the abstract-state-router. I'll go write an issue for that now. |
I couldn't fix the first example with replace option. The problem remains the same, also i don't need the invalid url to be replaced, it needs to stay there for the back button to work. I just need the content of the state of route_not_found not the route to change to "/not_found_route". |
Now is working :) i found the problem, I've looked at your test and the proper code is: Thank you for the response ;). this is a useful library :) |
oh man you're right >_< sorry about the misleading comment! As I have the time, I'll start working on the code to display the 404 state without changing the url. |
Okay, the [email protected] was published with the correct After upgrading to this new version, the fix detailed in above comments can now be implemented. |
My "not found" plan ran into some issues. Right now, the abstract-state-router has an implied contract with consumers that 1. all states can be identified with a string, and 2. you can get a hold of every state/dom API by watching for the state create/reset events. (See https://github.com/TehShrike/asr-active-state-watcher) I was going to implement this in a way that wouldn't involve a new identifier in the state names namespace, and wouldn't fire all of the regular events (like So I'm thinking of saying that the "not found" state will have a hardcoded state name of It's not what I wanted to do, but I think it will be necessary to keep my mental model for state change flow simple. Any thoughts? |
You know, I think you could implement a "not found" route by just adding a state with a wildcard |
Right now
evaluateCurrentRoute
only checks "is there any route" before sending you to a default state.It would probably be more correct to check "is the route empty?" and if so, send you to that default state, and if not, emit a
notFound
event or send you to a 404-not-found page.Thoughts?
The text was updated successfully, but these errors were encountered: