question: Does that mean that now we can have component and 2 directives that have the same input name and still apply diffrent values to them?

Like:

<MatButton:a href="https://github.com/admin" [disabled]="false" @HasRipple([disabled]="reducedMotion") @Tooltip(message="Cannot navigate" [disabled]="!hasPermissions")>Admin</MatButton:a>

<MatButton:a

What element will be added to the DOM, <a>?
If MatButton is a component, not a directive, does it mean we can finally create components without a wrapping custom element?

For example, to convert this:

<ul>
  <Example:li>Content</Example:li>
</ul>

into this:

<ul>
  <li>Content</li>
</ul>

question: Does that mean that now we can have component and 2 directives that have the same input name and still apply diffrent values to them?

Yes, all the bindings are targeted so you can pass different values to each of them.

What element will be added to the DOM, ? If MatButton is a component, not a directive, does it mean we can finally create components without a wrapping custom element?

Yes, it will create the MatButton component on an anchor node. We're still thinking if the component should control what node types it can be applied to.

I supposse there will be a RFC but any thoughts about this syntax:

<a href="https://github.com/admin" [disabled]="false" [test-id]="123" @@MatButton([variant]='ghost') @HasRipple([disabled]="reducedMotion") @Tooltip(message="Cannot navigate" [disabled]="!hasPermissions")>Admin</MatButton:a>

this way we won't need to write [attr.test-id] and it will be clear what is html attribute and what are component properties , and mayby even more like

<a (click)="nativeEventHandler()"  @@MatButton((click)="matButtonClickOutputHandler()" @Directive((click)="directiveClickOutputHandler")> 

so again clear distinction between what is html event and angular output

also mayby Generic types?

@Directive()
export class SomeDirecctive<T> {
test = input<T>(); 
}

@SomeDirective<string>( [test]=2]) //error!

It think these are two features here.

Selecterless would get a thumb up from me. Really useful to keep in line with web standard tags without nested weird tag names.

The attribute style thing is sonething that needs discussion.

It think these are two features here.

Selecterless would get a thumb up from me. Really useful to keep in line with web standard tags without nested weird tag names.

The attribute style thing is sonething that needs discussion.

I agree. Selectorlews been lovely using a lite version for a year now. But don't like the @ i much rather use the use: prefix makes it cleaner in my view. Take a look at solidjs

I really like the distinction between html attributes and directives because right now when a directive isn't imported the language service thinks it is a html attribute, and targeted bindings is NEEDED since it solves the overlap when combining directives that have similar inputs/output. good stuff

😅

<div @Dir(...props)></div>

Passing TGP

What element will be added to the DOM, <a>? If MatButton is a component, not a directive, does it mean we can finally create components without a wrapping custom element?

You could always do that with attribute component selectors: a[MatButton], no wrapping custom elements.

We apply styles to taiga.ui(but can be any lib) component/directives or add functionality that we need anytime we use libs Comp/Dir just applying our directive to the same selector as libs Comp/Dir. With the selectorless approach, I don't see a way to do so without manually adding our directives whenever we use libs Comp/Dir, even though we consider it a default state.

We're still thinking if the component should control what node types it can be applied to.

Please don't limit this; at least make such a limitation optional. The only issue I can see right now is that someone might apply it to a void element, but I think the compiler can easily report an error about that.

What element will be added to the DOM, <a>? If MatButton is a component, not a directive, does it mean we can finally create components without a wrapping custom element?

You could always do that with attribute component selectors: a[MatButton], no wrapping custom elements.

With the exception of some elements like input and textarea. Will this new syntax support using input as well?

You could always do that with attribute component selectors: a[MatButton], no wrapping custom elements.

You are right, @waterplea, I confused it with this:

<ul>
 <example>Content</example>
</ul>

@Component({
   template: `<li>Some: <ng-content></ng-content></li>`
})
class Example {}

and result should be:

<ul>
 <li>Some: Content</li>
</ul>

I think selectorless will not allow it either.

Will this new syntax support using input as well?

input is a void element, it can not have content. Applying components is pointless.

😅

<div @Dir(...props)></div>

Is this going to be possible? :D This my biggest pain point regarding this framework 😄

Will the newly proposed Template Syntax for selectorless components/directives also apply to existing components/directives that have a selector specified? In other words, will it be backward-compatible?

I am considering reusing components/directives from older libraries or Angular versions. My idea is to ignore the selector definition when using the new approach. Is that possible?

So why is it <MatButton:a and not <a:MatButton. From a developer perspective, it seems more logical to still go element->directive than the other way around. Especially with the a link its very easy to miss what will be the item in the DOM. Overall I'm not entirely against it, but I don't think this is easy to read compared to what we have now.

And why is it MatButton:a but also @HasRipple and @Tooltip. If we're combining directives, wouldn't it make sense to put the a tag first and just have @MatButton ? And if the use case is that is going to be replaced with why don't we use another kind of input for saying what element we want to have?

