Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Park UI Roadmap to 1.0 #466

Open
cschroeter opened this issue Nov 5, 2024 · 3 comments
Open

Park UI Roadmap to 1.0 #466

cschroeter opened this issue Nov 5, 2024 · 3 comments
Assignees

Comments

@cschroeter
Copy link
Owner

cschroeter commented Nov 5, 2024

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.

@cschroeter cschroeter self-assigned this Nov 5, 2024
@cschroeter cschroeter pinned this issue Nov 5, 2024
@vitorGabr
Copy link

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

@cschroeter
Copy link
Owner Author

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

@cschroeter cschroeter changed the title Road to 1.0 [Draft] Park UI Roadmap to 1.0 Nov 7, 2024
@kornhama
Copy link

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! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants