-
Notifications
You must be signed in to change notification settings - Fork 54
feat(Radio): radio button base implementation #100
Conversation
Codecov Report
@@ Coverage Diff @@
## master #100 +/- ##
==========================================
- Coverage 88.37% 88.35% -0.02%
==========================================
Files 45 47 +2
Lines 757 773 +16
Branches 100 109 +9
==========================================
+ Hits 669 683 +14
- Misses 85 87 +2
Partials 3 3
Continue to review full report at Codecov.
|
504a834
to
9860779
Compare
display: 'inline-flex', | ||
position: 'relative', | ||
alignItems: 'center', | ||
justifyContent: 'flex-end', |
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.
could you, please, suggest where this is necessary?
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.
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.
but the justifyContent will be removed from here in next update
|
||
label: ({ props, variables }): ICSSInJSStyle => { | ||
return { | ||
alignItems: 'center', |
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.
this one is unnecessary (has no effect for this display
value)
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.
true, thanks, will fix
src/themes/teams/siteVariables.ts
Outdated
@@ -63,6 +63,8 @@ export const timestampTextColor = gray04 | |||
// | |||
// Fonts | |||
// | |||
export const fontSizeLarge = pxToRem(24) | |||
export const fontSizeMedium = pxToRem(18) |
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.
a bit confused what is the difference between medium
and base
?
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 is smaller than medium - pairing the sizes from current Teams app so that I can provide the example accordingly
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.
will keep the default value of the font-size for now to keep the changes to minimum
export default (siteVars: any) => { | ||
const vars: any = {} | ||
|
||
vars.fontSize = siteVars.fontSizeMedium |
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.
actually, just for the sake of simplifying things a bit - maybe we could just hardcode some value here for now, and return to that later. However, just expressing my thoughts on that - please, feel free to reason by yourself what would be better; nevertheless, in case we would like to leave this changes here, we'd better to make decision about names for fontWeight
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 see that the default fontWeight is set to 500 and we need 400 for parity with Teams existing styles.
src/components/Radio/Radio.tsx
Outdated
|
||
return ( | ||
<ElementType {...rest} className={classes.root} {...htmlInputProps}> | ||
{createHTMLInput(input || type, { |
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.
while it seems that I do see where this intent goes (and totally support it) with introducing type
property that would be a superset of input
values - and, at the same time, would be able to extend these values to slider
or toggle
variants, just for the sake of simplifying things I would rather suggest to omit this type
property for now (although, surely, we will need it later).
Primary reason is that currently this logic is a bit misleading - if type
is passed as an argument to createHTMLInput
, it does mean that all the values that could be passed to type
property should be valid values for HTML input
one. But, in that case, we might have reasonable question of why we would need two properties that will, effectively, duplicate each other (as it is now - once again, this might change in future) - and, by that leading library's client to confusion about which one should be used from these two, as well as which one will take precedence.
Please, let me know about your thoughts on that.
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.
That is a good point.
I was thinking pretty much on it, whether to add a full new component or to extend the existing Input by providing a different type to the example. I still think that having a different component (Radio in this case) might be easier for the user to understand what she is writing. In the same way we will write a Checkbox component when needed.
However I don't have the full picture on whether the users would like to further create an Input with type 'button', 'color' or 'date' which of course will require different styling and different properties attached. Will need further debate on it for the right implementation here, but until then I will remove the type from the creation of the input, to remove any doubt.
label: ({ props, variables }): ICSSInJSStyle => { | ||
return { | ||
alignItems: 'center', | ||
cursor: 'pointer', |
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.
one thing that I am missing with that is an ability to check Radio
by clicking on label. Seems that we should do either of two
- do not introduce this style property now
- or introduce support for radio selection by clicking on its label
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.
will chose the first option for the base implementation
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.
👍 everything looks nice, have left couple of comments. One thing that I do see really important before merging this is to resolve question around behavior on label click
Regarding the label click, it would be ideal if we can get the input to be a child of the label. This will avoid a lot of complexity in the component that we face over at Semantic UI React. |
src/components/Radio/Radio.tsx
Outdated
|
||
renderComponent({ ElementType, classes, rest, styles }) { | ||
const { input, type, label } = this.props | ||
const [htmlInputProps, restProps] = this.partitionProps() |
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.
Heads up, restProps
is unused here and the ElementType below is spreading the rest
props received from renderComponent
instead.
9860779
to
174e8cb
Compare
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.
please, fix docs issue and it seems that we are good to merge :)
actually, almost overlooked Levi's comment about reusing Unfortunately, currently it is not possible because for the layout that |
Radio
A basic radio button.
TODO
API Proposal
Default