choo icon indicating copy to clipboard operation
choo copied to clipboard

Emitting pushState is a no-op in a route handler

Open aknuds1 opened this issue 6 years ago • 2 comments

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 avatar Feb 21 '18 13:02 aknuds1

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?

aknuds1 avatar Feb 24 '18 18:02 aknuds1

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.

goto-bus-stop avatar Jun 13 '18 14:06 goto-bus-stop