🌮 vue-styled-components tag prop use case

I'm currently working on building a Vue UI components library called Kiwi based on vue-styled-components. Even though I've not been developing for a very long time, I'm still very open to learning. So please feel free to helping me improve my understading of Styled Components.

📦 Types of components

In the Kiwi component library that I am working on, I planned to create my components under two main categories. I have Abstract and Composed components. The Composed components are to be composed from the abstract components. An example of an abstract component would be the <Box>, <PseudoBox> components. These in the real world can represent the <div>, <header>, <section>, <nav>, <button> etc. elements.

An example of composed components would include my library's Button and Modal components, for example. The idea is to compose these components from the abstract components. This would make it easier to create these library components from a base reusable component and still allow for flexibility for a user. If a user would like to create a make the Button element render an anchor tag they could just adjust the tag prop on the <Button tag="TAG" /> node in the template.

With this kind of composability in mind, the first two components I made were the Box and PseudoBox components. These two components were to serve the as the building blocks for all other components.

The Box component is to be the wrapper for all possible style props and render a <div> element by default. The PseudoBox is to be a wrapper for all the pseudo style props. This includes &:hover, &:focus, &:before, etc. states. PseudoBox renders the Box at definition.

Below is an example of my use case:

Box.js

import system from '@styled-system'
import baseProps from '@/lib/utils/'

/**
 * Define the Box component. Render 'div' by default.
 * */
const Box = styled('div', {
  ...baseProps
})`
  ${props => {
    const sanitizedProps = cleanProps(props)
    return system(sanitizedProps)
  }}
`
export default Box

PseudoBox.js

import css from '@styled-system/css'
import { Box } from '../../lib/core/'
import { pseudoProps } from '../../lib/config/props'
import { parsePseudoStyles } from './utils'

/**
 * Define PseudoBox component to provide pseudo styles for 
 * `_focus`, `_hover`, `_active`, etc. and `aria-*` attributes.
 * Renders the Box component.
 */
const PseudoBox = styled(Box, {
  ...pseudoProps
})`
  ${(props) => {
    const styles = parsePseudoStyles(props)
    return css(styles)
  }}
`
export default PseudoBox

This allows me to do bind pseudo state styles as props while maintaining the base props inherited from the Box component.

📚 The challenge with withComponent API?

Components created using the withComponent API presently do not inherit props from the "grandparent" styled component. i.e. If the parent component(PseudoBox) is composed from another styled component(PseudoBox), the resulting component(Button) will not inherit style props from the grandparent component(Box).

// Create Box and bind style props
const Box = styled('div' ...props)

// Create PseudoBox from Box and bind pseudo style props
const PseudoBox = styled(Box, ...props)

// In this case, `Button` will only "inherit" style props defined on the `PseudoBox` component but not those style props that `PseudoBox` inherits from `Box`.
const Button = PseudoBox.withComponent('button')

💐 Why tag="TAGNAME" prop is useful.

This would allow me to extend the styles of the declared component internally all while setting the tag type. This will allow for better composability for higher level components like buttons, menus, etc.

This would allow me to make use of the PseudoBox component when creating a new Button component that extends the props of PseudoBox.

<template>
  <PseudoBox
    tag="button"
    role="button"
    bg="blue.400"
    :_focus="{
      bg: 'blue.500',
      border: '2px'
    }"
    :disabled="isDisabled"
    :aria-disabled="isDisabled"
  >
    Button Text
  </PseudoBox>
</template>

For UserLand

The tag attribute below allows the userland devs to modify the tag while inheriting it's props from the PseudoBox and Box components. I would love for myself to be able to manipulate the tag attribute to a desired element to customize the Box and PseudoBox for my desired need. E.g. Render a Box as a header or main which are more accessible without having to modify the script as shown below.

<template>
  <Box
    tag="header"
    bg="gray.100"
    px="8"
    py="6"
    font-family="heading"
    d="flex"
  >
    <Box>
      <Text
        tag="h1"
        color="primary"
      >
        My awesome site heading
      </Text>
    <Box>
    <Text
      tag="h2"
      font-weight="thin"
      color="secondary"
    >
      My site's description
    <Text>
  </Box>
