Breaking "bugfixes" for an eventual 3.0

[nathanhammond]

These are things that are very much broken but we can't change for reasons of backwards compatibility. This list is for a very specific category of issue. These should tend toward mechanical changes.

For example, query params clobber path params inside of the params object passed to the model hook. These should be separated into different keyspaces. This is breaking because it will change how people need to access query params and it's even possible that somebody was relying upon the clobbering behavior. However, with moving toward isolated query param behavior this tremendously reduces the complexity of the problem, skirts around different behaviors with refreshModel and simply setting a controller property, and makes the entire process more easily understood.

As a second example, query strings are serialized and deserialized differently in different layers of Ember. Changing this will obviously be breaking but it must be done to solve the "refresh" problem.

When you comment on this thread please identify why your issue fits this category. The canonical list will be hoisted here. Comments will only be used to identify which things should be promoted to this top post.

• Move query params to a separate key or separate object for params into a route's hooks.
• Correct Query String Serialization and Deserialization ember.js#14174

---

Unconfirmed as to whether they should be promoted:

• Breaking "bugfixes" for an eventual 3.0 #170 (comment)

[Gaurav0]

Computed properties without get or set readonly by default?

[btecu]

• Make get and set optional?
• Make jQuery optional
• Routable components?

Sounds more like a wishlist.

[ghost]

import Component from '@ember/component' please!

[nathanhammond]

Confirm, these are wishlist items which is why I've not promoted them into the top-post. Y'all please keep this to things that are definitely broken but we can't change without likely breaking peoples applications.

For example, the params thing from my first post: query params clobber path params inside of the params object passed to the model hook. Almost certainly somebody relies on this behavior and fixing it requires separating the namespaces. Since that will change semantics and people will need to adjust where they look for properties it is breaking. That params is lossy is a bug.

This list is for a very specific category of issue.

[nathanhammond]

Updated the top post to describe what we're looking for in this thread. Please review.

[runspired]

component.schedule and route.schedule instead of run.schedule (although mostly this can be achieved without a breaking change, I believe we should deprecate global Ember.run)

[nathanhammond]

The function signature for the existing "routing service" is distinct from the function signature of the same method name on the route and controller.

The existing routing service: transitionTo(routeName, models, queryParams, shouldReplace)

The underlying implementation on routes: transitionTo(routeName, ...models, options)

I feel like I've opened a bug on the second invocation in the past for unrelated reasons, but can't find it.

We should make these consistent.

[knownasilya]

Keep inline link-to consistent with block format.

{{link-to Name route}}

vs

{{#link-to route}}
  Name
{{/link-to}}

The order is backwards and gets me every time I use the inline form. I'd expect:

{{link-to route Name}}
{{!-- or for clarity --}}
{{link-to route label=Name}}

[Serabe]

Classic actions as {{action "actionName"}}

[nathanhammond]

@knownasilya I'm personally of the opinion that all of inline {{link-to}} was a mistake. Also any triple-curly {{{link-to}}}. Also {{#link-to}} in general. I'd instead rather deprecate it entirely, but these changes (as well as your proposals) are beyond the scope of this issue.

@Serabe Your proposal also doesn't meet the bar for this thread, it should almost be something that is an unintended side-effect of a feature's implementation.

Both of y'all's proposals have to do with changing documented public API and that would require a deprecation and process. For future travelers if something has ever appeared in the guides there is no way it will be accepted into the top-posted list as that does not count as a bugfix.

[cibernox]

@nathanhammond I agree on deprecating inline {{link-to}}
@Gaurav0 Agree on making computed-properties without a get being readonly by default, although probably some changes already in the pipeline for computed-properties when decorators can be used will already achieve that.

Deprecate component.sendAction (perhaps as part of glimmer-components) so people uses closure actions instead.

[balinterdi]

As the implementer of the inline link-to I feel intrigued :) I understand why the param order should be brought in line (pun intended) with the block form, but do you think it should be scrapped? It does save some typing and thus potential messing up, doesn't it?

[nathanhammond]

@balinterdi My complaints are mostly that the entirety of link-to should go away. Positional arguments that get turned into content are also really a mess... most of Ember doesn't leverage positional arguments so I want to make that consistent since it's a non-zero logical overhead.

[balinterdi]

@nathanhammond Ok, that makes sense. So what is it going to get replaced by?

[rlivsey]

@balinterdi I think the plan is to decompose link-to into a number of helpers & the routing service along the lines of:

<a href={{url-for "foo"}} class={{active-class "foo"}}>
  Name
</a>

This has the added benefit that url-for & friends can be used outside of the context of rendering a link, eg for passing to components / translation libraries, for more easily setting the active class on container elements etc…

link-to could still exist and just use those smaller building blocks vs implementing everything itself in a black box.

[balinterdi]

@rlivsey Now this makes perfect sense, thank you for the explanation!

[knownasilya]

What about emberjs/ember.js#14783 I'd call that a bug, even though some wouldn't.

[sandstrom]

@nathanhammond Can we close this issue? I guess it's not relevant anymore