Description
Is there an existing issue for this?
- I have searched the existing issues
Is your feature request related to a problem? Please describe the problem.
it happens that the required set of attributes in a tag is needed only in one file. In this case, you can:
- either duplicate these attributes for each case. Accordingly, the disadvantage is duplication.
- Or put it in a separate component. Then there are features of a separate component, its separate render, and this logic may have to be further processed somehow. and an extra file
I would like this small component not to be processed as a separate Blazor component.
Describe the solution you'd like
Let's take an example. We have 3 buttons with "hello", "world" classes. And the type of button. First and last button also have some margin left and right classes.
<input class="hello world ml-4" type="button">Btn1</input>
<input class="hello world" type="button">Btn2</input>
<input class="hello world mr-4" type="button">Btn3</input>
First option (QML like)
I want to write something like this
@component("MyInput"){
<input class="hello world" type="button"/>
}
<MyInput class="ml-4">Btn1</MyInput>
<MyInput>Btn2</MyInput>
<MyInput class="mr-4">Btn3</MyInput>
With some custom attribute application policy, for example, addition or complete redefinition (in this example, the component class will be supplemented with information about margin.
the same convenient function is available in the QML language.
Syntax:
component <component name> : BaseType {
// declare properties and bindings here
}
Example:
component MyBtn : Button {
color: "red"
margin: 4
}
MyBtn { text: "Btn1" }
MyBtn { text: "Btn2" }
MyBtn { text: "Btn3" }
Second option (composition like)
We will write a certain set of attributes and give it a name, and the assembly will try to push them into all the tags where we specify this set of attributes
@compose_attributes("MySet"){
class="hello world",
type="button"
}
<input MySet class="ml-4">Btn1</input>
<input MySet>Btn2</input>
<input MySet class="mr-4">Btn3</input>
In this case, we have the advantages of composition in that it is possible to deploy several different sets of attributes in one tag
Important
please note that both methods do not pretend to change the logic of the render. All they do is add a step before compilation to expand this syntactic sugar into what it looks like with manual duplication. And handle errors related to this as if the code was written by hand
(here, of course, the second option is much less advantageous, because it turns out to have a very dynamic nature)
Additional context
Perhaps it has something in common with these requests.
Perhaps this can be solved at the Render Fragment level, but it is more verbose