</template>

🥜 In a nut shell

Box | default <div>

• PseudoBox | "Inherits" props from Box
  • This PseudoBox component can be rendered with a different element via a tag attribute.

Example
https://codesandbox.io/s/vue-template-kh32i

Describe the bug
NumberInput field shows NaN and loses functionality when the min/max value limit is exceeded.

To Reproduce
Steps to reproduce the behavior:

1. Go to https://vue.chakra-ui.com/numberinput
2. Focus on input with min/max value
3. Press 0, so that value is 150
4. See NaN
5. Enter 15 again
6. Try to press up or down - doesn't work anymore

Expected behavior
Not sure tbh. I'd probably expect the value to stay at 15.

Desktop (please complete the following information):

• OS: Windows 10
• Browser Firefox
• Version 76.0

Describe the bug
On triggering onClose for a hovering Modal triggered from a Drawer component, the Drawer component closes too.

To Reproduce
Steps to reproduce the behavior:

1. Add Drawer component
2. Add a button with Modal trigger to Drawer component
3. Open Drawer component and click button to open the Modal
4. Close the Modal and Drawer component also closes

Expected behavior
Only the Modal should close and the Drawer should remain open.

Desktop (please complete the following information):

• OS: Mac OS X
• Browser : Brave Browser
• Version : 1.13.113

Thanks!

Is your feature request related to a problem? Please describe.
If this is something seen as useful to the userland, I'd like to possibly look into applying readable classnames for @chakra-ui/vue components in the future. This could be an opt-in feature.

Currently, chakra-ui/vue components output CSS classnames for each component as such:

/* Some weird non-descriptive class name */
.css-sdfkj9 { /* ... */ }

Possible solution could output:

/* Append component name to className by default*/
.css-sdfkj9-CButton { /* ... */ }

Custom values
If user passes in some kind of css label prop:

<c-button chakra-label="Signup">Signup button</c-button>

Output could be:

/* Append component name to className by default*/
.css-sdfkj9-Signup { /* ... */ }

This however is non-critical for now. But I'm happy to get ideas about this and hear what users think.

Is your feature request related to a problem? Please describe.
Chakra UI Vue provides some icons out of the box. These are normally referred to as internal icons.

At the beginning of this project, some internal icons were named with _ICON_NAME in a way that they would not provide naming conflicts with icons provided by external libraries e.g. FontAwesome.

The problem with this is that in case the user imports an icon that already exists inside Chakra UI it then means that the user prefers the external icon over the internal ones. The advantage of this is the naming convention of icons is simpler and the final icons object will be smaller.

Describe the solution you'd like
The natural thing to do would to overwrite the internal icons with the external ones when registering the Chakra plugin.

Doing this will mean that all other components that consume the icons internal icons should be renamed to the same convention as the external ones.

Additional context
Rename all icons in the packages/chakra-ui-core/lib/internal-icons.js from _icon-name to just icon-name. And in the Chakra/index.js file, the icons provided by the plugin should be registered after the internal icons in the $chakraIcons object.

This will automatically overwrite those icons internal icons with those from font awesome if there is a naming conflict.

Describe the bug
Currently the Menu component doesn't have a Props API table. This should be there. (https://vue.chakra-ui.com/menu)

Also the Menu docs page SEO component has the wrong values. This can be fixed at the top of the file.

Expected behavior

• Include all menu props in menu.mdx page
• Fix menu docs SEO component prop values

Is your feature request related to a problem? Please describe.
In conformance to the Vue style guide for components, component names/tags should always be Multi-Word. This helps prevent name clashing with HTML elements since Vue uses templates very similar to HTML elements.

Component names should always be multi-word, except for root App components, and built-in components provided by Vue, such as or
~ Vue style guide

Describe the solution you'd like
This involves prefixing all components with the c- or C
e.g.
Accordion -> CAccordion or c-accordion
Button -> CButton or c-button

