feat(v5): Drop bsPrefix from FormGroup

[kyletsang]

https://v5.getbootstrap.com/docs/5.0/migration/#forms

Dropped .form-group for margin utilities (we’ve replaced our docs examples with .mb-3).

Changes:

• Removed bsPrefix from FormGroup as the class is no longer supported.
• Updated all examples with mb-3 to handle spacing

[bpas247]

Guess this gives us a good excuse to revive the Layout component idea 😉 Would be fantastic if we could get this implemented for V5

[taion]

wait, hold on – isn't this still useful for DRYing specifying ID between control and label?

[kyletsang]

wait, hold on – isn't this still useful for DRYing specifying ID between control and label?

Could users use the FormContext directly? This FormGroup doesn't do much otherwise.

ie

<FormContext.Provider value={myContext}>
  <Form.Label />
  <Form.Control />
</FormContext.Provider>

[taion]

Probably want to wrap it up a bit better so it just takes the controlId maybe? cc @jquense thoughts?

[bpas247]

Could users use the FormContext directly? This FormGroup doesn't do much otherwise.

But then almost all of our end-users are just going to implement this themselves, so they'd just end up making their own FormGroup components anyways.

If we feel strongly about dropping this component then we should at least add a "recipes" section in our docs so that end-users will know exactly how they should be making that component.

[kyletsang]

Yeah that's true - It's nice to have something that works out of the box. Could we keep this component and remove the bsPrefix? What's the stance on "non-official" components?

[taion]

I think it's a judgment call? This seems in the same category as something like <OverlayTrigger> which is nice/possible given React, but would not be otherwise.

[kyletsang]

Ah ok. In that case, I would vote for just removing bsPrefix if that's fine by everybody.

[taion]

sgtm

[kyletsang]

Thanks for the feedback @taion and @bpas247. Updated PR with changes.

[taion]

well, in that case i think we'd want to look at generic "layout class" support. idk

[bpas247]

well, in that case i think we'd want to look at generic "layout class" support. idk

yep, having a Layout component would be great since we could handle three major use cases:

• provide a generic React component that our end users can directly use (instead of just using host elements)
• unify our as prop APIs everywhere - since any component that uses the as prop can just use the Layout component internally and have that handle the functionality for that
• improve the TypeScript DX for our end-users that want to utilize any Bootstrap utility classes

Not to mention, this generic layout component API is not anything new in the component library scene (e.g. the Box component from MUI and the Box component from Chakra-UI), so end-users who are switching from other component libraries to ours will already be familiar in some form to the idea behind it.

[kyletsang]

I'll merge this now.

I created a TODO note to revisit the margins after the Layout component has been added:
https://github.com/react-bootstrap/react-bootstrap/projects/2#card-43153543