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

V6 (Chakra UI V3) #341

Draft
wants to merge 45 commits into
base: main
Choose a base branch
from
Draft

V6 (Chakra UI V3) #341

wants to merge 45 commits into from

Conversation

csandman
Copy link
Owner

@csandman csandman commented Oct 11, 2024

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
    • Adds disabled, which will override the isDisabled prop built-in to react-select
      • This is just to keep the props consistent with each other.
  • Add a default for the menuPlacement of "auto". This is to more closely match the default flipping behavior of the Chakra Select.

Copy link

github-actions bot commented Oct 11, 2024

📊 Package size report   -5.2%↓

File Before After
dist/index.d.mts 19.9 kB -11.7%↓17.6 kB
dist/index.d.ts 19.9 kB -11.7%↓17.6 kB
dist/index.js 32.5 kB -3.43%↓31.4 kB
dist/index.mjs 30.9 kB -3.71%↓29.8 kB
package.json 3.1 kB -1.06%↓3.1 kB
README.md 47.5 kB -2.34%↓46.4 kB
Total (Includes all files) 154.9 kB -5.2%↓146.9 kB
Tarball size 31.1 kB -3.73%↓29.9 kB
Unchanged files
File Size
LICENSE.md 1.1 kB

🤖 This report was automatically generated by pkg-size-action

Copy link

pkg-pr-new bot commented Oct 23, 2024

Open in Stackblitzchakra-react-select-demo

yarn add https://pkg.pr.new/[email protected]

commit: a645027

@mskasal
Copy link

mskasal commented Nov 11, 2024

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

@csandman
Copy link
Owner Author

csandman commented Nov 13, 2024

@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 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
Copy link

b4stien commented Nov 14, 2024

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
Copy link
Owner Author

csandman commented Nov 14, 2024

@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
Copy link

sblyvwx commented Nov 18, 2024

@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
Copy link
Owner Author

csandman commented Nov 18, 2024

@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
Copy link

dontic commented Nov 29, 2024

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
Copy link

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

@csandman
Copy link
Owner Author

csandman commented Dec 2, 2024

@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!

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

Successfully merging this pull request may close these issues.

6 participants