separate component library

[samadadi]

Hi. Do you have plan to separate the whole ark package to multiple primitive packages. I like this library but I don't use it just because of this problem. Maybe i am silly person.

[cschroeter]

@samadadi
Ark UI is availabe for React, Solid and Vue.

If you have a proper app setup (Three Shaking) which is commonly supported in all application frameworks (Next.js, Nuxt etc) there is no downside installing the @ark-ui/{react|solid|vue} package.

If you don't have a proper app setup (legacy projects in enterprise companies) you can always fall back to path imports like for example: @ark-ui/react/accordion

Let me know if that answers your question.

[veloware]

@cschroeter I was also curious about this too, I notice Zag exposes the components separately (with the framework adapter separate) which enabled me to install and use only the @zag-js/select component without installing all the components, no tree shaking needed. Is there an architecture limitation that would stop this being achieved in Ark as well?

On tree-shaking, there are times when it's not quite as easy to use it, in the likes of micro-frontends through webpack module federation, the default is that all the modules are brought in at the start and shared due to technically not knowing at runtime which MFE's might be consumed. You can of course stop the modules being shared and front loaded as such where each MFE only pulls in what it needs at runtime, but that has other consequences such as slightly slower loading times of MFEs as the user navigates through your app, (as they are no longer front loaded)

In this kind of scenario, being able to use the likes of @ark-ui/select instead if all of @ark-ui/react would be perfect

[cschroeter]

@veloware

I might be misunderstanding, but could you clarify the difference between @ark-ui/react/select and a dedicated @ark-ui/react-select package?

In Park UI, I'm using path imports like import { Select } from '@ark-ui/react/select'. From my Next.js build output, I can see that only the Select component is added to the bundle when used in isolation.

Happy to hear your thoughts.

[veloware]

@cschroeter is your next build running treekshaking? It's something I'm not overly familiar with, but my limited knowledge tells me that if you install a node module like @ark-ui/react and don't have treekshaking then when your application builds it will include all of @ark-ui/react, even if in the usage of the component you import via @ark-ui/react/select

With treekshaking enabled it would not include any code that's not imported and used ( that's obviously a simplistic explanation )

If the above is true, what I am saying is that unless you are able to run treekshaking, then you have no option but to include all of the Ark package.

But if there is no dependencies across components that would allow components to be exposed individually, like @ark-ui/react-select it would allow those that can't treeshake ( for whatever reason ) to still consume components as and when needed.

This a learning experience for me to be honest, happy to be told I'm wrong :D

It's one of the + points for the likes of shadcn where you can grab whatever code you need for a subset of components.

And I suppose my thinking is, if Zag can do it, is there something to stop Ark, given Ark is just a thin wrapper around Zag for the most park.

Appreciate the feedback, thanks!

[RIP21]

@veloware it was true for commonjs modules. Now as this package is of dual nature and is both ESM and CJS simultaneously AND each of its components sits in a separate file it should be tree-shaken based on imports nicely by Vite, Webpack and other tools given you're using more or less fresh versions (I think one-year-old Rollup, Webpack, Vite, Next.js etc. will handle it just fine).

Note tho, that tree-shaking only works if each component or function of your library code sits in a separate file, if your tool, like let's say, tsup bundles them info one file, tree-shaking stops working even for ESM (at least my last testing proved exactly that).

If you're not sure if the library is properly packaged and tree-shakable you can always experiment with the empty Vite project, build it, and see the output, or setup size-limit tool and test with it instead.