fix(admin-ui): various UI fixes

[leopuleo]

Changes

With this PR introduces multiple changes:

• Add xs icon size.
• Fix the form components spacing.
• Fix the form components ghost variant when disabled: true.
• Cast Tooltip to font-weight: normal.
• Improve extendTailwindMerge configs.
• Style and refactor the Tabs component's public props (it now accepts a tags prop with the child tabs definition).
• Fix Avatar component while displaying images.
• Remove unused Chip props.
• Remove Popover portal from Autocomplete components.
• Include Tooltip.Portal; there were instances when the tooltip content became invisible.

How Has This Been Tested?

Manually

[adrians5j]

1. Orange Border Height

I noticed this is 3px in Figma, and in code it's 2px.

But I think you already posted a comment to K about this, right?

2. Not sure if this should be in line.

3. Active States

Should we discuss these with K maybe?

4. Tabs Moving?

Isn't it weird how the right tab is moving by 1px as the left one is switching between active/inactive?

movingpx.mov

[adrians5j]

Note

At this point, this is just a discussion.

BTW what do you think about the following API here?

<Tabs>
    <Tabs.Tab id="account" title="Account" icon={<Tabs.Tab.Icon icon={...} label={...}/>}>Account content</Tabs.Tab>
    <Tabs.Tab id="password" title="Password">Password content</Tabs.Tab>
</Tabs>

Some notes...

1. The current Tabs component uses tabs prop and has no children being used. Since both of these are just regular props, and both can be affected via a decorator, maybe might as well use children here? It'll also be a bit more in the spirit of React.
2. In this example, I'm using Tabs.Tab instead of POJO. Note that both Tabs and Tabs.Tab can also be made as decoratable, giving users full control.
3. Using Tabs.Tab.Icon not only allows the user to specify the icon, but also other props. Like in this example, a label for the icon, if needed. This is how I also did it with Dialog and it's icon prop. You pass Dialog.Icon element to it.
4. BTW I used id instead of value. value sounds a bit weird to me... but hey, if it's how it works in the React/components world, I guess we leave it as is.

The only potentially tricky thing I can see here is the fact that the title needs to be extracted from the child components, by the Tabs parent component, in order to construct triggers. I can see where doing this already, but I can also see it's easier to do this when you have tabs POJO prop, and not these child components (although I believe it's still possible to read props from these child components, I think I did it in the past).

[leopuleo]

All the styling issues highlighted above have been solved or discussed with K.

tabs prop

I've changed from POJO to the Tabs.Tab component. We need some little magic under the hood to extract all the valuable props for the underlying Trigger and Content components. The exact mechanism is used today.

This component is a good candidate for improvements via FTA; I noted it in the GH project.

Regarding the tabs vs children props: let's revisit them together with the other components.

tab icon

Currently, the icon prop receives any ReactElement, aka any SVG. We use the Icon component inside the Trigger where we pass the SVG received as a prop with fixed size, color and label.

I would keep it like this: I don't want to repeat all these fixed props while using this component around the admin.

id vs value prop

I chose to use value instead of id because this is what Radix UI uses, together with onValueChance callback. Also, the id prop is used internally by Radix UI to couple the content and the trigger.