New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support code generation for Generic components with Type Constraint #8923
Comments
Thanks for wanting to do a PR, @ArieGato ! We try to merge all non-breaking bugfixes and will deliberate the value of new features for the community. Please note there is no guarantee your pull request will be merged, so if you want to be sure before investing the work, feel free to contact the team first. |
We actually ended up adding @henon had some idea how to solve it. Could you share ideas? |
It would be a bit more complicated than it is now because using We'd have to define a mapping of applicable standard types for every component which can be used to instantiate a component such as MudDatePicker ... DateTime, MudSwitch ... bool then the code generator can instantiate the generic types with a type that suits the component and can do all the things it does like getting all public properties using reflection or generating automated test cases, etc. |
Perhaps one or more attribute decorations could help address this? I'm working on docs generator code now; let me know if I can help. |
Personally I'm not a big fan of adding code for unit testing. Although I like the idea that specifying the default generic type is close to the object it describes. @henon what do you think? |
First of all, we only need to configure generic components, which are the minority of our components. And if we for instance decide to use Edit: but it could still also be done with an attribute, I am fine with either way. |
That was my idea as well. It's just that I think code is generated at two places. So we have to add a dictionary of default generic types on two places. |
Right, that would speak for the attrib solution. |
But the attribute solution is more complex. And I don't have any experience with code generators. |
Getting an attribute from a type via reflection is very easy. No need to use code generators for this or do you mean our code generators for the docs and unit tests? |
I was actually wrong about the code being generated at two places. There are two occurences of class T though. Let me finish my PR and you can have a look at it |
Feature request type
Other
Component name
Unit Tests
Is your feature request related to a problem?
Code is generated for testing and documentation through reflection. For generic components two classes have been introduced.
class T
andclass U
. This works fine when there are no type constraints.For the MudSlider an implementation for INumber has been added. I think this is not sustainable. For the new Date Picker a constraint is added
where T : struct
.Describe the solution you'd like
I though about it a long time, but can't come up with a solution that uses Reflection. So I propose that we add some sort of dictionary for exceptions that will be used to generate the code. In the dictionary generic components can be added with the actual implementation that needs to be generated. In case of the MudSlider it could be a combination
typeof(MudSlider<>), typeof(MudSlider<decimal>)
.Have you seen this feature anywhere else?
No response
Describe alternatives you've considered
No response
Pull Request
Code of Conduct
The text was updated successfully, but these errors were encountered: