Sould composers be deprecated by components?

[lalo]

In my humble opinion, I’ve found composers (or what used to be controllers) an inferior way compared to components

Composers must be aware of where they are used

which feels like an anti-pattern (children must not be aware of it’s parent)
take this example: https://github.com/roots/sage/blob/10.0.0-dev/app/View/Composers/Post.php
the code must include all sections where the view will be used

In a component, this limitation doesn’t exist.

Global vs Local vars

Global vars have obvious disadvantages like name collisions.

Where does this variable come from?

In a component, it’s always super clear where variables come from. Not so in a composer

what are your thoughts about this?

[evankford]

I think there are natural, distinct roles for Components and Composers w/ Partials. These roles come from the differences you mention: local vs global variable inputs, components being context-agnostic, and the vagueness of variable scope in Composers.

For me, I use Components when I need to pass data to an included template, and I use Composers w/ partials when I need to include a global template part. Even the language feels natural: Components are little snippets of code that process data (Social Icon, Button, Heading, Image), and Partials are template_parts that take global variables rather than local ones (sidebars, footers, headers, contact form popups).

For this reason, I think it would be more unnatural to include an <x-post-content .../> with a bunch of variables every time, rather than including a template partial with it’s own data controller. I suppose it boils down to composers getting their data directly from the DB, and components getting their data from attributes. When you’re going to grab the data from the DB anyway, use a partial.

[lalo]

I like your definition.

I use composers with things that require something global, like $post

(btw, components can get data themselves, in their __construct method)