-
Notifications
You must be signed in to change notification settings - Fork 14
Description
The default behavior of Ember's <LinkTo> is to keep the query parameters of parent routes.
<Link> does not auto-append any query parameters to the generated URL. They need to be passed in explicitly via @query. This is über annoying, when you want to use <Link> as a substitute for <LinkTo> in a scenario where a child route links back to a parent route.
<Link> and {{link}} should offer a @keepQuery option. It can take these values:
none/ falsy value (default, current behavior): No QPs of the current location are kept.- Only QPs provided via
@queryare appended.
- Only QPs provided via
known: Only QPs of the current location at the time of invocation that are defined as known QPs in the current route hierarchy are kept.- QPs provided via
@queryoverride these QPs individually. - A
null/undefiendvalue in the@queryobject will remove a kept QP.
- QPs provided via
all: All QPs of the current location at the time of invocation are kept.- QPs provided via
@queryoverride these QPs individually. - A
null/undefiendvalue in the@queryobject will remove a kept QP.
- QPs provided via
tracked-known: Only QPs that are defined as known QPs in the current route hierarchy are kept.- When the the current route / QPs change, the
urlwill be updated live. - QPs provided via
@queryoverride these QPs individually. - A
null/undefiendvalue in the@queryobject will remove a kept QP.
- When the the current route / QPs change, the
tracked-all: All QPs of the current location are kept.- When the the current route / QPs change, the
urlwill be updated live. - QPs provided via
@queryoverride these QPs individually. - A
null/undefiendvalue in the@queryobject will remove a kept QP.
- When the the current route / QPs change, the
Unresolved Questions
none is the current behavior. Changing this would be a breaking change IMO, so I'd make it the default, too. Do we want to keep it this way though or switch to a different default?
Assuming we want to switch, we could raise a deprecation warning, prompting the user to explicitly chose none or a different behavior.
Should the default be configurable or should we allow users to opt-in to the new default mode prior to upgrading to the next major version?
Do the names used here make sense? @keepQuery, none, known, all, tracked-*, untracked-*?
Do we need the tracked-* variants? Or do we not need the untracked variant? Should the untracked variants also be prefixed with untracked-*? Or should the tracked-* variants instead have no prefix?