1. The CBadge component doesn't forward props passed from consumer that the component internally doesn't define.
   

2. The border property on the outline variant style is not applied. Need to check badgeStyles utility
   

当前状态
当前的Chakra UI文档仅以英语发布。

拟议的解决方案
为了使Chakra UI对**的开发社区可访问，最好将文档翻译成中文。
如果您使用@chakra-ui/vue，愿意为我们的文档翻译成中文提供帮助，我们将很高兴与您合作！

在此问题评论与我联系，或在这里加入我们的discord：

https://discord.gg/baVQcCC

Is your feature request related to a problem? Please describe.
The case for these pages is to explain the case or Chakra UI Vue and why it was created.

Describe the solution you'd like
A list pages to address the following:

• Why Chakra UI
• Accessibility (Why?)
• Constraint based design (Why?)
• Style props (The underlying technologies)
  • Convenient styling API
  • Allow easy composability with JS
• Document Theme page
• Add contributors
  cc: @DominusKelvin

Is your feature request related to a problem? Please describe.
The CMenu component currently accepts the onOpen and onClose function props.

However this goes against Vue's natural intuition and canbe better handled by emitting the @close and @open events to the parent context.

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered

• Change onClose prop to $emit('close')
• Change onOpen prop to $emit('open')
• Implement v-model for MenuGroup items.
• Implement v-model for MenuList items with only MenuItems children
  to it's rendering performance have to be made in the CPopover component

@all-contributors please add @codebender828 for code

Conrtibutions update

Is your feature request related to a problem? Please describe.
The number input doesn't have a 2 way binding implmentation.

Describe the solution you'd like
Implement v-model on CNumberInput

Is your feature request related to a problem? Please describe.
No tests currently written for components

Describe the solution you'd like
Write tests in jest :)

This current codebase is setup to work with Jest and @vue/test-utils out of the box.

Description

At https://chakra-ui-vue.netlify.com some of the components are throwing errors on render or not working as expected. See list of screenshots for description

Screenshots of broken components

Impaired functionality

Slider not reacting to drag

Progress component not showing anything

Desktop (please complete the following information):

• OS: Linux
• Browser: Chrome
• Version: 80.0.3987.116 (Official Build) (64-bit)

Is your feature request related to a problem? Please describe.
I previously tried using typescript to document components using intellisense but this doesn't always out of the block using user land extensions like Vetur. Vetur mainly supports autocompletion and doesn't use typescript to suggest component props to consumers.

To achieve this, one needs to use a helper json file that we can package in the distribution for consumers' intellisense to parse when they install the package.

Describe the solution you'd like
Template auto completion for component tags and props with documentation.

Describe alternatives you've considered

• https://vuejs.github.io/vetur/framework.html#usage

Additional context
Might require a bit of grunt work and configuration. If someone decides to take this on, please contact me so I can be of support to you :D

Is your feature request related to a problem? Please describe.
Maintaining the CClickAway component is proving to be more difficult than it already is. I've also fond some inconsistencies with it depending on certain conditions in the browser.

Describe the solution you'd like
It may be better to write a click-outside directive that we can bind to the menu and popover components. We could also consume/port a smaller already exisiting external directive like vue-click-outside

Describe alternatives you've considered
https://www.npmjs.com/package/vue-click-outside

Describe the bug
CNumberInput component ids are created at build time and not at component initialization time.

This results in duplication

To Reproduce
Steps to reproduce the behavior:

1. Go to https://vue.chakra-ui.com/numberinput
2. Open dev tools.
3. See id's warning in console

Expected behavior
Id's should be generated only when the component is created.

Screenshots

Can be fixed be moving id generation to a computed property.

Is your feature request related to a problem? Please describe.
Since majority of components inject the $colorMode variable, it would be good to provide either a default/fallback or accompany all $colorMode injections with an error message.

Describe the solution you'd like
The error message should stipulate that the consumer should wrap their application inside the ColorModeProvider component. This error should be logged to the console if the $colorMode is not provided from the parent context.

