docs(components/toggle-control): clarify that onChange is not required

[dsifford]

Description

Per discussion in Slack with @gziolo, this adjustment to the docs reflects the fact that onChange is not required if the user intends the component to be an "uncontrolled" component.

Let me know if you have any further questions/comments.

How has this been tested?

N/A

Screenshots

N/A

Types of changes

Docs

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[Soean]

TextControl, SelectControl, RangeControl, etc. require onChange. If we change it in one component, we should adjust it for all.

[dsifford]

@Soean I'm cool with keeping required, but if that's the case, then we should probably remove the conditional here...

gutenberg/packages/components/src/toggle-control/index.js

Lines 26 to 30 in 0563331

	onChange( event ) {
	if ( this.props.onChange ) {
	this.props.onChange( event.target.checked );
	}
	}

Because if it is indeed required, the code should throw an error if it's not provided.

[jorgefilipecosta]

This one is complex, the best approach would be to change to required and be consistent with other components, but the fact is that it is not required now and requiring it is a breaking change, we may make some plugin crash, but these plugins did not follow the docs which referred the prop was required. I'm not sure what's the best path here, I guess we will need to break consistency in order to not break back compatibility. Any on this @youknowriad?

[youknowriad]

Another option would be to make all it not required in all the other components to keep consistency but Tbh I don't think we had the intention to support "uncontrolled" components. I don't think anyone would be using uncontrolled component here.

[aduth]

If it's documented as being required, I don't think it needs to be considered as a breaking change to remove the condition which guards against its falsiness.

[jorgefilipecosta]

If it's documented as being required, I don't think it needs to be considered as a breaking change to remove the condition which guards against its falsiness.

Hi @aduth, just to confirm you would like to keep the onChange as required and you think we should remove the condition that guards against an undefined value?
cc: @jorgefilipecosta to keep track of the updates.

[aduth]

If it's documented as being required, I don't think it needs to be considered as a breaking change to remove the condition which guards against its falsiness.

Hi @aduth, just to confirm you would like to keep the onChange as required and you think we should remove the condition that guards against an undefined value?

Yes, this is what I mean.

[gziolo]

Based on the discussion it’s fine to merge