Skip to content
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

Emitting pushState is a no-op in a route handler #631

Open
aknuds1 opened this issue Feb 21, 2018 · 2 comments
Open

Emitting pushState is a no-op in a route handler #631

aknuds1 opened this issue Feb 21, 2018 · 2 comments

Comments

@aknuds1
Copy link
Contributor

aknuds1 commented Feb 21, 2018

Expected behavior

In choo v6.8.0, emitting pushState (e.g. emit('pushState', '/')) in a route handler should have the documented behaviour of navigating to the indicated page.

My use case is to redirect the user to the homepage from f.ex. the login page if the user is already logged in.

Actual behavior

When emitting this event in a route handler, it appears to do nothing. Instead I defer the event to be emitted asynchronously, which makes it work: setTimeout(() => {emit.global('pushState', '/')}, 0)

Steps to reproduce behavior

Emit the pushState event in a route handler, in my experience it'll be a no-op:

emit('pushState', '/')
@aknuds1
Copy link
Contributor Author

aknuds1 commented Feb 24, 2018

I found out that the reason for the pushState event being a no-op during a render pass being that nanoraf will suppress any render requests while already rendering. The question is if choo should handle this scenario and defer the handling of the event until after the render pass (i.e. as I do with setTimeout), on behalf of the client?

@goto-bus-stop
Copy link
Member

goto-bus-stop commented Jun 13, 2018

I think ideally we would detect that pushState was emitted in a route handler and bail out of rendering the current route, then render the new route. I think deferring on behalf of the client makes sense, even if just to maintain the async behaviour of pushState, so that

emit('pushState', '/newroute')
assert(state.route === '/oldroute')

works the same way in a route handler as elsewhere.

e; err, that's not actually how it works right now, but the point is that the rerender should not have happened yet at the assert() line.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants