Bandwidth
Field.Group causes rerender when number of Fields changes
<FieldRow> is rendered inside of <Field.Group> for each row that ends up being created (based on the columns of the children). <FieldRow> is keyed by index, so if a new row gets added, it can cause many extra rerenders and lifecycle changes that are unnecessary. It can also lead to strange bugs.
One fix for this could be to remove the <FieldRow> element if possible, and instead do layouting directly on children. Another option could be to separate out the masonry-style layout that fields provides from the label/helptext concept of a field. Primarily, exploration should be done into other options to handle field. See #223 and #188 for other issues to our current Field implementation.
The way Fields lays out children is pretty dependent on whether those children have labels / helptext, which complicates things.
Basically, Fields has to coordinate its layout to vertically align adjacent Field items depending on their internal elements. If both Field items don't have Label, for instance, then they align vertically to the top of their content. But if one of them has a Label and the other doesn't, the one without a label should maintain the empty space where the label should be to align with it sibling.
That's the main problem Fields was designed to solve, so we want to keep that behavior consistent.
I did have success with using CSS Grid to lay out Field items directly without the need for Row elements. The only drawback was that Fields behavior changed to include a bottom margin which couldn't be easily removed. However, I think that bottom margin was actually a good feature, since a block of Fields should indeed be visually separated from any content below it.
PR was here: https://github.com/Bandwidth/shared-components/pull/137
It was merged then reverted. Might be worth revisiting.
It's also complicated because Fields does that layout when it renders based on its exact children, so it doesn't map well to a consumer/provider pattern as implemented currently.
I would be happier with a top margin utilizing the + selector over a bottom margin