[added] RadioButton and RadioGroup

[aabenoja]

Part of #342.

The RadioGroup might also resolve #365 by keeping track of the selected item.

[aabenoja]

This also might against the wrong branch...

[jquense]

the label should probably also add htmlFor if there is an id prop, for better accessibility. We might also want to add id as a requiredForA11y prop to encourage good behavior. I wouldn't assume the prop is there tho to avoid breaking compatibility

[aabenoja]

Good point! I initially didn't implement it since the wrapping automatically associated the radio button with the label and gave me the green light through the WAVE tool. Having the id would certainly be a good enhancement, though I don't think I'll be making it a required prop.

[aabenoja]

@jquense Got the htmlFor in. Anything else we want to add to this? Any additional functionality we want to add to either the RadioButton or RadioGroup?

[aabenoja]

Before we pull this in, how do we want to go about handling a default value?

[joemcbride]

The pattern I've seen is to provide an initialValue property.

[joemcbride]

As described here as the initialCount.

[jquense]

I think the case of controlled/uncontrolled inputs defaultValue is more idiomatic and mirrors the basic form inputs as well as other rb components which have a similar pattern.

[joemcbride]

👍 defaultValue works and I think it is good to keep consistency in that regard.

[aabenoja]

👍

[AlexKVal]

id and label vars from 26 line

const {id, label} = this.props;

are not used anywhere else
why don't just ?

<label className={classNames(classes)} htmlFor={this.props.id}>
  {input}
  {this.props.label}

[aabenoja]

It looks cleaner to me this way, and babel will transform it to this.props.id anyway.

[AlexKVal]

Thank you for the clarification 🍒
no problem at all with it. it is just a matter of personal taste 😉

[AlexKVal]

Boolean props empty default values look odd.

Because of the code:

return legend ?
  <legend className={classNames(classes)}>{legend}</legend> :
  null;

'radio': !this.props.inline

their "default" undefined value actually interprets as false.

I propose either to explicitly add them to RadioGroup.defaultProps = {}
(alas there is no smth like @default for documentation generation)
What do you think ?

[jquense]

I think having empty bool values is fine for now. It might be better to just solve this in the prop documentation code with like a @default or something. That or just default bool props to false. In either case I wouldn't hold up this PR for it.

@aabenoja One thing I might do tho is name the noop function used as the default so it looks clearer in the docs.

let noop = ()=>{}

defaultProps = {
  onChange: noop
}

up to you

[aabenoja]

@AlexKVal I don't see anything necessarily wrong with undefined being interpreted as false, which is something I expect in javascript anyway. It feels pretty asinine to do this for every single boolean, especially when the effect is purely cosmetic.

@jquense I agree, that's something we could do during prop documentation generation. I could sneak that in with this PR. As for the noop that is also a good idea.

[AlexKVal]

Agree.
Maybe it would be best to let the docs generator to automatically fill default value for booleans if no other default value is provided.

[taion]

A potential problem with filling in a default of e.g. false is that code could potentially do something different for a null-y value than for a false-y one. I think it'd be stupid and broken to do that, but eh. Or I could be wrong - maybe better to require explicit defaults for boolean fields?

[taion]

@aabenoja Did you get a chance to look at @jquense's last two comments?

[aabenoja]

@taion I've been swamped for a while and haven't been able to set aside the time, unfortunately.

[taion]

No worries - going to push this down one more milestone then. Probably better all-around since we have quite a few things for v0.25 already.

[taion]

Is this essentially good to go now, except for

this also needs to wrap the RadioButton in a FormGroup to be consistent with the old behavior

?

[AlexKVal]

It seems we should decide the way to go: #962 (comment)

jquense: this also needs to wrap the RadioButton in a FormGroup to be consistent with the old behavior

aabenoja : That my be so, but using FormGroup on RadioButton is causing all sorts of headache, mainly with inline styles.

Wrap it or no ?

[aabenoja]

Sorry, I've been swamped with other things on my end. In all honestly, using FormGroup around individual RadioButtons doesn't make a lot of sense to me.

[aabenoja]

Not the button I wanted to hit >.>

[vsembobra]

i think return {} shoud be better

[vsembobra]

({message: undefined}).message=== ({}).message returns true

[bbenezech]

I need this. I can spend some time on it to get the PR moving.
Can someone sum up the blockers?

poke @jquense @aabenoja

[taion]

@bbenezech At this point, our plan is to revise the <Input> API entirely; we want to drop just about everything on that component except for label, and expose user-composable form groups for everything more customized.

[bbenezech]

@taion I see. Sounds a bit though for a first commit :/
Good luck and keep up the great work, I appreciate it.

[taion]

Closing this for now – will incorporate this into the form/input rewrite.

[laughnan]

@taion i see that this has been closed but so is #342. i don't see RadioGroup as being implemented. did something come to fruition from this?

[taion]

We're just not going to do it for now – if you want something like a radio group, consider a higher-level abstraction like React Formal. For now, we don't see much value in going beyond matching the TWBS API in a thin way here.

[martinjuhasz]

For now, we don't see much value in going beyond matching the TWBS API in a thin way here.

Since there is no way to add some radio buttons that toggle a single value and then read the corresponding value with uncontrolled props ( without relying on state) i think there is value in here.
Esprecially on simple forms when there is no state binding needed but you want to toggle a value using multiple radios.