RADIO

• fix defaultChecked prop
• Implement v-model for RadioButtonGroup
• Ensure v-model works for Radio Group component

Describe the bug
CAlert variant names should all be kebab case.

POPOVER

• Fix Focus visibility styles on open for CPopover usePortal

• Add Function to return ref for initialFocusRef prop.

  • Accepted function should be run inside of nextTick or setTimeout

• Move forwardProps object to follow internal props.

  chakra-ui/chakra-ui-vue

  After prop forwarding, update shorthand props in Popover docs.

• Emit @close event when CPopover closes

• Emit @open when CPopover opens

Describe the bug
The arrow in the Popover component looses its 45° rotation on-update.
The CPopperArrow component initially has styles:
position: absolute; transform: translate(152px, 0px) rotate(45deg); left: 0px;
which becomes:
position: absolute; transform: translate(152px, 0px); left: 0px;

To Reproduce
Steps to reproduce the behavior:

1. Go to 'https://vue.chakra-ui.com/popover'
2. Click on any 'trigger'
3. Scroll or resize window
4. See arrow become square

Expected behavior
The arrow keeping its triangle formation / its 45° rotation.

Screenshots

Desktop (please complete the following information):

• OS: Windows
• Browser: Chrome 81.0.4044.138 / Firefox 74.0 & 76.0.1 (x64)
  Smartphone (please complete the following information):
  (Not a browser/OS related matter)

Describe the bug
Cannot pass Button component as a prop value without it throwing errors. Error message:
The error it throws says that this.$slots is undefined

vue.runtime.esm.js?2b0e:619 [Vue warn]: Error in render: "TypeError: Cannot read property 'default' of undefined"
        found in

        ---> <PseudoBox>
              <Button>
                <MenuButton>
                  <Menu>
                    <ThemeProvider>
                      <App> at src/App.vue
                        <Root>

To Reproduce
Steps to reproduce the behavior:

1. Import Menu & MenuButton components
2. Pass in Button in as prop for MenuButton component.
3. See error

Additional context
I believe this error has much to do with the Button component itself. Will look into this.

Is your feature request related to a problem? Please describe.
Since Vue component templates in VSCode do not have typescript support, it's difficult to consume component libraries without constantly going to and from in between the docs for autocompletion.

Describe the solution you'd like
An extension that suggests component props and types to consumers

Describe alternatives you've considered
Vetur extension might be able to support this feature. Should research and compare

Describe the bug
The CBreadcrumbSeparator is not rendered in between multiple CBreadcrumbItem.

How to reproduce

**Code: **

<CBreadcrumb :add-separator="false">
  <CBreadcrumbItem>
    <CBreadcrumbLink href="#">Breadcrumb 1</CBreadcrumbLink>
  </CBreadcrumbItem>
  <CBreadcrumbItem>
    <CBreadcrumbLink href="#">Breadcrumb 2</CBreadcrumbLink>
  </CBreadcrumbItem>
  <CBreadcrumbItem isCurrentPage>
    <CBreadcrumbLink href="#">Breadcrumb 2</CBreadcrumbLink>
  </CBreadcrumbItem>
</CBreadcrumb>

Output

Expected behavior

The CBreadcrumbSeparator should be rendered in between multiple CBreadcrumbItems by default. When the is-current-page prop is passed the corresponding item separator should be hidden.

Desired Output

Is your feature request related to a problem? Please describe.
No types system is setup for consumers to get auto-complete suggestions in VSCode and/other development environments.

Describe the solution you'd like
Not sure, how exactly to implement this yet, but would be very useful for chakra-ui consumers.

Is your feature request related to a problem? Please describe.
In accordance with the Vue style guide, it is recommended to prefix all our injected variable names with a unique identifier.

Describe the solution you'd like
Prefix all component injected variables with $chakra

This would change our injected variables from:
$colorMode -> $chakraColorMode
$theme -> $chakraTheme
$icons -> $chakraIcons

This will help with preventing namespace clashing with other authors.

