49 raises an issue around Refresh, where parameters will be less accessible, so it needs to be considered how we can make them more accessible when using refresh.
But beyond that, this is about restructuring the parameter object, and how it is passed around... Right now we have:
$routeParams : We don't wan't to be dependent on this, in fact this should be pushed out into the legacy module over time.
$state.current.$params : { all, path, search } : This is what was meant to be used, but it is deeply nested so it gets annoying to access.
That leaves us without any options.
One solution would be to define a property for parameters directly on $state, like $state.params, or alternatively add a $stateParams value to the injector like UI-Router does, the later is ok but I feel that people will often end up including both the parameters and state service anyways, and so $stateParams over $state.params seems to add very little value, if any at all...
However, having to type params.all etc is tedious as well. so we need to redesign that part as well, but being able to filter out the different parameters in could be handy in some cases not to mention that optional and search parameters should be available... So changing to an implementation with reserved property names seems like a way to go, like so:
{
// ['x'] -> Path or All ?? - Depending on the choice of the outer object, either `$all` or `$ goes away path`
$all : {}, // -> Returns all parameters
$path : {}, // -> Returns route parameters
$search : {} // -> Returns search parameters
}
jeme
commented
11 years ago
49 raises an issue around Refresh, where parameters will be less accessible, so it needs to be considered how we can make them more accessible when using refresh.
But beyond that, this is about restructuring the parameter object, and how it is passed around... Right now we have:
$routeParams: We don't wan't to be dependent on this, in fact this should be pushed out into the legacy module over time.$state.current.$params : { all, path, search }: This is what was meant to be used, but it is deeply nested so it gets annoying to access.That leaves us without any options.
One solution would be to define a property for parameters directly on
$state, like$state.params, or alternatively add a$stateParamsvalue to the injector like UI-Router does, the later is ok but I feel that people will often end up including both the parameters and state service anyways, and so$stateParamsover$state.paramsseems to add very little value, if any at all...However, having to type
params.alletc is tedious as well. so we need to redesign that part as well, but being able to filter out the different parameters in could be handy in some cases not to mention that optional and search parameters should be available... So changing to an implementation with reserved property names seems like a way to go, like so: