Update workflow

[S-unya]

• Update workflow
• Add example Radix component
• Add example bespoke component
• Setup storybooks
• Setup vitest

[olibooty]

... is it just aerated?

[S-unya]

I'm not sure yet... I will work this all out once we decide on the way that we are managing versioning,etc. I'm going to remove all this.

[olibooty]

I'm not sold on the API of this atm if I understand it correctly - I'd need to import three components to have it working correctly. What are the benefits of requiring this over providing more props for text elements etc.
And some other thoughts:

• trigger can just be a string?
• Can dialogTitle type include string and render a default h tag? Though the question would be what's the appropriate h tag? If the wrapper is a section, does it matter? 🤔
• I'd prefer props as foo over dialogFoo - it's already being called as a dialog

[S-unya]

1. The purpose of the multiple elements imports was to give more control over the styling of, e.g. the footer by passing className. Given that I have removed the "trigger" as it wasn't giving that benefit, but I can still see the need for a footer that you can pass a className to.
2. Trigger must be a button, and I have now typed it as such
3. I have allowed the title to be a string now - this is a good suggestion for DX 👍
4. Agreed, done.

[olibooty]

should this be the inverse?

Suggested change

	[styles.visuallyHidden]: dialogTitle.hideTitle === false,
	[styles.visuallyHidden]: dialogTitle.hideTitle,

[S-unya]

👍

[S-unya]

done

[olibooty]

No secondary?!

[S-unya]

There is a default and a primary, tertiary is deliberately skipping a level to indicate it is much less obvious than the other buttons... though it might be better named linkLike... what do you think?

[olibooty]

you could make these a discriminated union of booleans, allowing only one at a time, like this
it's pretty verbose, but makes for a nice api

[S-unya]

That is useful for elsewhere, but you cannot put 2 different versions of this in the variant... so perhaps overkill for this?

[DanCoderDev]

Maybe we could also add styles for <em> and <s> if relevant?

[S-unya]

They will have browser styles, the purpose of this is so that it picks up the correct font.

[DanCoderDev]

From what I could understand, all looked good to me. Just a couple of CSS changes to consider:

• Could add a CSS/SCSS file for backgrounds -> In here, we could set colour contrast functionality (e.g. if background colour is black, the text is white, etc.)
• Could add a CSS/SCSS file for accessibility -> Have a central place for everything accessibility (e.g. could set reduced motion styles, etc.)