V6 (Chakra UI V3)

[csandman]

This is still very much a work in progress, I'm just going to leave this open in draft state while I work on it.

To test out the Chakra V3 compatible version, install it using the following.

npm i chakra-react-select@next
# or
yarn add chakra-react-select@next

---

Just to keep track, here are some loosely formatted notes on what changed:

• All of the styles pulled from the end user's theme are now using styles from the select component (except for the control which still uses input styles).
• Everything that was colorScheme is now colorPalette
  • tagColorScheme -> tagColorPalette
  • selectedOptionColorScheme -> selectedOptionColorPalette
  • An individual option's colorScheme -> colorPalette
• Some props were removed from chakraComponents.LoadingIndicator (they no longer exist on the Chakra Spinner):
  • emptyColor
  • speed
  • thickness
• focusBorderColor and errorBorderColor were removed as custom props, as they no long exist on the input/select.
• All boolean props have had the is prefix removed:
  • isRequired is now the required attribute that's already built-in to react-select.
  • isReadOnly -> readOnly
  • isInvalid -> invalid

[github-actions[bot]]

📊 Package size report   -2.15%↓

File	Before	After
dist/index.d.mts	19.9 kB	-1.71%↓19.6 kB
dist/index.d.ts	19.9 kB	-1.71%↓19.6 kB
dist/index.js	32.5 kB	-4.78%↓31.0 kB
dist/index.mjs	30.9 kB	-4.92%↓29.4 kB
package.json	3.1 kB	-4.3%↓3.0 kB
README.md	47.5 kB	1%↑48.1 kB
Total (Includes all files)	154.9 kB	-2.15%↓151.6 kB
Tarball size	31.1 kB	-4.32%↓29.7 kB

Unchanged files

File	Size
LICENSE.md	1.1 kB

_{🤖 This report was automatically generated by pkg-size-action}

[pkg-pr-new[bot]]

Open in Stackblitz • chakra-react-select-demo

npm i https://pkg.pr.new/chakra-react-select@341

commit: 4321ee3

[mskasal]

@csandman Hello there. Do we have a timeline for migrating to ChakraUI v3? And how can we help?

[csandman]

@csandman Hello there. Do we have a timeline for migrating to ChakraUI v3? And how can we help?

Hey, sorry for the delay in communication, I've been very busy recently and haven't had as much time to focus on this project as I'd like. Let me give a rundown of the current situation.

So, for full transparency, my company isn't planning to upgrade to Chakra V3 in the near future due to the dramatic size of the refactor necessary. That means that I will most likely not be personally using this new version of chakra-react-select in production for the forseeable future. Because of that, it's made me pretty hesitant to mark this as an official release, as I haven't really had a chance to stress test it in a production environment as much as I'd like.

Besides that, the biggest blocker really is updating the docs. With all of the changes to the core component APIs along with the theming API in Chakra v3, I will have to do a full refresh of the docs for this project to reflect those changes, and how this package utilizes them. Overall, it's not actually too complicated past the changes I mentioned above, I just wrote a giant wall of text for the docs over time, and it's going to take a while to comb through them haha.

---

Now, all that being said, I think the changes in the 6.0.0-next.3 are pretty much production ready! The best thing people can do to help get this fully released is to give it a try in a real app and give some feedback on it. That feedback can be anything from "it's working fine" to "it's totally broken in this use case", to "it's missing this core feature that would be great for v3 compatibility". If it does work fine, that feedback will help give me the confidence to put an official release tag on it and ship it. It's just been tough for me to call it an official release because I haven't really heard any feedback on this pre-release so far, positive or negative.

And if there is any feedback around things genuinely not working properly, I will do my best to get things fixed in a timely manner to avoid slowing anyone's development down. If you post an issue on a weekday, I should have a fix ready by the next night, if not the same night (barring anything that involves major architectural changes).

[b4stien]

The next-themes peer dependency is a bit too restrictive, chakra (3) snippet CLI asks for next-themes ^0.4.3. Maybe you can align with them?

EDIT: If others are blocked and are using npm, this block in package.json supress the error and force next-themes to the wanted version:

  "overrides": {
    "chakra-react-select": {
      "next-themes": "$next-themes"
    }
  }

[csandman]

@b4stien Good call, I intended for that version ^0.3.0 to match all minor versions above 0.3.0, but I forgot that the ^ flag doesn't count the second version num as a minor version when the major version is 0, so this was only matching 0.3.x versions. I'll deploy a new version with more lenient version matching in a little bit.

---

EDIT: Ok I just pushed a new version that changes the peer dependency requirement of next-themes to 0.x, so hopefully that fixes you problem! The change is live in v6.0.0-next.4

[sblyvwx]

@csandman Hi, I just wanted to mention that I encountered runtime errors on my side if any of the Select components weren't enclosed within the Chakra's Field component. The error was "TypeError: Cannot read properties of undefined (reading 'readOnly')", meaning that inputProps.readOnly and similar properties were undefined.

[csandman]

@csandman Hi, I just wanted to mention that I encountered runtime errors on my side if any of the Select components weren't enclosed within the Chakra's Field component. The error was "TypeError: Cannot read properties of undefined (reading 'readOnly')", meaning that inputProps.readOnly and similar properties were undefined.

Ok thanks for letting me know, I'll take a look tonight! Can you provide an example of your implementation of it that I can go off of?

---

EDIT: Nevermind @sblyvwx, I realized I just made a really stupid mistake. Somehow I totally missed handling the case where the Select is used outside of a Field.Root (a very common case, I could have sworn I had tried that). Anyway, a fix is available now in 6.0.0-next.5!

Now that I think about it, the reason I hadn't thought anything of it is that the return typing on the useFieldContext hook doesn't have the potential to be undefined which is technically wrong, but whatever.

[dontic]

That feedback can be anything from "it's working fine"

I just implemented a pretty complex case with debouncing using 6.0.0-next.5 like this and it's working like a charm:

// Async Listing select stuff
const [listingValue, setListingValue] = useState<any>(null);

const _loadListingOptions = (inputValue: string, callback: any) => {
  autovisitaListingsList({ search: inputValue }).then((response) => {
    const newOptions = response.map((listing) => ({
      label: listing.title,
      value: listing.pk
    }));
    callback(newOptions);
  });
};

const loadListingOptions = useDebouncedCallback(_loadListingOptions, 500);

{/* ... */}

{/* Listing */}
<Field
  label="Listing"
  invalid={errors.listing ? true : false}
  errorText={errors.listing?.message}
>
  <AsyncSelect
    name="listing"
    placeholder="Select listing"
    loadOptions={loadListingOptions}
    noOptionsMessage={() => "Start typing to search"}
    loadingMessage={() => "Loading..."}
    onChange={(value: any) => {
      setListingValue(value); // Set value to local state
      setValue("listing", value?.value); // Send value to hook form
    }}
    value={listingValue}
  />

  <Button
    size={"xs"}
    variant={"subtle"}
    colorPalette="gray"
    onClick={() => {
      setValue("listing", null);
      setListingValue(null);
    }}
  >
    Clean
  </Button>
</Field>

Note: I'm controlling listingValue so I can pass it initial data gathered from my API.

[lovegehlin]

Things are working fine here using 6.0.0-next.5.

[csandman]

@dontic @lovegehlin Thanks for the feedback! I'm working on the changes to the docs now, so I should have the first full release ready pretty soon!

[csandman]

Good news, I spent a bunch of time tonight going through the docs and updating a large portion of it. I updated the docs for all of the custom props provided by this package, as well as the correlations between the react-select components and the Chakra theme styles they are now pulling from. In the process, I also updated the demo to include examples for all of the custom props, giving me the opportunity to test everything more thoroughly. I caught a few more issues with the styling that are now also resolved, and the demo should look more "real" now for anyone who wants to test it.

