Add recipe variants to return value of `createRuntimeFn`

[Mokshit06]

This PR adds the keys of variants passed to createRuntimeFn as a property on its return value. This allows for runtime reflection of variants that are available, which is useful in a few cases, like deciding which props should be passed to the runtimeFn and which to passed to the component

[changeset-bot[bot]]

⚠️ No Changeset found

Latest commit: b557b5becc6c5e2edfb60595c2c4757de1dac8c8

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[mattcompiles]

@Mokshit06 Could you provide some code examples of where you think this would be helpful?

[Mokshit06]

@mattcompiles I was working on a css-in-ts library which provides a styled api wrapper over recipes API and allows to declare vanilla-extract styles in same file. In the styled API I would need some way to reliably figure out which props are to be passed through to the underlying component and which are variants, runtime reflection of them would make it easier

[mattcompiles]

@Mokshit06 Sorry, it's still not super clear to me exactly what you're trying to achieve. Also, adding this data to all recipe calls is extra information that 99% of users don't require. Not sure I'm comfortable with adding it without having a clear use-case that's relevant to a fair share of users.

If you're trying to build abstraction on top of recipes then you may be better off forking the code and internalising it into your own solution?

[Mokshit06]

The abstraction already works without needing a fork, the thing that I want to add is:

const styled = (Component, runtimeFn) => {
  return function StyledComponent(props) {
    const [variants, others] = splitProps(props, runtimeFn.variants)

    return <Component class={runtimeFn(variants)} {...others} />
  }
}

const button = recipe({ .. })
const StyledButton = styled("button", button)

here I want to be able to introspect the variants that a function returned by recipe has so that I can split the props accordingly. It is pretty small to add it to the core so I was looking if this could be added to the core without needing a fork of vanilla-extract/recipes

[bjgrosse]

The abstraction already works without needing a fork, the thing that I want to add is:

const styled = (Component, runtimeFn) => {
  return function StyledComponent(props) {
    const [variants, others] = splitProps(props, runtimeFn.variants)

    return <Component class={runtimeFn(variants)} {...others} />
  }
}

const button = recipe({ .. })
const StyledButton = styled("button", button)

here I want to be able to introspect the variants that a function returned by recipe has so that I can split the props accordingly. It is pretty small to add it to the core so I was looking if this could be added to the core without needing a fork of vanilla-extract/recipes

this is exactly my use case as well. Sprinkles nicely includes .properties and it seems like recipes doing the same would be very consistent.

[mszczepanczyk]

I need this too! I was actually about to create a PR but then I saw this one. Funnily I even implemented it exactly the same way byte for byte. @mattcompiles I can finish this PR if @Mokshit06 doesn't want to (make variants a function).

[mattcompiles]

@mszczepanczyk Go for it bud 👍

[mszczepanczyk]

@mattcompiles created a new PR #1044 as I've no right to push to this one

[mattcompiles]

Closed in favour of #1044