1. If a component changes state and its parent doesn't, then the other children aren't considered so it would be O(1). If the parent rerenders, then yes, we would consider each child and it would take O(n).

2. Yes, it would. You would really have to go out of your way to make that happen, though. React has a feature for batching state updates together to prevent unnecessary rerenders if all of the updates occur together. Beyond that, it's rarely an issue.

If you have a particularly long list you can use a tool like react-virtualized (https://github.com/bvaughn/react-virtualized) so that only the onscreen rows are rendered at all.

> You would really have to go out of your way to make that happen, though. React has a feature for batching state updates together to prevent unnecessary rerenders if all of the updates occur together.

These batched state updates only happen "within React's walls", right?

So for example, say you had an RxJs observable that omitted a list of items to display. When you first subscribe, it emits say, ten items, one by one, but all in the same browser tick. It may emit items later in the future as well.

In this case, each of the initial emitted items triggers a full rerender and you get the O(N^2) behavior, correct? My point here isn't that this is the end of the world, but just that it isn't that crazy to say that it might happen.

Yes, you're generally correct. If you can call into ReactDOM.unstable_batchedUpdates at the top of the stack, that's another approach. We might be able to make that the default in the future so synchronous calls are always grouped even if React isn't on the stack.

We generally see the most success when you update your data wholesale with the latest copy from your stores, but your RxJS example is a good one.