Park UI Roadmap to 1.0

[cschroeter]

Park UI Roadmap to 1.0

Park UI is evolving to provide a more intuitive, flexible, and maintainable component system. These updates should make Park UI more adaptable and easier to work with, directly reflecting our user feedback. Here's our path to version 1.0:

Configuration Updates (v0.43)

The configuration system is being streamlined to provide more direct control over theming:

import { defineConfig } from '@pandacss/dev'
import { createPreset } from '@park-ui/panda-preset'
import amber from '@park-ui/panda-preset/colors/amber'
import sand from '@park-ui/panda-preset/colors/sand'

export default defineConfig({
  preflight: true,
  presets: [createPreset({ accentColor: amber, grayColor: sand, radius: 'sm' })],
  include: ['./src/**/*.{js,jsx,ts,tsx,vue}'],
  jsxFramework: 'react', // or solid or vue
  outdir: 'styled-system',
})

Simplifying Color Tokens (v0.43)

- <Box color="accent.default"/>
+ <Box color="colorPalette.default" />

The previous structure for color tokens looked like this:

colorPalette.1  
  └── accent.1  
      └── amber.1  
          ├── amber.light.1  
          └── amber.dark.1  

However, in our recipes and preset, the "accent" portion is unnecessary and can be simplified to:

colorPalette.1  
  └── amber.1  
      ├── amber.light.1  
      └── amber.dark.1  

Recipes

Component recipes will be embedded within the component snippets, making customization and adjustments easier:

import { ark } from '@ark-ui/react/factory'
import { cva } from 'styled-system/css'
import { styled } from 'styled-system/jsx'
import type { ComponentProps } from 'styled-system/types'

const buttonRecipe = cva({
  base: {
    display: 'inline-flex',
  },
  defaultVariants: {
    variant: 'solid',
    size: 'md',
  },
  variants: {
    variant: {
      solid: {},
      subtle: {},
      outline: {},
    },
    size: {
      sm: {},
      md: {},
      lg: {},
    },
  },
})

export type ButtonProps = ComponentProps<typeof Button>
export const Button = styled(ark.button, buttonRecipe)

---

Update Compositions (v0.7)

Compositions will be updated to match the one in Chakra UI. You can learn more about compositions here.

[vitorGabr]

It would be nice to have support for icons within the input in v1

[cschroeter]

@vitorGabr the component api will be more or less the same as chakra - so yes that will be available

[kornhama]

Hi Christian,

I'm currently considering Park UI as a base for a design system of an upcoming project.
Now that there's talk about 1.0, here are a few of my insights after using it for a few months.

I'm not entirely convinced of the concept of Park UI being a snippet-only library, and I've seen this mirrored in discussions with others.
In most cases, snippets only increase maintenance overhead (e.g. linting rules, code style and merge reviews).
I'd prefer to have something like a "@park-ui/components" package, that exports the uncustomized components, as most of the time I'm quite happy with the default components with some adjusted styling.
Ideally, if I'd need to make adjustments for a component, I could still keep using the @park-ui/cli to download that specific component.

The same goes for adjusting the styling of a component.
Most of the time, I only want to override certain aspects of the default styling, which is the main reason I'm considering Park UI in the first place.
I'd be using Ark directly otherwise.
Therefore I'd prefer to keep using config recipes instead of atomic recipes, which would probably result in a merge conflict whenever the upstream component changes (if I read this roadmap correctly).

This would allow me to just update the upstream @park-ui/components without adapting anything else on my end unless there are breaking changes.

Obviously, the way forward remains your decision.

I want to thank you for your work on Park UI and Ark UI.
Keep up the great work! :)

[Mottoweb]

Using park ui in a project that is about to go to production with real users, wanted to thank for your great work!

Regarding recipes, i've been using park ui this way for quite some time now (manually adding cva instead of config recipes for every component), and honestly found it to be the only way for extensibility and maintainability, so +1 for that.

As for the color tokens, is there a way to maintain old ones with the new ones? Because i've been using cva's i have to manually update every component cva to match new tokens, but i still want to be able to selectively update some components to new tokens, could you advise on that please?

[FranciscoKloganB]

@kornhama Wouldn't that project be better off using Chakra UI? Most pre-styled component libraries support configurations and overrides either via CSS selectors or JavaScript configuration objects. At least the one I use (Nuxt UI) does.

The way I see it, I might be missing something of course, is that you should pick recipes/components once and own them as your own code going forward, without needing to constantly sync. Although I understand that eventually, you must "synch" with Park-UI releases if you want to keep dependencies up to date. 😬

[kornhama]

@FranciscoKloganB

The ability to override styles for Ark UI remains available using Park UI.
You can even layer cva over a pre-styled Park UI component.
The choice between Chakra and Park UI is currently mostly about the CSS runtime, as they seem to converge in API design.
For some perspective: I'm looking at Park UI as a base for a component library that is going to be reused in multiple projects, as opposed to an in-tree customization for a single project.
I'm also considering CSS bundle size differences between cva and config recipes, although I haven't fully evaluated them.
Also: even if you have prepackaged components, no one is stopping you from copying the source of the component in cases where you really need that last bit of customizability.
As I mentioned before, if I wasn't happy with the Park UI baseline, I'd be using Ark UI directly.

I used to program in C and C++ where vendoring source code was (and still is) a common practice.
And you could be doing that with pretty much every JavaScript library out there as well (as it used to be done in the jQuery days).
I know that the snippet trend saw a recent surge in popularity in frontend development starting with shadcn.
I guess everything old is new again.
This obviously works and gives you a lot of flexibility.
But it certainly comes with increased maintenance efforts (e.g. see the previous comment about the color token changes).

I've come to realize that very often you will have to synchronize with upstream changes eventually and have come to prefer using a package manager over effectively maintaining a fork.
Actually, if you want to own the components and need full customizability, forking the full Park UI repository remains a possibility.
And once things have settled a little that approach might not even require a lot more maintenance over maintaining separate downloaded components (especially from the component library perspective).

Just my own opinion, others might have different preferences.