Skip to content
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

Closed
2 tasks done
ArieGato opened this issue May 8, 2024 · 11 comments · Fixed by #8962
Closed
2 tasks done

Support code generation for Generic components with Type Constraint #8923

ArieGato opened this issue May 8, 2024 · 11 comments · Fixed by #8962
Assignees
Labels
enhancement New feature or request wants to do a PR

Comments

@ArieGato
Copy link
Contributor

ArieGato commented May 8, 2024

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 and class 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

  • I would like to do a Pull Request

Code of Conduct

  • I agree to follow this project's Code of Conduct
@ArieGato ArieGato added the enhancement New feature or request label May 8, 2024
Copy link

github-actions bot commented May 8, 2024

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.

@ScarletKuro
Copy link
Member

ScarletKuro commented May 8, 2024

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.

We actually ended up adding TStruct in the end because of this addition #8881
And I had to slightly modify the code generation.
But I agree, this code generation is giving a lot of limitations.

@henon had some idea how to solve it. Could you share ideas?

@henon
Copy link
Collaborator

henon commented May 9, 2024

It would be a bit more complicated than it is now because using class T was the simplest solution I could come up with.

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.

@jperson2000
Copy link
Sponsor Contributor

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

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.

@ArieGato
Copy link
Contributor Author

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?

@henon
Copy link
Collaborator

henon commented May 13, 2024

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 string as the default for T and only maintain a list of components where string doesn't work and that list is short I'd go for the config list.

Edit: but it could still also be done with an attribute, I am fine with either way.

@ArieGato
Copy link
Contributor Author

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.

@henon
Copy link
Collaborator

henon commented May 13, 2024

Right, that would speak for the attrib solution.

@ArieGato
Copy link
Contributor Author

But the attribute solution is more complex. And I don't have any experience with code generators.

@henon
Copy link
Collaborator

henon commented May 13, 2024

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?

@ArieGato
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request wants to do a PR
Projects
None yet
4 participants