Inconsistent API for children JSX

[vezaynk]

There are some components such as Tabs, and Flashbars which prefer expose a configuration-based API where JSX is supplied as part of a configuration object, whereas others prefer to pass it as children.

Here is an example of what I mean:

The way it is right now seems to be:

• inconsistent with other components
• smells like an anti-pattern (the children prop/slot is there for a reason)
• limits functionality (hooks cannot be used in this way)

---

Sidenote (I could break this out into a separate discussion, if need be): the flashbar API is odd in general. It accepts an array of items instead of implementing via a JSX-based API (compound components). Something like this:

<FlashbarStack>
  <Flashbar ... />
  <Flashbar ... />
  <Flashbar ... />
  <Flashbar ... />
</FlashbarStack>

[just-boris]

Hello!

The API you are proposing would not allow to implement our recent addition, stackItems property. For all list-type of components (breadcrumb group, cards, flashbar, tabs, table) we consistently expect content as an array of items and it worked well for years.

In places where we do not have an opinion about items order (container, expandable section and derivatives), we expose children prop, but these situations are rather uncommon.

Do you have any supportive examples on why we should consider changes in our approach?

[vezaynk]

stackItems could've been implemented with something like this, and then each Flashbar could've been defined via JSX:

<FlashbarStack>
  <Flashbar ... />
  <Flashbar ... />
  <Flashbar ... />
  <Flashbar ... />
</FlashbarStack>

using Compound Components.

Doing it without JSX doesn't feel React-y, but more concretely it:

1. Limits the use of hooks inside of content since it expects a JSX block and not a component. edit: this is incorrect, nvm.
2. Performs unnecessary renders due to the configuration object identity changing on every render (Unless if the consumer wraps it in a useMemo). This is why flat prop structures are preferred (i.e. <Component a={...} b={...}/> is preferred over <Component values={{ a: ..., b: ... }} /> ).

There is prior art supporting my POV throughout most major UI libraries such as MUI which uses avoids configuration object props and uses children where possible.

I could come up with more points, but these two are the ones that come to mind right now.

I don't see any use-case which is broken by the current API that cannot be worked around, but it could be improved.

[just-boris]

Thanks for the feedback we may consider this input if we build a new major version, but our current version 3.0 will have to stick to an already established convention

---

For the internal team reference, there is also AWSUI-9532