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