If you do want to test it, you can use the chakra-react-select-demo link from the @pkg-pr-new comment above: https://github.com/csandman/chakra-react-select/pull/341#issuecomment-2430618608

After these changes, I'm much more confident in the current state of this branch, so I also released the first release candidate version, v6.0.0-rc.0! There aren't too many obvious differences, but I did fix a few styles, and I added the prop focusRingColor to replace the previously removed focusBorderColor. There was also a font-sizing issue fixed with the empty messages, as well as a new wrapping "end element" for the tag remove button.

I still have some left to do to get the readme docs up to date, including replacing all of the examples, but it should be mostly possible to figure everything out based on the other changes to the docs, which you can see here: https://github.com/csandman/chakra-react-select/tree/v6?tab=readme-ov-file#chakra-react-select-v6

And besides that, I plan to put together a more comprehensive change list to be provided with the release notes.

[JAD3N]

The react-select dependency on the V6 branch has a peer dependency of up-to React 18. Would it be fine to bump the version to 5.9.0 so there are no peer dependency warnings when using React 19?

[csandman]

The react-select dependency on the V6 branch has a peer dependency of up-to React 18. Would it be fine to bump the version to 5.9.0 so there are no peer dependency warnings when using React 19?

@JAD3N Good callout, I had seen the release notification but forgot to handle the implementation. I just went ahead and published v6.0.0-rc.3 which updated the peer dependency for react-select to be a bit more lenient, and allow for react-select ^5.8.0 (anything in the 5.x range above 5.8).

In order to ensure everything still works, I also went ahead and updated all of the dependencies of the demo so that is now also on react@19, and everything is working like a charm! Give it a try when you get a chance.

---

EDIT: Actually, I just pushed one more new version with a minimum react-select version of v5.9.0 haha. This should make it easier for people to upgrade without manually upgrading the nested dependency with something like npm upgrade. The latest version is now v6.0.0-rc.4.

[maulik13]

I have been using rc.4 and it has been working great so far. I had to adjust some of the old styling, but the it was more of removing them since the default out of the box in chakra v3 works great.

[csandman]

I have been using rc.4 and it has been working great so far. I had to adjust some of the old styling, but the it was more of removing them since the default out of the box in chakra v3 works great.

Thanks for the feedback! When you say "removing them", do you mean removing custom styling you previously had using the chakraStyles prop or something?

---

The goal of the styling for this package has always been to rely on Chakra styles directly as much as possible, adding only minimal overrides to bridge the gap between the differences in DOM structure between the built-in Chakra components and React Select components, as well as their differences in the absolute positioning of the popover. Previously, I had to rely on pulling in styles from the closest available counterpart to a select, that being the Chakra Menu. However, with the addition of the new custom Select component in Chakra v3, along with them making the components/theme styles much more granular, the components that make up React Select and the Chakra Select component align much more closely overall. This allowed me to remove many of the custom style overrides I had previously included just to render the component properly.

Hopefully, this should make it much easier for people to rely on their own theme styles in order to make this component appear as they'd like it to. And also to hopefully be styled more like they'd expect it to be in general, with less quirks when it comes to styles that are unexpectedly necessary to override.

[csandman]

Ok all, the official release is most likely coming Monday! Thanks for all the support!

[maulik13]

I have been using rc.4 and it has been working great so far. I had to adjust some of the old styling, but the it was more of removing them since the default out of the box in chakra v3 works great.

Thanks for the feedback! When you say "removing them", do you mean removing custom styling you previously had using the chakraStyles prop or something?

Sorry for the late reply, I meant that the old styling was specific to chakra-v2 customization to match my app. It did not break anything (if I remember correctly), but it was more of just a small clean up. Looking forward to the new release :D

[csandman]

v6 is officially released, give it a try and let me know if anything isn't working right!