Skip to main content

Migrating from Pretty Checkbox React 2

I'll be frank with the readers of this guide. PCR 2.x was kind of a architectural nightmare. While it offers features with state management, many of the architectural decisions were short-sighted. The crux of the issue was twofold:

  1. Component never achieved real decoupling from the composition model which in turn lead to tight coupling with a new Pretty component
  2. The code has an insane amount of indirection and in certain user flows it becomes exceedingly difficult to follow

PCR 3.x addresses both issues.

Breaking Changes#

PCR 3.x introduces a few breaking changes you need to be aware of.

Group and RadioGroup Removal#

These components were introduced with the intent of making PCR "more" accessible. The fact is, they were never needed. PCR is accessible by default without the bloat of unnecessary role and aria-* props. PCR 3.x fixes these issues.

Migrating from RadioGroup#

RadioGroup is just a fieldset. See more on why this change was made.

- import { RadioGroup, Radio } from 'pretty-checkbox-react';+ import { Radio } from 'pretty-checkbox-react';
function App() {    return (-       <RadioGroup>+       <fieldset>            <Radio name="pizza" value="thin">Thin Crust</Radio>            <Radio name="pizza" value="reg">Regular Crust</Radio>            <Radio name="pizza" value="dd">Deep Dish</Radio>+       </fieldset>-       </RadioGroup>    )}

Migrating from Group#

If you're using Group replace with a div:

- import { Group, Radio } from 'pretty-checkbox-react';+ import { Radio } from 'pretty-checkbox-react';
function App() {    return (-       <Group>+       <div>            <Radio name="pizza" value="thin">Thin Crust</Radio>            <Radio name="pizza" value="reg">Regular Crust</Radio>            <Radio name="pizza" value="dd">Deep Dish</Radio>+       </div>-       </Group>    )}

useSwitchState Removal#

The useSwitchState hook existed for the sole purpose of convenience; however introduced problems with tree-shaking.

Our hypothetical scenario is a Switch component used as a radio or a checkbox. useSwitchState calls both hooks and decides which props to forward based on a parameter. No only does this mean none of the hooks can be removed from production bundles, but twice the amount of work was being done in the useSwitchState state hook ๐Ÿ˜ข!

Replace with:

  • useRadioState
  • useCheckboxState
CheckboxSwitch.tsx
- import { useSwitchState, Switch } from 'pretty-checkbox-react';+ import { useCheckboxState, Switch } from 'pretty-checkbox-react';
function App() {-    const checkbox = useSwitchState();+    const checkbox = useCheckboxState();    return <Switch {...checkbox} />}

and when used as a radio...

RadioSwitch.tsx
- import { useSwitchState, Switch } from 'pretty-checkbox-react';+ import { useRadioState, Switch } from 'pretty-checkbox-react';
function App() {-    const radio = useSwitchState({ type: 'radio' });+    const radio = useRadioState();    return <Switch {...radio} />}

baseId Removal#

Mainly an internal prop in PCR 2.x, the baseId prop has been removed. If you're using this, remove the prop from your code ๐Ÿ˜„

fill Rename#

The fill prop has been renamed to variant. This allows for you to create custom variants in pretty-checkbox and have them applied to PCR 3.x without any extra code changes required on the PCR side.

<Checkbox-    fill="fill"+    variant="fill">    Hello</Checkbox>

Non-Breaking Changes#

If I can sum it up in three words: return to simplicity. PR 2.x was a weird soft-control hybrid with questionable accessibility, yet still using semantic HTML elements. In reality, none of the complexity was needed. I've learned a lot since PCR 2.0 was released and this time it's here to stay.

  • Removal of keyboard handlers on .pretty
  • Removal of Pretty components (if you're using these โ€“tsk tsk โ€“ they're not "public")
  • Removal of some (not all) aria-* props
  • Addressing accessibility issues in Switch
  • Fixing webpack error when building nanoid@3. PCR 3.x uses nanoid/non-secure so no crypto polyfill is needed for legacy clients ๐Ÿ˜Ž
  • Intuitive indeterminate support via state or prop (your choice)
  • The checked prop actually works now
  • ...and tonnes of type fixes ๐Ÿ‘ผ