Skip to content
This repository has been archived by the owner on Mar 4, 2020. It is now read-only.

feat(Radio): radio button base implementation #100

Merged
merged 9 commits into from
Aug 22, 2018

Conversation

alinais
Copy link
Contributor

@alinais alinais commented Aug 16, 2018

Radio

A basic radio button.

TODO

  • Conformance test
  • Minimal doc site example
  • Stardust base theme
  • Teams Light theme
  • Teams Dark theme
  • Teams Contrast theme
  • Confirm RTL usage
  • W3 accessibility check
  • Stardust accessibility check
  • Update glossary props table
  • Update the CHANGELOG.md

API Proposal

Default

image

<Radio label="Make your choice" />
<div class="ui-radio" type="radio">
  <input type="radio" />
  <label class="ui-label">Make your choice</label>
</div>

@codecov
Copy link

codecov bot commented Aug 16, 2018

Codecov Report

Merging #100 into master will decrease coverage by 0.01%.
The diff coverage is 88.23%.

Impacted file tree graph

@@            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
Impacted Files Coverage Δ
src/components/Radio/index.ts 100% <100%> (ø)
src/index.ts 100% <100%> (ø) ⬆️
src/components/Radio/Radio.tsx 86.66% <86.66%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cfd9700...148934b. Read the comment docs.

@alinais alinais force-pushed the feature/radio-button-base-implementation branch from 504a834 to 9860779 Compare August 20, 2018 10:54
display: 'inline-flex',
position: 'relative',
alignItems: 'center',
justifyContent: 'flex-end',
Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image

Copy link
Contributor Author

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',
Copy link
Contributor

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)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

true, thanks, will fix

@@ -63,6 +63,8 @@ export const timestampTextColor = gray04
//
// Fonts
//
export const fontSizeLarge = pxToRem(24)
export const fontSizeMedium = pxToRem(18)
Copy link
Contributor

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?

Copy link
Contributor Author

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

Copy link
Contributor Author

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
Copy link
Contributor

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

Copy link
Contributor Author

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.


return (
<ElementType {...rest} className={classes.root} {...htmlInputProps}>
{createHTMLInput(input || type, {
Copy link
Contributor

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.

Copy link
Contributor Author

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',
Copy link
Contributor

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

Copy link
Contributor Author

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

Copy link
Contributor

@kuzhelov kuzhelov left a 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

@levithomason
Copy link
Member

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.


renderComponent({ ElementType, classes, rest, styles }) {
const { input, type, label } = this.props
const [htmlInputProps, restProps] = this.partitionProps()
Copy link
Member

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.

@kuzhelov kuzhelov added needs author changes Author needs to implement changes before merge and removed 🚀 ready for review labels Aug 21, 2018
@alinais alinais force-pushed the feature/radio-button-base-implementation branch from 9860779 to 174e8cb Compare August 21, 2018 17:15
@alinais alinais added comments addressed 🚀 ready for review and removed needs author changes Author needs to implement changes before merge labels Aug 21, 2018
@kuzhelov
Copy link
Contributor

kuzhelov commented Aug 22, 2018

currently experiencing the following problem while trying to run docs from the branch. Easy fix, but needs to be introduced

image

Copy link
Contributor

@kuzhelov kuzhelov left a 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 :)

@kuzhelov
Copy link
Contributor

kuzhelov commented Aug 22, 2018

actually, almost overlooked Levi's comment about reusing Input component - yes, absolutely agree, we should do it this way.

Unfortunately, currently it is not possible because for the layout that Input component introduces (input element turns out to be wrapped by div). Will create an issue for that and address it asap

@kuzhelov kuzhelov merged commit 0dff885 into master Aug 22, 2018
@kuzhelov kuzhelov deleted the feature/radio-button-base-implementation branch August 29, 2018 21:06
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants