Skip to content

dynamic:true vs notify:false - UI-Router 1.0 Does not appear to be feature-complete #3650

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

Closed
1 of 3 tasks
nickminutello opened this issue Feb 16, 2018 · 4 comments
Closed
1 of 3 tasks
Labels

Comments

@nickminutello
Copy link

nickminutello commented Feb 16, 2018

This is a (check one box):

  • Bug Report
  • Feature Request
  • General Query

My version of UI-Router is: 1.0.6

Feature Request

With older (legacy) version of ui-router, we used to use state.go() with {notify:false} when we wanted to keep the url updated with the app state (e.g. pagination or filters or sort-orders) without reloading the controller.

Since upgrading to 1.0, we have used {dynamic: true} on the respective params. This works fine insofar as updating the query params on the url from state.go() without reloading the controller.

However, what we observe is that the Forward/Back button behaviour is now completely broken - i.e. if the user hits back (or fwd) the UI is not updated. Reloading the controller (dynamic:false) solves those problems, but creates others.

I have learned that I can register a callback to listen for parameters changing - https://ui-router.github.io/ng1/docs/1.0.0/interfaces/ng1.ng1controller.html#uionparamschanged

Although this is a bit more involved than {notify: false} it would work if I could determine the origin of the change - but I can't. Basically I want to ignore any changes in params that have arisen from calls to state.go() because my component has already reacted to that change. I need to know if the param change has come from outside the app - i.e. the user interacting with the browser directly (e.g. Back button or editing the URL directly - which is what our selenium tests do).

There does not seem to be any mechanism that completely replaces notify:false - to fully handle features like pagination, etc - or at least none that are documented or that I have been able to discover.

Thanks

@nickminutello nickminutello changed the title dynamic:true vs notify:false dynamic:true vs notify:false - UI-Router 1.0 Does not appear to be feature-complete Feb 16, 2018
@christopherthielen
Copy link
Contributor

if the user hits back (or fwd) the UI is not updated.

As you know, when using dynamic parameters, the component is not reloaded when a parameter changes. The component itself should listen to and respond to parameter changes.

In the uiOnParamsChanged callback, you can get the source of the transition using trans.options().source. However, I've generally found that the source of the transition (url or ui-sref) shouldn't be relevant to handling the transition in search/pagination scenarios. Dynamic params were introduced with search/pagination specifically in mind, so hopefully it's sufficient!

@JackForbes
Copy link

@christopherthielen I just upgraded to the latest UI Router and have a related question. In quite a few cases on my site I've been using $state.transitionTo with notify: false because I essentially just want to update the url path. In many cases I don't pass params so I can't include dynamic: true on anything. How can I achieve this?

A related question doesn't have a solution that's working for me (e.g. sticky: true).

@buraktamturk
Copy link

buraktamturk commented Jun 27, 2018

I have upgraded to the latest version also, and I have two different states (one is for adding new entry, the second is for editing an existing one) which I want to jump without reloading the view and the controller.

Have anyone worked a solution for this? I was achieving the same thing with "{ notify: false }" and it was working on previous versions.

@stale
Copy link

stale bot commented Jan 24, 2020

This issue has been automatically marked as stale because it has not had
recent activity. It will be closed if no further activity occurs.

This does not mean that the issue is invalid. Valid issues
may be reopened.

Thank you for your contributions.

@stale stale bot added the stale label Jan 24, 2020
@stale stale bot closed this as completed Feb 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants