Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate inline link-to #501

Open
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
8 participants
@NullVoxPopuli
Copy link
Contributor

commented Jun 12, 2019

rendered

@Panman8201

This comment has been minimized.

Copy link

commented Jun 12, 2019

I use inline {{link-to}} fairly often because I never have anything special within the block {{#link-to "route.name"}}Nothing Special{{/link-to}} so inline just shortened it up {{link-to "Nothing Special" "route.name"}}

I don't have a strong feeling one way or the other so meh. 🤷‍♂ But since Glimmer Components don't have positional parameters, and if {{link-to}} will eventually become a Glimmer Component then this RFC make sense.

To the alternate suggestion, I've created components that {{#if (has-block)}}{{yield}}{{else}}{{@text}}{{/if}} as a way to support both options.

@NullVoxPopuli

This comment has been minimized.

Copy link
Contributor Author

commented Jun 12, 2019

I think in a post-curly world, the options would be:

<LinkTo @route='route.name'>
  Nothing Special
</LinkTo>

for block or

<LinkTo @route='route.name' @text='Nothing Special' />

for inline

To the alternate suggestion, I've created components that {{#if (has-block)}}{{yield}}{{else}}{{@text}}{{/if}} as a way to support both options.

Yeah, that's a good way to handle it

@mehulkar

This comment has been minimized.

Copy link

commented Jun 13, 2019

Is a lint rule, build time transform, or codemod possible to handle existing inline link-tos? (I personally don't like build time transforms of my code, but codemod/lint rule would be awesome. Either way, I don't have a horse in this race, since I do not use inline link-to!

This comment has been minimized.

Copy link
Member

commented Jun 14, 2019 — with Octobox

It's definitely easy to write a lint rule for it, and it may be possible to write a simple codemod that would handle the majority of cases.

@robclancy

This comment has been minimized.

Copy link

commented Jun 19, 2019

we made our own component for this which works like this...

<Link @to={{route 'users.show' user.id}}>

The benefit of this is that we can build the route anywhere and have it sent to the link. Whereas if you have separate attributes it gets a bit harder. Obvioulsy we shouldn't be using <Link since it is already used by head stuff.

Just thought I'd mention it, either way I 100 percent want to see this change made.

@lougreenwood

This comment has been minimized.

Copy link

commented Jun 19, 2019

I'm confused, the PR says:

<LinkTo> does not support inline invocation

but above @NullVoxPopuli says:

I think in a post-curly world, the options would be:

<LinkTo @route='route.name' @text='Nothing Special' />

for inline

So does that mean if this RFC is merged, we will need to also add "inline angle bracket link-to" to fill in the gap?

@robclancy

This comment has been minimized.

Copy link

commented Jun 19, 2019

Personally I think the inline should just never be supported. It isn't how HTML works and if you need to add HTML you now need to cut paste therefore maintenance isn't as good. And... actually I take it all back. Because if we support @text then it means you can curry components with the @text already set.

@paulyoder

This comment has been minimized.

Copy link

commented Jun 19, 2019

I use the inline link-to all the time. I would love to see a codemod available if it's deprecated.

@tleperou

This comment has been minimized.

Copy link

commented Jun 19, 2019

Even if I use inline {{link-to}} in my apps, I do agree with @robclancy to limit to only one option.

That makes sense to provide a <Link-to></Link-to>:

  • Developers feel more comfortable with a <a>-like component
  • Emberistas love the convention over configuration philosophy, hence to stick with one opinion
  • Easier to teach. In contrast, it avoids explaining why there are 2 different manners
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.