Describe the bug
ModalOverlay doesn't close the Modal on click by default.

To Reproduce
Steps to reproduce the behavior:

1. Go to https://chakra-ui-vue.netlify.com/?path=/story/ui-modal--base-modal
2. Click on Show Modal button. Modal should open
3. Click the dark overlay.
4. Modal doesn't close.

Expected behavior
Clicking the ModalOverlay component should close Modal by default.

Additional context
Inspect the ModalOverlay component context to make sure it receives the onClose prop from the $ModalContext. Should invoke onClose function on click.

Is your feature request related to a problem? Please describe.
The CModal component is consumed by both the CDrawer and the CAlertDialog components. In order to provide for better component composition, we need to spread the component options object instead of re-assigning them.

We should also provide for a way to provide meta information to set the component signatures.

Also the following problems need to be fixed.

• Emit @close event instead of consuming onClose prop.
• Spread components objects into component that compose CModal
• Fix blockScrollOnMount

Is your feature request related to a problem? Please describe.
Currently all props declare their own prop types for style props. This hurts bundle sizes.

There is almost no need to strictly limit style prop definitions since any CSS or styled system theme variable can be passed.

This will reduce bundle sizes for props.js and pseudoprops.js since all components reference these.

Describe the solution you'd like
Reference style props from variable.

// Define style prop types
const proptypes = [String, Number, Array]

export const baseProps = {
  w: propTypes,
  h: propTypes,
  p: propTypes,
  // ... Continue for all style props
}

When using the usePortal prop, even though the Popover opens successfully and the CPopoverContent element receives focus, it may not always be visible. This might be because certain domProps of the CPopoverContent are not yet applied by the time the styles object is set in the portal.

Other issues:

• Fix Focus visibility styles on open for CPopover usePortal

• Add Function to return ref for initialFocusRef prop.

  • Accepted function should be run inside of nextTick or setTimeout

• Move forwardProps object to follow internal props.

  chakra-ui/chakra-ui-vue

  After prop forwarding, update shorthand props in Popover docs.

• Emit @close event when CPopover closes

• Emit @open when CPopover opens

Is your feature request related to a problem? Please describe.
Components built are currently not documented. Need help with setting up a documentation site.

Describe the solution you'd like
Nuxt with live editor for components
Demo: http://nuxt-mdx.netlify.com/
Github: https://github.com/codebender828/nuxt-mdx-poc

Describe alternatives you've considered

• vuepress

Additional context
The main idea here is to use Markdown for documenting components
I'd prefer that whoever decides to begin work on this is up for a brief chat. Feel free to contact me on Twitter

Is your feature request related to a problem? Please describe.
Currently the notifications API uses a rather verbose approach when creating a toast notification instance.

This is because the Toast's dependency, breadstick doesn't have access to the current Vue instance upon creation as seen in Toast/index.js.

So consumers will have do something hideous like:

<script>
import { useToast } from 'kiwi-core'

export default {
  name: 'MyComponentWhereToastIsConsumed',
  inject: ['$theme', '$icons', '$colorMode'],
  data () {
    return {
      toast: undefined
    }
  },
  created () {
    // This is too verbose
    this.toast = useToast({
      theme: this.$theme(),
      icons: this.$icons,
      colorMode: this.$colorMode()
    })
  }
}
</script>

Describe the solution you'd like
API should be made more concise until Vue3 comes out

<script>
import { useToast } from 'kiwi-core'

export default {
  name: 'MyComponentWhereToastIsConsumed',
  data () {
    return {
      toast: undefined
    }
  },
  created () {
    // This is too verbose
    this.toast = useToast()
  }
}
</script>

We could use Vue.observable API when the Vue instance is created to trap the current colorMode and the theme variables from the ThemeProvider and ColorModeProvidercomponents. We can also trap the icons from the plugin initialization function.

This proposed store object should be reactive to runtime changes in the colorMode especially. This means we should watch the this._colorMode computed value in the ColorModeProvider component. Every time this value is changed, we then update the store.colorMode value.

