-
-
Notifications
You must be signed in to change notification settings - Fork 57
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
Varargs for Seq[ReactElement] children #478
base: main
Are you sure you want to change the base?
Conversation
The way the @react macro works, if you want an apply method that takes varargs children you have two options: 1. ReactElement* in the first parameter list. 2. ReactElement* in another parameter list. Option 1 means no other parameters can have default values. Option 2 means props values cannot be easily manipulated because no copy method is generated. A 3rd option: convert Seq[ReactElement] into a varargs parameter would break compatibility with existing code. This change introduces a boolean `expandChildrenSeq` parameter to the @react annotation. If `true` a `children: Seq[ReactElement]` parameter will be converted into a varargs `ReactElement*` parameter in the generated apply method, enabling both default parameter values for other props parameters and a generated copy method.
scalafmt seems to have reformatted more than my changes. Not sure why. |
q"${ps.name}: _*" | ||
} else q"${ps.name}" | ||
} | ||
childrenParam.get.tpt match { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we could make this even more general, based on the comments in #237, by having expandChildren
make children
curried regardless of the parameter type. That would line up with JSX behavior better too. And since expandChildren
is false by default, there's no worry of unexpected behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jedahu thinking about things a bit more, I'm fairly convinced myself that removing the type restriction is the way to go; if you think that makes sense could you go ahead and remove it?
Looks great overall! Just one API design possibility to ponder. |
@jedahu I think we can merge this PR and then generalize the support later; could you add a quick note to the changelog and docs explaining this feature? |
7b5ecd9
to
72a3416
Compare
The way the @react macro works, if you want an apply method that takes varargs children you have two options:
Option 1 means no other parameters can have default values. Option 2 means props values cannot be easily manipulated because no copy method is generated.
A 3rd option: convert Seq[ReactElement] into a varargs parameter would break compatibility with existing code.
This change introduces a boolean
expandChildrenSeq
parameter to the @react annotation. Iftrue
achildren: Seq[ReactElement]
parameter will be converted into a varargsReactElement*
parameter in the generated apply method, enabling both default parameter values for other props parameters and a generated copy method, and preserving compatibility with existing code.