> For the complete documentation index, see [llms.txt](https://docs.theopenpresenter.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.theopenpresenter.com/development/ui-component.md). # UI Component Our UI stack of choice is [TailwindCSS](https://tailwindcss.com/) + [`shadcn`](https://ui.shadcn.com/) ([radix-ui](https://www.radix-ui.com/)). Our UI component lives in **packages/ui**. And while we use a lot of components from shadcn, it acts mainly as a base for us to work from. #### CSS usage As much as possible, we should put our styles in a **.css** file. While tailwind allows for the style to be defined inline, we prefer this to be kept to a minimum. The main benefit of tailwind we are utilizing is the design system and its syntactic sugars. In general, we use the following convention for the css class name: `[repo-name]--[component-name]-[component-part]__[extra-info]` For example: ``` ui--alert-heading__warning ui--alert-title pl-lyrics--mobile-preview-pane__open ``` > **pl** stands for plugin ### Micro-frontends and Tailwind Tailwind doesn't work the greatest with micro-frontends. See for more info. In our app, we have several separation between components that leads to this issue. Eg: In remote, we have the container app, UI library, and also each plugin. So we need to somehow avoid the styles from clashing. #### Solution **UI Library -** On our UI library, the class names are mangled on build using [tailwindcss-mangle](https://github.com/sonofmagic/tailwindcss-mangle). This prevents the clashing with any other components **Remote Container App -** As much as possible, all styles on the container apps should use custom css class names as recommended above **Plugin -** Since the other components tries their best to avoid using the default tailwind class names, each plugin should be able to use default tailwind class names. However, we still recommend using custom ones like above, or a prefix