deep-object-diff | Deep diffs two objects , including nested structures

that would mean any time the incoming props change, those get immediately reflected in state

Yes, that's wrong. When I first started out I was doing the same thing.

1. state is something "owned" by that component (noteworthy: not all components need state at all!).
2. props are something that are "owned" by a higher component.

Best example:

ComponentA passed an id to ComponentB as a prop. ComponentB uses that id to make an API request (for example).

The status/results of that API request form part of ComponentB's state (it's "owned" by your component). The id passed in as a prop is NOT part of ComponentB's state (it's owned by ComponentA, or maybe somewhere higher in the tree that passed it as a prop to ComponentA).

When the id prop changes, ComponentB will need to make another API request.

EDIT:

The complexity of lifecycle methods is why React has highly encouraged functional components.

You should think of components as functions. It's a lot easier to write the logic if you just think of it as input -> output.

componentDidUpdate has been moved to useEffect with a dependency list so you can say - run this function, but only when this prop changes - which is a nice way to break down massive componentDidUpdate methods into tiny readbale/testable chunks.

I've heard a lot of people say hooks ruined react, but I highly disagree with them. React saw the problems people were running into in the community by misusing class/instance based components and instead of lecturing about how to use them correctly, they nudged people to writing better components by introucing a simpler API - functions, while they still can and will be abused - are generally simpler to deal with than classes and align nicely with composition over inheritance and declarative over imperative.