Adjustment on UI Framework Usage

[preschian]

Hi team, in retrospect, IMO we need to improve our implementation of our NeoComponent. Let me explain why I don't like this approach.

The Problem

Currently, this is how we extend the component.

app -> kodadot/brick -> forked/extend version of oruga

We face some obstacles since Oruga is moving away from Options API to Composition API. Extending Composition API is not quite straightforward anymore. We need to adjust/hack some stuff. Additionally, extends is not recommended for Composition API. Based on this, we are currently stuck with older versions of Oruga and Sass.

Solution

Instead of using a forked/extended version, just use it directly.

app -> ui-framework (oruga or @nuxt/ui)

The question is, do we want to go with Oruga or @nuxt/ui? @kodadot/internal-dev

Personally, I prefer NuxtUI. Community support is bigger and can help us address icon-pack issues. Related:

• Integrate Iconify icons pack #10622
• We faced FontAwesome downtime twice: Replace icons set with branded business outlined icons #796 (comment)

Built-in modules from NuxtUI: https://ui.nuxt.com/getting-started/installation#modules

Initial setup for NuxtUI: #11229

Action Items

Whether we go with Oruga or NuxtUI, we need to migrate our NeoComponent. Once done, we can move on to other major CSS tasks.

Related issues:

• new Oruga 0.8.0 - breaks build #8479
• How to extend Composition API components #9195
• Should we use oruga for any UI component? #8504

Styling/CSS issues:

• CSS Refactoring step 1 #8071
• Bulma conflicting with Tailwind classes  #9973
• refactor: container size to tailwind #9245
• remove bulma css #9013
• A mess of styles #8066

---

lmk what you guys think

[vikiival]

Hey @preschian,
I am not against the idea but:

1. Isn't it easier to rewrite NeoComponents with NuxtUI? aka replace Oruga
2. How much time would take it?
3. Is it possible to automate this task with some AI agent?
4. What would break?

Moreover, Koda has 57401 Lines of Vue code, wouldn't be more optimal to optimize/remove the dead code so we know better what we really need to rewrite?

[preschian]

Hi Vik, thanks for the response.

1. It doesn't quite solve the main problem. NuxtUI also uses Composition API (I think currently most Vue apps use Composition API instead of Options API). Plus, we would only be adding an additional unneeded layer to the components.

2. It takes time, similar to this issue. Plus, it depends on compatibility between NuxtUI/Oruga newer versions with our current styles. Unless we're still happy with the older version of Oruga. Or maybe someone has a better idea for it?

3. Would be happy if we could address that with AI.

4. We only need to rewrite libs/ui/* components and do it one by one like the task mentioned in point 2. So the possible breakage would occur when we're migrating that specific component. For example, if we rewrite NeoAutocomplete component, the possible breakage would only be on that component. Most of the components would still remain using the old version.

[vikiival]

cc @kodadot/internal-dev

[roiLeo]

It might be wiser to use nuxt UI v3 (w/ Tailwind v4), as migration from v2 can cause headaches.

[preschian]

This is a nice addition

For Tailwind, there are probably not many breaking changes. However, for the components, it seems more complex since there are changes in some APIs/props usage

Previously, I mentioned migrating NeoComponent first and then handling the CSS stuff. But with this addition, let's start with some CSS work first while waiting for NuxtUI v3

[preschian]

NuxtUI v3 released: https://nuxt.com/blog/nuxt-ui-v3

wow, it's quite earlier than I expected

[roiLeo]

@roiLeo have you tried to customize nuxt-ui components? Asking in case we would like to use it in koda

It's easy to customise nuxt-ui components in the app.config.ts file. What's more, you can always extend the components to suit your needs. I advise you to start directly from v3, which will save you the trouble of migrating from v2 to v3.

[preschian]

Hmm team, yesterday the whole day I tried to add the framework. Unfortunately, since @nuxt/ui is tightly coupled with Tailwind v4, we're facing some major breaking changes from Tailwind v4:

1. Tailwind Not Compatible with SCSS

   • From the Tailwind v4 docs: "Tailwind CSS v4.0 is a full-featured CSS build tool designed for a specific workflow, and is not designed to be used with CSS preprocessors like Sass, Less, or Stylus."
   • Reference: Tailwind Compatibility Docs
   • We still need SCSS at the moment because Oruga/Brick components require it. (unless we migrate it first to using vanilla css, idk how much the effor, not recommended I guess)

2. Explicit @apply Usage Requirements

   • Now, if we want to use @apply in our components, we need to add @reference at the top. This means adding it to each of our Vue components
   • Another problem: I don't know how to use @reference in SCSS files (related to point 1 above)
   • Reference: Tailwind Upgrade Guide

Does anyone have other ideas about this?

I will try to find alternative approaches today

[roiLeo]

Have you tried to use Nuxt layers capabilities? Maybe migration can be gradual if we process like we've done it with histoire, replace each components with NuxtUI equivalent.

[preschian]

Have you tried to use Nuxt layers capabilities? Maybe migration can be gradual if we process like we've done it with histoire, replace each components with NuxtUI equivalent.

Not checked yet, but using Nuxt Layers also comes to mind.

Besides that, here's another approach: Let's bundle our Oruga components so we can separate between Tailwind v3 (for Oruga/Brick) and progress to Tailwind v4 on the app.

Needed Changes Before Upgrade to v4:

1. Since Tailwind v4 doesn't work with SCSS, we need to convert @apply ... to vanilla CSS rules.
   Example: _carousel-arrows.scss#L7
2. Add @reference ... in Vue components that use @apply ... and remove lang="scss" attribute
3. If the Vue component imports styles from SCSS files, keep using SCSS and convert @apply ... to vanilla CSS.
   Example: ImageSlider.vue#L109-L111

Steps of Action:

1. Convert @apply ... to CSS rules
2. Add @reference ... or convert to CSS rules on Vue components
3. Bundle Oruga/Brick components
4. Upgrade to Tailwind v4 (in this step, make sure the styles are not broken)
5. Install @nuxt/ui@v3
6. Gradually migrate the components

this approach seems feasible, any concern maybe?

[preschian]

Hi team, upgrading Tailwind CSS to v4 is almost done: PR #11513

Currently, I'm still checking some minor details, but overall the styles look fine. Some caveats:

• Bundle size will probably be bigger because we load Tailwind CSS v3 on Brick and v4 on our app. We're stuck on v3 on Brick because Tailwind CSS v4 doesn't support SCSS at the moment
• All Tailwind CSS utilities are using important: true, in the config (tailwind.config.ts) because without it, some utilities get overridden from Bulma (such as minireset.css)