You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Partials are widely believed to be a bad idea, but we don't do enough to help people understand that they should always prefer a component to a partial.
We should deprecate partials in Ember, ideally as part of Octane. I believe the only thing blocking this currently is the lack of a deprecation RFC. We may also want a code mod that can automatically migrate the most common partial cases, although I'm not sure if I'd want to block deprecation on that.
We may also want a code mod that can automatically migrate the most common partial cases, although I'm not sure if I'd want to block deprecation on that.
I would like to see a codemod mentioned in the deprecation RFC, but I don't think we need to hold up work on implementing the deprecation for any codemod work...
So just chiming in that after upgrading to Ember v3.7 I am seeing a regression related to Partials that is causing an error in my app.
I am all for deprecating partials!
Is there anything blocking the initial RFC from being created? If not, and it suits, I'd like to volunteer to author the RFC and then help implement the changes needed if it lands.
I don't pretend this stuff is good practices and good patterns/design, but still, without partials, we have to pass all attributes tu the called component. I guess it will be easier with the new ... syntax (I am not sure but I think I saw something like that in the pipes ?)
1 - Not sur it is ^^
2 + in my above exemple, the idea it to have inheritance. In inheritance patern, you don't have to call parent.property when you are accessing smt that "belongs to" your inherited parent
this said you can still working smt out by inheriting your child component by a parent where you write aliases for all of those attributes
Activity
rwjblue commentedon Oct 16, 2018
I would like to see a codemod mentioned in the deprecation RFC, but I don't think we need to hold up work on implementing the deprecation for any codemod work...
knownasilya commentedon Oct 16, 2018
Would https://github.com/dyfactor/dyfactor be the tool for that? I know it's still young, but I think it could handle all partial migrations if done right.
ctcpip commentedon Oct 16, 2018
@lbeauvilliers it's happening
lbeauvilliers commentedon Oct 16, 2018
@ctcpip 😱
I mean ... 🎉
webark commentedon Oct 16, 2018
parsing the partial for all variables, and passing all those into a component seems like a harry task for a codemod..
rwjblue commentedon Oct 16, 2018
You say hairy, I say fun 😜
Alonski commentedon Feb 13, 2019
So just chiming in that after upgrading to Ember v3.7 I am seeing a regression related to Partials that is causing an error in my app.
I am all for deprecating partials!
rwjblue commentedon Feb 13, 2019
@Alonski - You might want to report that over on emberjs/ember.js, we haven't intentionally broken anything related to partials...
GavinJoyce commentedon Feb 14, 2019
Is there anything blocking the initial RFC from being created? If not, and it suits, I'd like to volunteer to author the RFC and then help implement the changes needed if it lands.
rwjblue commentedon Feb 16, 2019
Nope, nothing blocking other than needing someone to work on it. 😸
GavinJoyce commentedon Feb 16, 2019
👍 thanks, I'll draft an RFC soon
GavinJoyce commentedon Feb 19, 2019
Here's the RFC to deprecate
{{partial}}s:#449
ngouy commentedon Feb 25, 2019
the idea of a "kind of component" having the same context as the caller was sometimes very helpfull :
https://blog.nathangouy.com/emberjs-full-component-inheritance/
I don't pretend this stuff is good practices and good patterns/design, but still, without partials, we have to pass all attributes tu the called component. I guess it will be easier with the new
...syntax (I am not sure but I think I saw something like that in the pipes ?)mydea commentedon Feb 25, 2019
Not sure how "best practice" that is, but you can pass
thisto a component, e.g.:Use with care, but can be useful for some tricky edge cases.
ngouy commentedon Feb 25, 2019
1 - Not sur it is ^^
2 + in my above exemple, the idea it to have inheritance. In inheritance patern, you don't have to call parent.property when you are accessing smt that "belongs to" your inherited parent
this said you can still working smt out by inheriting your child component by a parent where you write aliases for all of those attributes
But still, I guess it's not really a good idea
rwjblue commentedon Feb 28, 2019
Closing in favor of #449