-
Notifications
You must be signed in to change notification settings - Fork 21
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
Possible legal values for parameters #151
Comments
Does such a feature makes sense? |
IMO it does but it can't be implemented like this as far as I could see. The parameters are converted to native fluid parameters and there it is not possible to add an additional attribute like yours. |
This is the viewhelper I've used for such cases
|
Another possibility just for the "in list" case could be to add literal and union types, like TypeScript has: https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#literal-types But I'm not sure if it's worth the trouble implementing this. |
Something like this? <fc:param name="align" type="literal" cases="{'left', 'right'}" />
<fc:param name="prime" type="literal" cases="{2, 3, 5, 7}" />
// not valid
<fc:param name="prime" type="literal" cases="{'left', 2, 3, 5, 7}" /> |
More like: <fc:param name="align" type="'left' | 'right'" /> |
+1 for this feature! I found this example for a Button component with three variants. If both params are false, then it's the default variant. <fc:param name="isPrimary" type="boolean" optional="1" default="0" />
<fc:param name="isSecondary" type="boolean" optional="1" default="0" /> In my view this syntax would be much better: <fc:param name="variant" type="'default' | 'primary' | 'secondary'" /> |
It would be nice to define possible legal values for an parameter. Without having to introduce a custom data structure.
I think an implementation would not a big deal.
I thought about to enable
enum
as parameter type but we would not be able to pass an enum case in an fluid template. So the value of the parameter would be a string anyway. To then pass the string to thetryFrom
function of the enum does not feel right and overdone.Maybe enum will have usecases but for many cases I can think of now, a simple list, defined within the parameter tag would be very handy.
[written on smartphone, pull request will follow]
The text was updated successfully, but these errors were encountered: