-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
[Control] add labelElement prop #1378
Conversation
Type label with ReactNodePreview: documentation |
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.
Just checked into the typings for ReactNode
to make sure string
s, number
s, etc., were still supported. Looks like we're good!
//
// React Nodes
// http://facebook.github.io/react/docs/glossary.html
// ----------------------------------------------------------------------
type ReactText = string | number;
type ReactChild = ReactElement<any> | ReactText;
// Should be Array<ReactNode> but type aliases cannot be recursive
type ReactFragment = {} | Array<ReactChild | any[] | boolean>;
type ReactNode = ReactChild | ReactFragment | boolean;
❌ THIS DOES NOT COMPILE. Try actually using it in JSX: <Checkbox label={<strong>"Gilad Gray"</strong>} defaultIndeterminate /> and you'll see an error:
this is because edit: notice how each type in parens above is @llorca please add |
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.
❌ see comment
add example to each Control docs sectionPreview: documentation |
@@ -17,8 +17,11 @@ import * as React from "react"; | |||
import * as Classes from "../../common/classes"; | |||
import { IProps, removeNonHTMLProps } from "../../common/props"; | |||
import { safeInvoke } from "../../common/utils"; | |||
import { HTMLInputProps } from "../../index"; | |||
|
|||
export interface IControlProps extends IProps, HTMLInputProps { |
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.
🎉
]; | ||
|
||
/** Base Component class for all Controls */ | ||
export class Control<P extends IControlProps> extends React.Component<React.HTMLProps<HTMLInputElement> & P, {}> { | ||
export class Control<P extends IControlProps> extends React.Component<P, {}> { |
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.
Do we still need <P extends IControlProps>
if we already have interfaces extending IControlProps
, such as export interface ICheckboxProps extends IControlProps
?
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.
yes it enforces that the P
is a subclass of IControlProps
, so I can't pass IDialogProps
, for instance. these two extends
are separate things.
@@ -62,6 +79,7 @@ export class Control<P extends IControlProps> extends React.Component<React.HTML | |||
<input {...inputProps} ref={inputRef} type={type} /> | |||
<span className={Classes.CONTROL_INDICATOR} /> | |||
{this.props.label} | |||
{this.props.labelElement} |
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.
If both label
and labelElement
props are provided, do we still render both?
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.
what does the code say?
yes, and label
comes first.
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.
@giladgray Apologies, I meant to ask if we actually want to render both. Sounds error-prone to allow both at the same time
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.
why? it's just JSX children, there's no limit. seems more error-prone to only render one.
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 just can't imagine a case where setting those two props at the same time would be intentional. Probably a false concern 🤷♂️
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.
nor can i, but doing the simple thing works reasonably well in all cases here 🍰
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.
love it
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.
Yesss.
<Switch labelElement={<strong>Enabled</strong>} /> | ||
<Switch labelElement={<em>Public</em>} /> | ||
<Switch labelElement={<u>Cooperative</u>} defaultChecked /> | ||
<small>This example uses <code>labelElement</code> to demonstrate JSX labels.</small> |
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.
👏
curious, why add |
@thasner scroll up and read the convo, especially this comment: #1378 (comment) |
👍 |
Fixes #1351
A new prop must be added for TypeScript support because the existing
label
prop inReact.HTMLAttributes
only acceptsstring
values, so tsc rejects JSX elements.JS consumers can happily pass JSX to the
label
prop (cuz no compiler to stop them and the code does actually support JSX) but we need to add a new prop to sidestep the typings for TS consumers.