Opening link in new tab does not respect hash-bang

[mrozbarry]

I'm not sure if this is something that can be captured easily (maybe hook on window.unload?), but if I am not using history (history: false on router component), and right click on a link and open it in a new tab, the router isn't or can't intercept that url change to use a hash-bang, which breaks my widget (it's a widget that embeds into wordpress), and forces the user into a page not found url.

I'm not sure if there is a real and common issue that is fixable in all situations, so should I be implementing the fix in my application, or is there a more generic fix that can be applied to the router?

Edit: I just realized that some of my problem isn't correct, or even track-able. New tab obviously doesn't emit a window.unload, and if the user does a right-click, we lose dom events, so we couldn't even do something like a window.open

[mrozbarry]

Obviously, I can do some route handling in my wordpress plugin, which is maybe the only solution, but if there is something in javascript we can do, I think that would be preferable.

[larrymyers]

Since you're using hash urls unfortunately that means your server can't bootstrap the page in the correct state. Can you recreate the correct page state with async calls after page load? Hitting the 'notFound' route would mean the hash url being generated truly isn't a route your React app is setup to handle.

[mrozbarry]

Oh, I should have specified; the not found is from wordpress, not from the app. We're embedding a react component in a wordpress shortcode. I think we'll just have to handle this in the plugin, which is perfectly fine, I just wasn't sure if this is something hookable inside this project.

[larrymyers]

Ah, gotcha. Sounds like you do indeed have a use case is that outside the scope of the ReactMiniRouter component.