DEV Community: Aurora

The problem with callbacks depending on state inside useEffect you might not be aware of!

Aurora — Sun, 14 Nov 2021 14:48:03 +0000

While writing React code. I have come across an issue that was really hard to figure out why it happened, but had a really fix, and so I thought I'd publish it for future devs to be aware of!

The setup

So you might have a react functional component that uses the useState hook, some useEffects and that has some complicated logic inside a listener, and so you've placed the logic inside a callback that references the state:

const MyComponent = () => {
    const [myState, setMyState] = useState()

    const myHelper = () => {
        /* does stuff based on myState in here*/
    }

    useEffect(() => {
        addListener(myHelper())
    }, [/* some dependencies */])

    return (<div/>)
}

What you might notice is, when the state changes, the handler being executed by the listener still uses the old state!

It seems like the it captures its environment and uses that!

This can be really confusing to figure out why it does this.

The solution

To solve this, you need to do two things:

add the state to the dependency array
remove the listener on state change

useEffect(() => {
    // store the listener to be able to remove it later
    const listener = addListener(myHelper);
    return () => {
        // actually remove the listener in the cleanup
        listener.remove();
    };
    // add myState to the dependencies              
}, [myState, /* other dependencies*/])

And that's it!

Conclusion

This might seem obvious at first, add all the states that the useEffect depends on inside the dependencies array.

But the tricky part here is, you might have more dependencies than you think at first!

It's not just the states directly used inside the useEffect hook, but it's also all the states used by functions that are called in here!

So the next time you think of what dependencies need to go in the dependency array, don't just look at what states are used inside the hook, but also at which ones are used in functions inside the hook!

Don't use Function Components, use Void Function Components

Aurora — Mon, 23 Aug 2021 17:09:58 +0000

One thing you'll come across when using Typescript with React is giving types to your components.

Most places I've seen will use React.FC for this:

const MyButton: React.FC<MyButtonProps> = ({prop1, prop2}) => {
  //...
}

And while React.FC is an actual type, most uses of it are incorrect.

This becomes clear when you look at its definition:

type FC<P = {}> = FunctionComponent<P>;

interface FunctionComponent<P = {}> {
    (props: PropsWithChildren<P>, context?: any): ReactElement<any, any> | null;
    propTypes?: WeakValidationMap<P> | undefined;
    contextTypes?: ValidationMap<any> | undefined;
    defaultProps?: Partial<P> | undefined;
    displayName?: string | undefined;
}

The notable thing here is that props gets PropsWithChilren, which means that you component will be able to take children in adition to your other props you passed in.

On the other hand, there also exists Void Function Components or VFCs:

type VFC<P = {}> = VoidFunctionComponent<P>;

interface VoidFunctionComponent<P = {}> {
    (props: P, context?: any): ReactElement<any, any> | null;
    propTypes?: WeakValidationMap<P>;
    contextTypes?: ValidationMap<any>;
    defaultProps?: Partial<P>;
    displayName?: string;
}

The only difference between this and FC is that when you tell it that P is its props, it will use just that, and it won't add an aditional children props to the final type.

conclusion

If you have some sort of pannel component or an abstract component which takes in children to render, then yeah, React.FC is the type for those.

But if the component you have isn't meant to have any more children, like a custom button or a custom card or input or whatever else, then using React.VFC is more correct.

Improve your callbacks by making their return meaningful

Aurora — Fri, 13 Aug 2021 21:44:21 +0000

When dealing with the more interractive elements of React like inputs or buttons, you will often come across the need of passing around callbacks like this:

const MyInput = (props) => {
  return(
    <input
    type="text"
    value={props.value}
    onChange={props.onChange}
    />
  );
}

And focusing on the onChange part of the snippet, it will call the callback with the values and that's about it, ignoring if it returns anything.

But with a need for making it easier to make stuff happen when pressing enter, I came up with the following snippet:

const MyInput = (props) => {
  return(
    <input
    type="text"
    value={props.value}
    onChange={props.onChange}
    onKeyDown={(e) => {
      if (e.key === 'Enter') {
        props.onEnter()
      }
    }}
    />
  );
}

usually with the idea that I should make it blur sometimes when I press enter. And then I had the idea that props.onEnter() should return if it will stay focused or not, leading to the following idea:

const MyInput = (props) => {
  const inputRef = useRef(null);
  return(
    <input
    type="text"
    ref={inputRef}
    value={props.value}
    onChange={props.onChange}
    onKeyDown={(e) => {
      if (e.key === 'Enter') {
        const keepFocus = props.onEnter();
        keepFocus || inputRef.current.blur();
      }
    }}
    />
  );
}

This way, whenever I need to use my custom MyInput component, I can write an elegant onEnter callback like this:

<MyInput
value={value}
onChange={setValue}
onEnter={() => {
  if (value === '') {
    return false;
  } else {
    process(value);
    setValue('');
    return true;
  }
}}
/>

so that if the user presses enter when there is something in the input field, it will process it and clear it, keeping focus on it. But if it is empty, it will simply blur the input field.

A similar pattern can be found in React's useEffect hook, it's basic idea is that you just pass in a callback for what it should execute after each render, but if you need it to clean up, you make the callback return a cleanup function.

So the next time you make a component take a callback, consider if you can give your code more functionality by working with what it returns.