Also, something like <#a @MatButton @Tooltip seems more logical to me than the current one. And if you really want MatButton first, than even using <MatButton#a is easier to recognize and scan in a template than using :. But if directives decide that they can replace, it honestly should just be a component instead. If the underlying thought is that the : is referring to its Type, than I think it should follow the entire tag, not just the opening entry.

I can see why you'd want to replace the host with an actual element one can use but I'm not sure if this is the right direction to go for. We could have the parent decide what the element should be, but also have the component itself decide (or even give multiple variants as part of its configuration where the parent can give input to what variant you want. In cases where you'd want a button over a a link. As a common use case right now is to have a button component that replaces both of them.

Sidenote: from the Flow Syntax, I preferred it when you gave the community multiple options and didn't start with a PR but rather a discussion and made clear why you'd want it and what limitations you can think of that decide the boundaries in which the community can provide feedback.

With the exception of some elements like input and textarea. Will this new syntax support using input as well?

What do you mean? You could use it on inputs too. I do that all the time.

@e-oz while it's true that input is a void element and cannot have content it can still have template as a component where you can define ng-template or structural directives to use later, for example you can have some template shown as a dropdown in some scenarios. It's a pretty neat trick that allows you to bake some additional logic in.

Please don't limit this; at least make such a limitation optional.

Limiting tags that components can be applied to absolutely makes sense. You can have a component that is applied to buttons only, because it takes care of disabled state and a version of it for links to look like buttons, for example, but it cannot be applied to random span/div.

We often have the same component twice say my-list for flat lists and my-list[labels] for grouped lists, these are 2 different components that look the same to the end user but are matched by selector. Such things should definitely still be possible, selectors are very powerful. I suppose this whole endeavor is necessary for incremental compilation or something, I just want to make sure it does not take away from our DX/UX.

So why is it <MatButton:a and not <a:MatButton. From a developer perspective, it seems more logical to still go element->directive than the other way around.

💯 @Martinspire — it definitely should be the other way around, especially keeping in mind my argument above. I want to type a and then see autocomplete for all components applicable to a link tag.

And why is it MatButton:a but also @HasRipple and @ToolTip.

Because MatButton is a component and HasRipple/Tooltip are directives. It's not "directives deciding what they should replace", it's literally just a[MatButton] component written in other syntax (and that new syntax supposedly unlocks some benefits).

We could have the parent decide what the element should be, but also have the component itself decide (or even give multiple variants as part of its configuration where the parent can give input to what variant you want. In cases where you'd want a button over a a link. As a common use case right now is to have a button component that replaces both of them.

I want to reiterate, because scanning through this discussion it seems like people are missing this: you can do selector: 'a[myButton], button[myButton]' right now and have your components applied to native tags and whatever tags you want with no intermediary custom element, you do not have to do my-button and then internally decide to use a or button tags, no need for a "button component that replaces both", it can be both.

So why is it <MatButton:a and not <a:MatButton. From a developer perspective, it seems more logical to still go element->directive than the other way around. Especially with the a link its very easy to miss what will be the item in the DOM. Overall I'm not entirely against it, but I don't think this is easy to read compared to what we have now.

I like that even more, so we can have <input:date ... /> (date beeing the component) and the component handles the other attributes, this makes it a lot more logical. No more need for ViewContainerRef.createComponent and ng-container magic and I still can inject inner contents :) love it.

@muuvmuuv what issues with VCR.createComponent and ng-container are you talking about? This changes nothing from writing <input date .../> right now.

Limiting tags that components can be applied to absolutely makes sense. You can have a component that is applied to buttons only, because it takes care of disabled state and a version of it for links to look like buttons, for example, but it cannot be applied to random span/div.

I understand this, but if a user applies something like MatButton to a textarea, then the issue is with the user, not the component. I only ask to make it optional, so by default, a component could be applied to any element, but with an option to explicitly declare the set of supported elements.

One thing i cant see in the inital PR comments and reading through the code. What happening about pipes. Surely same support should be added here. If not is the idea to drop pipes for signals computed values/function calls?

So why is it <MatButton:a and not <a:MatButton>

This would be a good topic for the RFC :) None of the syntax here is set in stone, but we need to start somewhere.

This PR was merged into the repository by commit 92c4123.

The changes were merged into the following branches: main

I like the new selector less syntax, also the host element is great and powerful, but I'm not sure about the @directive syntax. we're using @ for control flow statements. Maybe & like saying "and"

<MatButton:a href="/admin" 
&HasRipple 
&Tooltip(message="Cannot navigate" [disabled]="hasPermissions")
>Admin</MatButton:a>

So we could read it as "MatButton hosted with tag, and HasRipple, and Tooltip".

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}