fix(ui-sref): Allow sref state options to take a scope object

[jhicken]

The tests pretty well outline the problem. Look at them if you want to see what is accomplished.

Basically when you try to use an object on a scope as your parameters for ui-sref. On a digest churn no updates occur. This fixes that problem.

$rootscope.scopeVar = {a:'1',b:'asd'}
ui-sref="something.something(scopeVar)"

[ProLoser]

Is this just a convenient alternative to ui-sref="something.something({a:'1',b:'asd'})" which I think works too?

[jhicken]

The idea is that... I keep a global object on $rootScope or in a service that contains my global url prams. Then you use that object from local or rootScope to populate all of your ui-srefs. So instead of doing this ui-sref="something.something({a:'1',b:'asd'})"... You would do ...

$rootscope.urlParams = {a:'1',b:'asd'}
ui-sref="something.something(urlParams)"

This also makes it so when you change one of the values inside your urlPramas your ui-srefs are updated to link to the correct place.

Without this when you change that urlParams object, ui-srefs simple ignore your changes until new DOM elements are loaded with new srefs.

[ProLoser]

So I don't necessarily disagree that you should not be able to use the
syntax you mention, I don't run into your problem because I feel you are
creating two different "sources of truth" regarding the active params. For
me, the logic you are using to update your service or scope data should
probably just change the state directly and treat the params as readonly.
On Sep 20, 2014 2:46 PM, "Jeff Hicken" [email protected] wrote:

The idea is that... I keep a global object on $rootScope or in a service
that contains my global url prams. Then you use that object from local or
rootScope to populate all of your ui-srefs. So instead of doing this
ui-sref="something.something({a:'1',b:'asd'})"... You would do ...

$rootscope.urlParams = {a:'1',b:'asd'}
ui-sref="something.something(urlParams)"

This also makes it so when you change one of the values inside your
urlPramas your ui-srefs are updated to link to the correct place.

Without this when you change that urlParams object, ui-srefs simple ignore
your changes until new DOM elements are loaded with new srefs.

—
Reply to this email directly or view it on GitHub
#1141 (comment).

[jhicken]

So thats great in most cases. In fact its really nice not having to worry about passing your urlParams in most cases. However this is a large application with some robust needs. My problem is I have 2 different state sets. Also I have a settings area that there is no place for url params in the URL (a third state set). Thats on purpose to avoid mixing state info. Also that settings page changes parts of the current url params objects. So I need to keep my url params for different states in a separate location.

[nateabele]

This seems fine to me, but it looks like it needs to be rebased and cleaned up a bit. Also, there's already a describe() block for links, which would be the appropriate place for the new tests.

[jhicken]

Rebased and moved the tests am I missing anything?

[nateabele]

Nope, merged.