-
-
Notifications
You must be signed in to change notification settings - Fork 407
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 {{partial}} #449
Conversation
5834b0f
to
302825c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👏 awesome, thank you for putting this together @GavinJoyce!
I'm 1000000% in favor...
This is an RFC that I'd assumed had happened already! We've been treating partials as deprecated for years! |
I guess it's more appropriate to post it here :
the idea of a "kind of component" having the same context as the caller was sometimes very helpful : I understand the reason of deprecating this for simplifications and performence reasons, I just wonder how it will be possible to do something like that later on... passing all attributes with |
There is |
Ok my bad I thought I saw something like this in a RFC. It would have been a great tool to have a smooth transition on this one, but giant thing to implement due to bunch of corner cases I guess. |
Great writeup, @GavinJoyce. This is long overdue, and perhaps one of the least controversial deprecations RFCs to ever come across the core team desk. 😉 We're moving this one to Final Comment Period, so please chime in now if you've got concerns with the proposal as written. |
Regarding the migration script: Mostly the use cases considered are looking at downward data flow. We should consider |
@mixonic yep that would break because this form of action implicitly closes over {{!--outside--}}
<ConvertedFromPartial ... @action={{action 'foo'}} .../>
{{!--inside--}}
<button {{action @action}}> |
I'm fully in favour of this deprecation, but I don't think a codemod that fully automates the migration will land. There is too much implicit two-day data flow going on with partials to be safely handled by static analysis. If this library was still active, it may have been possible, but probably beyond difficult for smaller teams to manage. I think a codemod that superficially converts partials to components (and generates the placeholder component files), followed by a list of items migrated, would greatly help with the migration process, but a large part of it will most likely be arduous and manual. Still worth it as we've noted that partials are a point of incredible confusion when we onboard a new developer into our team. |
@omairvaiyani agree to disagree 😸, I believe the codemod steps discussed in this RFC would work fine and the number of cases that were not possible would be limited to those where you have partial usage inside of a partial. However, I also agree with you that even without codemod support, this RFC is still worthwhile. |
@GavinJoyce can you update the RFC to include the |
c0be65f
to
4ec9069
Compare
@chancancode I've updated the deprecation details to include an example action:
{{#let (hash title="Don't use partials" body="Components are always better") as |tip|}}
{{partial "partials/quick-tip"}}
{{/let}}
<h1>Tip: {{tip.title}}</h1>
<p>{{tip.body}}</p>
<button {{action 'dismissTip'}}>OK</button> Here's the same template code after migrating the
{{#let (hash title="Don't use partials" body="Components are always better") as |tip|}}
<QuickTip @tip={{tip}} @onDismiss={{action 'dismissTip'}} />
{{/let}}
<h1>Tip: {{@tip.title}}</h1>
<p>{{@tip.body}}</p>
<button {{action @onDismiss}}>OK</button> |
🎉 Thanks @GavinJoyce! |
closes #390
Rendered