erikringsmuth / app-router

Router for Web Components
https://erikringsmuth.github.io/app-router/
MIT License
610 stars 83 forks source link

two-way binding back to the actual URL #112

Open liebrand opened 9 years ago

liebrand commented 9 years ago

We are using binding to get both pathArguments and search parameters as attributes on our elements which works great!

However, when the app/elements on the page change these values, the URL does not update. I have managed to add this in to my own element, which uses polymer's observe to monitor any changes to these variables and then history.replaceState to update the URL accordingly, but it would be nice if this was handled by the app router itself.

This allows for the UI updating and the URL being accurate (for example for bookmarking or refreshing).

As a rule of thumb, if pathArguments change we use history.pushState to update the URL (eg adding to the browsers history), and when search parameters change, we use replaceState...

erikringsmuth commented 9 years ago

...it's a tough one and has some history here too https://github.com/erikringsmuth/app-router/issues/98.

Does it push or replace state?

Does it trigger custom element lifecycle events? Does it trigger router lifecycle events?

If you're using multiple nested routers does it trigger a popstate or hashchange event like router.go() or does it only update the current router?

Object.observe() is an ES7 feature which is still a ways out. I don't really want to polyfill this since it would be a performance hit for the majority of people who don't use the feature. I'd also like to avoid adding Polymer as a dependency.

Many frameworks including React and Angular 2 are ditching 2 way binding but keep dynamic one-way binding. Polymer 0.8 still has two-way binding but you have to be much more explicit about setting it than you did in 0.5.

My current feeling on this is it's safer to not auto-update the URL and require an explicit URL change in an observer.