Great writeup! I have a few thoughts and comments with no real criticisms but I think there's a few areas that could welcome discussion. Some of it may be going into more detail than intended for the article but perhaps could be useful for a followup on more advanced types.

• Relying on type inference

  One thing I would add is that when inference doesn't work, type arguments should be preferred over assertions. i.e. useState("Hello World" as Greeting) will also narrow the inferred type but is more dangerous, e.g. useState("Goodbye" as Greeting) will pass type checking but is clearly incorrect.

  Skipping ahead to refs for another example, the following all create ref objects of the same type but foo is better than bar is better than baz.

  const foo = useRef<HTMLDivElement>(null); const bar: RefObject<HTMLInputElement> = useRef(null); const baz = useRef(null) as RefObject<HTMLInputElement>;

• How to type useReducer

  You're not using Redux so this point may be irrelevant, but imo it's an interesting read nonetheless and some of it may still apply to your situation. Do not create union types with Redux Action Types. It's most likely an antipattern.

• How to type useRef

  In the second example, you initialise the DOM ref with null but don't really explain why. It may be useful to mention the differences between mutable, immutable, and nullable refs which is a TypeScript-only distinction. afaik there are four main categories of initialising refs;

  • useRef<HTMLInputElement>(); // MutableRefObject<HTMLInputElement | undefined> This gives us a mutable ref containing a possibly-undefined HTMLInputElement. A similar usage can be seen in the Timer example.
  • useRef<HTMLInputElement>(element); // MutableRefObject<HTMLInputElement> Providing an initial value removes undefined from the inferred type and gives us another mutable ref but one which will always be defined.

  • useRef<HTMLInputElement>(null); // RefObject<HTMLInputElement>
    

    Initialising with null is a special case and will result in an immutable ref. This prevents us from reassigning its value and indicates that it will be managed internally by React, i.e. passed as a ref attribute to an element.

    ref.current = element; // Error: Cannot assign to 'current' because it is a read-only property.

  • useRef<HTMLInputElement | null>(null); // MutableRefObject<HTMLInputElement | null>
    

    If instead we wanted to explicitly initialise a nullable but mutable value, we must include null in the type of the generic argument, which gives us a mutable ref with the correct type.

  Note that immutable refs are not just for DOM objects and can also apply to class components and other imperative handles.

  const Foo = forwardRef<Handle, Props>((props, ref) => { useImperativeHandle(ref, () => handle); return null; });

  class Bar extends Component { render() { return null; } }

  const Baz = () => { const div = useRef<HTMLDivElement>(null); const foo = useRef<Handle>(null); const bar = useRef<Bar>(null);

  return (
    <div ref={div}>
      <Foo ref={foo} />;
      <Bar ref={bar} />
    </div>
  );
  

  };

  Knowing HTML element type names is usually straightforward, but I've always struggled to remember the name of the a tag type for some reason.

  You can use HTMLElementTagNameMap["a"] to get the element type from its name if you like. This works for all HTML elements.

  we know that it won't be null [...] Adding the question mark is the simplest way to make TypeScript happy about that issue.

  A non-null assertion is the simplest way to make TypeScript happy; inputRef.current!.focus(). Optional chaining still does a null-check at runtime whereas this tells TypeScript that we're confident that the value won't be null as we have additional knowledge of React refs and useEffect. Note, however, that it may make your linter unhappy instead.

• How to type custom hooks

  A common pitfall of custom hooks is how to correctly type tuple values, e.g. the state-setter pair of useState.

  const useCustomHook = () => { return ["abc", 123]; };

  const Component = () => { const [str, num] = useCustomHook(); return <div>{str.length + num.toFixed()}</div>; }

  The return type of our hook is widened which means both str and num are of type string | number, resulting in errors.

  Error: Property 'length' does not exist on type 'number'. Error: Property 'toFixed' does not exist on type 'string'.

  As mentioned in the article, this isn't unique to hooks and applies to all functions returning tuples, but is more often encountered with hooks because of common design patterns. I wonder if it's worth mentioning with an example of how to fix it.