ux

ux copied to clipboard

First I want to thanks and congratulates @weaverryan and all people involved in making those 2 new components 👏!

I just start a fresh new project, using the Twig Component. and it's already saving me some extra work, this is really appreciate.

Here is a list of some suggestions that could improve this package:

Default path

Add a Bundle configuration parameter default_path, similar to the one for Twig, to define where components are stored.

default_path: '%kernel.project_dir%/templates/components' # default value

Additional paths

Be able to defined multiple Component paths. This can be useful in applications where we want to split each parts:

component_paths: 
 - '%kernel.project_dir%/templates/website/components'
 - '%kernel.project_dir%/templates/admin/components'
 - '%kernel.project_dir%/templates/common/components'

When rendering, it will parse each path to find the component template then fallback to default_path if none is found.

Prefix

It's a common practice to prefix "partial" twig template with _ (e.g. _form_delete.html.twig). Being able to define a "global" prefix without having to specified it in the getComponentName method will be great. The prefix will be concatenate with the component name.

component_prefix: '_' # optional, none by default

Alternate templates

Sometimes, depending on the context, it can be useful to display the component with a different template.

public function getComponentTemplate(): string
{
    return match(this->context) {
        $this->foo() => 'bar',
        $this->bar() => 'foo',
    };
}

Maker command

I'm pretty sure this one is already in the pipe, but having a make:component command to quickly build a component will save some extra work!

WDYT ?

Hey @ker0x!

Thanks for testing things and giving feedback. That is 💯!

I think what you're asking for is entirely sensible - it's just a matter of getting the details right.

We're using the main Twig service, so we need to use paths that are known to twig - e.g. the default path (templates/) or any Twig namespaces that you might have configured. So, in general, instead of default_path: '%kernel.project_dir%/templates/components' it would be something more like default_path: 'components/' .

Be able to defined multiple Component paths. This can be useful in applications where we want to split each parts

To try to play devil's advocate (i.e. find an existing solution that works), in #106, we will likely add a "template" option to the PHP 8 attribute - something like this:

#[AsTwigComponent('alert', 'notifications/alert.html.twig')]

So, in your case, it would require you to explicitly define the template path if a component knows its template will live inside for example, an admin directory.

Btw, the above feature complicates the default_path idea also. If I specify the template name like above, then... I don't think we can use the default_path (because it looks like the user is giving us a full, final template path - templates/notifications/alert.html.twig). I'm not sure if there is a way around that: it seems that we either use the default_path OR the user tells us the template and we full do NOT use the default path. I would like to keep it simple.

It's a common practice to prefix "partial" twig template with _

Perhaps a default_template_name with a special {name} syntax in there that's replaced by the template name?

default_template_name: '_{name}.html.twig'

Then you could do all kinds of crazy things ;).

Sometimes, depending on the context, it can be useful to display the component with a different template

This has occurred to me too. My current thinking is that if you have this case, you can have conditional in your template. I'm not against this... but unless it's a super common thing that we end up needing to do, it's already possible with template conditionals.

I'm pretty sure this one is already in the pipe, but having a make:component command to quickly build a component will save some extra work!

Yes! It's already done in another library somewhere... @kbond just needs to polish it and push it up. But the initial version will probably be pretty spartan. We're open to ideas on what and how many questions we should ask to make it better. Right now, it asks for your component name and whether or not you want it to be a live component... but that's all.

Cheers!

Hello,

Be able to defined multiple Component paths. This can be useful in applications where we want to split each parts.

In line with this comment, it might be usefull to specify a "namespaces" convention for twig and live components.

This would make it possible to:

• create reusable twig coponents in a twig bundle, that doesn't conflict with your application's twig components. (someBundle:xxx)
• implement structures like atomic twig components (atom:button, molecule:button-list, organism:header-menu)

(I didn't see anything like this in the documentation. Yet, it is possible to use the semicolon for this in both twig components and live components.)

This could make it possible to specify a smart mapping between namespace and default location of twig template as well.

create reusable twig coponents in a twig bundle, that doesn't conflict with your application's twig components. (someBundle:xxx)

My thinking here is to ensure bundles define their own prefix (and template) in their component definitions:

#[TwigComponent(name: '@MyBundle:my_component', template: '@MyBundle/components/my_component.html.twig')]
class MyComponent {}

(I didn't see anything like this in the documentation. Yet, it is possible to use the semicolon for this in both twig components and live components.)

For this to work, you currently have to customize the template for the component? I guess you're thinking atom:button should auto-resolve to templates/components/atom/button.html.twig?

yes, that looks nice. Auto resolving would indeed be nice. That way you don't have to specify the template. But I wouldn't mind that much if it didn't autoresolve either.

Thank you for this issue. There has not been a lot of activity here for a while. Has this been resolved?

I'm closing this issue as all suggestions have been addressed and resolved! 👍