Breaking "bugfixes" for an eventual 3.0 about rfcs

[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.

[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)

[Gaurav0]

Computed properties without get or set readonly by default?

[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.

[btecu]

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

Sounds more like a wishlist.

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.

[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?

[balinterdi]

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

[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