This way, an external consumer like breadstick could still access it upon invocation.

This reactive store object can also be be used to store other variables that consumers may require. Until then, this seems to be the best available solution for Vue 2 version of this project until Vue 3 is release.

I'm also open to other ideas if you'd like to share.

Is your feature request related to a problem? Please describe.
Because accessibility is a Chakra UI fundamental concept, I feel that it would be a great idea to document for consumers who answers to the following questions:

"Huh? 😒 How is this button accessible?! Looks pretty alright to me!"

"Also what do you mean this modal is accessible? Hmm? How do I know it is? 🕵🏽‍♂️"

"I'm a Vue developer building a website for a specific group of people and I need to find a component library that supports accessibility and allows me to work fast! Can I use Chakra UI Vue for my end users?"

This aims to describe the supported WAI-ARIA guidelines for all Chakra components. For the sake of of people who might consider accessibility as a core criterium for choosing a component library for an application, I feel that to ease the burden of inspecting the source code, we should briefly document how each component is built support accessibility.

If the Chakra component is a custom/authored component, we should use WAI-ARIA guidelines as a benchmark.

This will also a be a useful resource for developers who would like to know about authoring accessible javascript applications.

Describe the solution you'd like
In each Chakra component folder, we can create an accessibility.md file and describe the component's accessibility there. We can then link to it from the official docs for those who would like to know more.

Ideas and contributions are welcome! 😁

Is your feature request related to a problem? Please describe.
Need to update Popper.js to latest version. This will reduce bundle sizes for the Popper component's consumers

See docs here: https://popper.js.org/

Describe the bug
According to WAI-ARIA specifications for tooltips, the tooltip should be be dismissed if the anchor is focused on Escape keyboard event. Currently if the tooltip anchor is a focusable element (e.g. a Button) tooltip will correctly show on focus, but is not dismissed when the Escape key is pressed.

See: https://www.w3.org/TR/wai-aria-practices/#keyboard-interaction-21

To Reproduce

1. Go to 'https://chakra-ui-vue.netlify.com/?path=/story/ui-tooltip--with-custom-separator'
2. Tab until button is focused. Tooltip should be shown
3. Press Escape.
4. Tooltip remains visible.
   

Expected behavior
Tooltip should be dismissed on escape for focused tooltip anchor
Example: https://cdpn.io/Moiety/debug/LaPvWy

Hi Chakra family.

Following Vue 3's recent release, here is the current roadmap for Vue 3 support for Chakra UI Vue:

Motivation

The next major version of Chakra UI Vue 3 is motivated primarily by 3 things:

1. Upcoming Vue 3 release - The latest major version of Vue.js (v3) will introduce some major breaking changes in it's underlying signature. These changes will cover Vue application startup, plugin registration and installation, the composition API and the render function signature. These changes in Vue 3 will provide some really good opportunities to improve Chakra UI Vue.
2. Chakra UI v1 release - Chakra UI React is also presently planning it's next major release. This new release will introduce some improvements to the theming API for components.

🗺 Roadmap

https://github.com/orgs/chakra-ui/projects/6/views/1

In the coming weeks, I hope to share more ways in which contributors can contribute towards Chakra UI Vue as I focus my efforts on releasing v1.

Describe the bug
When I change a page in the documentation the scroll stays when it was on the previous page.

Expected behavior
I would expect that it always scrolls back to the top.

Desktop (please complete the following information):

• OS: Linux
• Browser chromium, firefox

Additional context
I would really wish this would be fixed because it makes browsing docs confusing.

Describe the bug
Menu performance is poor on JS heavy pages. This occurs when mounting the menu component.

To Reproduce
Steps to reproduce the behavior:

1. Go to https://chakra-ui-vue.now.sh/menu#menugroup
2. Click on Live example MenuButton
3. PAGE MAY JANK BEFORE OPENING AND CLOSING MENU

Expected behavior
The page should not jank while opening and closing complex menus.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Mac OS
• Browser Firefox Developer Edition

