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

createBrowserHistory with a specific window object #624

Closed
voliva opened this issue Oct 1, 2018 · 3 comments · Fixed by #751
Closed

createBrowserHistory with a specific window object #624

voliva opened this issue Oct 1, 2018 · 3 comments · Fixed by #751
Labels

Comments

@voliva
Copy link

voliva commented Oct 1, 2018

Inspired from this article https://hackernoon.com/using-a-react-16-portal-to-do-something-cool-2a2d627b0202 and trying to do a desktop Electron app which takes some seconds to initialize (parsing all own + vendor JS, fetching initial data from servers, etc.), I'm trying to spawn new windows and skipping this initialization, by using React portals.

For example, in a view I have a button "Contacts" which will popup the window with the Contacts component for the user to browse. By using this method, I can create an about:blank window, render everything in there by using a Portal, and that window will share the same state as the parent window.

In case that, for some reason, the popup window gets refreshed (the users presses Ctrl+R, or whatever), I can set the URL of the popup window by replaceState to a URL that I can define as a route, so when it gets refreshed it will go through all initialization (oh well...) and render the same component.

The problem I have though is if that Contacts component has some nested routes on it, as the code is running on the parent window AND the Router was initialized with it, all routes are based on the parent window, not on the popup window - So when I'm navigating the Contacts component, the URL gets replaced on the parent window which makes it harder to keep both window URLs in sync and it gets really impractical (because the parent window gets URL changes without changing any view)

If createBrowserHistory accepted a Window object as an option, then I could create a new history object every time I'm popping out a new window, and declare a new Router that uses that history object for that specific window.

@gragland
Copy link

@voliva Did you ever figure out a solution to this? Trying to do the same thing.

@mjackson
Copy link
Member

Thank you for bringing this to our attention, @voliva. I'd definitely like to add this feature, not only to browser history but to hash as well. I'll get it on the roadmap.

@mjackson mjackson mentioned this issue Sep 10, 2019
25 tasks
mjackson added a commit that referenced this issue Nov 5, 2019
New features:
- Remove legacy browser support (pre pushState)
- Add state to hash history
- Use custom window when creating history objects
- Better history.block API (wip)
- Fix location.pathname encoding issues
- About 50% smaller
- No dependencies

Removed features:
- Removes basename support
- Removes getUserConfirmation
- Removes keyLength
- Removes hashType
- Removes relative pathname support in hash + memory histories

Still TBD:
- Missing pathname support in push/replace

Fixes #624
Fixes #704
Fixes #723
Fixes #726
@mjackson mjackson mentioned this issue Nov 5, 2019
Merged
@mjackson
Copy link
Member

mjackson commented Nov 8, 2019

Just a heads up, in the v5 beta released today you can now do:

var history = createBrowserHistory({ window: iframe.contentWindow });

Please give it a shot and LMK how it goes!

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

Successfully merging a pull request may close this issue.

3 participants