Manage query parameter at route only
- Dominant language
- No language data
- Stars
- 801
- Forks
- 409
- PR merge metrics
- No merged PRs in 30d
Description
Query parameters are managed at two places in Ember today: At the controller and it's corresponding route.
This has two main downsides in my opinion:
1. It increases mental overhead as a developer has to recall which configuration goes to the controller and which goes to the route.
2. Managing query parameters is the only reason left for which controllers _must_ be used. This prevents teams to fully migrate away from controllers if they prefer to do so.
How Ember handles query parameter today has several issues. Solving all of them will very likely require a rework of the entire feature. While I think doing so is needed at one point in time, I think it shouldn't block us from shipping small improvements step by step. Making query parameter _not_ blocking migrating away from controllers is a valuable first step in my opinion.
We could allow teams to migrate away from controllers by moving existing query parameter registration and configuration from controller to the route - without requiring any other change to existing feature.
Beside registration and configuration of a query parameter the controller is often used to read and mutated query parameters:
```js
class MyController extend Controller {
queryParams = ["sort"];
sort = "asc";
// read query parameter value
get sortedModel() {
const { sort } = this;
const sortedModel = [...this.model].sort();
if (sort = "desc") {
sortedModel.reverse();
}
return sortedModel;
}
// mutate query paramter value
@action
updateSorting(sort) {
this.sort = sort;
}
}
```
Thanks to the router service query parameter can be read and mutated everywhere - not only through the controller. Interacting with query parameters through `RouterService` does not only allow more flexible architecture. It also makes it explicit that query parameters are changed by a transition - even though that transition may not change current route nor its dynamic segments. This also simplifies the mental model of routing in Ember.
```js
class MyComponent extend Component {
@service router;
// read query parameter value
get sortedModel() {
const { sort } = this.router.currentRoute.queryParams;
const sortedModel = [...this.model].sort();
if (this.sort = "desc") {
sortedModel.reverse();
}
return sortedModel;
}
// mutate query paramter value
@action
updateSorting(sort) {
this.router.transitionTo({
queryParams: { sort }
});
}
}
```
I'm not sure yet how to deal with the default value of a query parameter. Currently a developer can define a default value for a query parameter by providing a default value for a class property of the controller with the same name:
```js
class MyController extend Controller {
queryParams = ["sort"];
sort = "asc";
}
```
This API isn't very intuitive to me. It could be replaced by a `defaultValue` option on the query parameter configuration object. But to be honest I'm not sure if it is needed at all. In my opinion it should be the responsibility of the code, which uses the query parameter value to handle the case that query parameter is not set.
I'm opening this issue to see what community and core team thinks before investing time into writing a fully fledged RFC. Would love to hear your thoughts.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.