Additional context
This will only be visible on pages that have lots of JS code running. So it may not be easily reproducible.

This might be related to the CPortal component. So while working on it, please check to make sure that everything work normally.

Describe the bug
A tab that is disabled can also be said as the default tab with defaultIndex

To Reproduce
Steps to reproduce the behavior:

1. Create 3 tabs
2. Set the defaultIndex props on tabs to the third tab via :default-index="2"
3. Disable the third tab by passing it the is-disabled prop
4. See error

Expected behavior
I suppose Chakra UI Vue should complain or default to the first tab on the list of tabs instead of both disabling the third tab and also showing it's content.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: Pop!_OS
• Browser chrome
• Version 81.0.4044.129 (Official Build) (64-bit)

Is your feature request related to a problem? Please describe.
Add the easing function values for the enterEasing and leaveEasing props for the CCollapse component documentation.

Easing documentation -> https://chakra-ui-vue.now.sh/collapse

The CCollapse component uses animejs, so it accepts the animejs easing props.

Might be related to Issue #69 .

If you wish to own this issue feel free to take this and open a PR against #69.

Is your feature request related to a problem? Please describe.
After testing @chakra-ui/vue with Nuxt.js on various pilot projects, I've noticed that there are inconsistencies in how the @nuxtjs/emotion package server-renders styles. I'm not entirely sure about what causes this because I haven't looked into it extensively.

In some cases the emotion stylesheets are correctly inlined, but after clearing the browser cache and requesting a page in a nuxt app running in universal mode, a flash of unstyled content is shown before the styles are eventually added to the DOM.

Demo of problem: https://chakra-nuxt.now.sh/ (Clear your browser cache before refreshing)

Further more, @nuxtjs/emotion is not actively maintained, I don't entirely feel secure about the future of the project.

In order to solve these inconsistencies, something more secure needs to be built inhouse tht @chakra-ui/vue can rely on.

Describe the solution you'd like
The proposed solution is to create a simple nuxt module with emotion and create-emotion-server to hook into nuxt's vue-renderer:ssr:templateParams and generate hooks inline generated styles of the subject template into the final rendered HTML.

Describe alternatives you've considered
There really aren't any other alternatives I've found to date to fix this problem.

Additional context
Because of this problem, I will not be focusing on making @chakra-ui/vue stable for Nuxt SSR builds until the @chakra-ui/vue release for Vue CLI projects is stable.

We're interested in gathering more ideas and context around this problem as well as other alternative solutions!

The outline variant button spinner should consume the buttons current text color as shown below:

Currently it only uses to the default gray color scheme

Here's a link to our release roadmap, mid-April! 🏵

https://www.notion.so/chakra-ui-vue-9cc2e0c3d9d3470ea13310b17ad937ad

Feel free to share your thoughts or how you'd like to contribute!

PS: It's still a WIP but it gets the idea across :D

Can anybody provide an example how to use this with Gridsome?

Describe the bug
The mobile side navigation does not scroll, it completely seems fixed as one cannot access other part of the links on the documentation.

Expected behavior
The mobile navigation is supposed to be scrollable.

Screenshots

• COLLAPSE
  • Add defaults to CCollapse component docs
  • Add easing props for the CCollapse component

INPUT

• Change CInput component name
• RADIOGROUP
  • Add v-model to CRadioGroup
  • Fix CRadioGroup default value prop
• MODAL
  • Fix function for finalFocusRef on CModal
• EDITABLE
  • Replace default-value prop on CEditable with v-model implementation
• FORMCONTROL
  • FormControl should have as prop
  • vue.common.dev.js:630 [Vue warn]: Injection "$useFormControl" not found in CFormLabel component
• HEADING
  • Change as prop default to h2
  • Fix isTruncated prop
• ICONBUTTON
  • Make arialLabel prop required
• IMAGE
  • Fix size prop on image component
  • Fix fallback-src prop

Is your feature request related to a problem? Please describe.
Currently the slider doesn't have a 2 way binding implementation

Describe the solution you'd like
Implement v-model for the CSlider component