Skip to content

Pre-RFC: Deprecate partials #390

Closed

Description

@tomdale

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.

Activity

  1. rwjblue commented on Oct 16, 2018

    @rwjblue
    Member

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

  2. knownasilya commented on Oct 16, 2018

    @knownasilya
    Contributor

    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.

  3. ctcpip commented on Oct 16, 2018

    @ctcpip

    @lbeauvilliers it's happening

  4. lbeauvilliers commented on Oct 16, 2018

    @lbeauvilliers

    @ctcpip 😱

    I mean ... 🎉

  5. webark commented on Oct 16, 2018

    @webark

    parsing the partial for all variables, and passing all those into a component seems like a harry task for a codemod..

  6. rwjblue commented on Oct 16, 2018

    @rwjblue
    Member

    You say hairy, I say fun 😜

  7. Alonski commented on Feb 13, 2019

    @Alonski
    Member

    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!

  8. rwjblue commented on Feb 13, 2019

    @rwjblue
    Member

    @Alonski - You might want to report that over on emberjs/ember.js, we haven't intentionally broken anything related to partials...

  9. GavinJoyce commented on Feb 14, 2019

    @GavinJoyce
    Member

    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.

  10. rwjblue commented on Feb 16, 2019

    @rwjblue
    Member

    Nope, nothing blocking other than needing someone to work on it. 😸

  11. GavinJoyce commented on Feb 16, 2019

    @GavinJoyce
    Member

    👍 thanks, I'll draft an RFC soon

  12. GavinJoyce commented on Feb 19, 2019

    @GavinJoyce
    Member

    Here's the RFC to deprecate {{partial}}s:

    #449

  13. ngouy commented on Feb 25, 2019

    @ngouy

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

  14. mydea commented on Feb 25, 2019

    @mydea

    Not sure how "best practice" that is, but you can pass this to a component, e.g.:

    {{! app/components/item.hbs }}
    {{item-child parent=this}}
    {{! app/components/item-child.hbs }}
    {{parent.title}}

    Use with care, but can be useful for some tricky edge cases.

  15. ngouy commented on Feb 25, 2019

    @ngouy

    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

  16. rwjblue commented on Feb 28, 2019

    @rwjblue
    Member

    Closing in favor of #449

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions