Skip to content

Allow state options to be overidden in ui-sref directive #694

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
wants to merge 2 commits into from
Closed

Allow state options to be overidden in ui-sref directive #694

wants to merge 2 commits into from

Conversation

IcanDivideBy0
Copy link

Options passed to the $state.go() and $state.href() cannot be changed while using the ui-sref directive.

@caitp
Copy link
Contributor

caitp commented Dec 31, 2013

hmm, I can see that it's flexible, but hmmm... I'm not sure how I feel about this

@IcanDivideBy0
Copy link
Author

Since params are parsed with a regex, we cannot add options in the same place ... I can see only two options :

  • stop using regex to parse prams and add options in ui-sref directive
  • using the ui-sref-opts attribute proposed here

Anyways, I think that using regex for this kind of stuff is the wrong way to go.

@timkindberg
Copy link
Contributor

This has actually already been brought up and rejected in a different pull request, but this is a different approach. This approach matches what @nateabele had mentioned was his idea for implementation in his last comment. See #644.

I think I'm ok with this enhancement. @nateabele?

@@ -35,6 +35,9 @@ function stateContext(el) {
* to the state that the link lives in, in other words the state that loaded the
* template containing the link.
*
* Options passed to the `$state.go()` also can be overiden with the `ui-sref-opts`

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo: overiden => overridden

@nateabele
Copy link
Contributor

Finally following up on this... I can definitely see some jankyness happening if people are able to arbitrarily overwrite any go() option (i.e. since some of them are calculated). I think at a minimum we should lock it down to whatever options you'd actually want to change. IMO location, inherit, and reload are probably enough. @caitp is that about what you were thinking?

@caitp
Copy link
Contributor

caitp commented Jan 18, 2014

That's the gist of it... If there are specific options supported, it seems less harmful. One thing I don't necessarily want is another $watch, this should probably be evaluated only at link-time.

Anyways, it's just my opinion :>

@nateabele
Copy link
Contributor

Well, at worst I guess we could $watch the union of this and ui-sref, right?

@roryf
Copy link

roryf commented Jan 23, 2014

Any update on this being merged? If there's changes to be made, I can jump in.

@nateabele
Copy link
Contributor

Any update on this being merged? If there's changes to be made, I can jump in.

@roryf Yeah, could you? Here's what's outstanding:

  • Needs to be rebased, since HEAD has diverged
  • Needs to be brought into line with contributor guidelines
  • Needs to respect restrictions discussed above

Please feel free to fire off any questions you might have.

@nateabele
Copy link
Contributor

Implemented in #813.

@nateabele nateabele closed this Feb 17, 2014
@timkindberg
Copy link
Contributor

This makes me feel like we should have done ui-sref-params as a separate directive too, instead of coming up with our own string syntax there.

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

Successfully merging this pull request may close these issues.

6 participants