Yea idk. Or you can just change the perspective to: all the old stuff is actually client model + hydration like oldschool next, but and then you have new capabilities for rendering markup on server with RSC instead of hydration. Just think of it as a new additional tool in your toolbelt that you might want to use to offload big dependencies from the client bundle and run on server instead.
But from that real situation with props.dataSource, I would not expect the state from that useState to return a new value on prop update, even in a normal react app / without next. If you are not setting this client state (with the second method destructed from the hook) you could potentially ditch the useState completely and just run that data.slice(0, defaultShowItems) as is in the function body, or wrap in memo if calculation is expensive.
> Just think of it as a new additional tool in your toolbelt
This is the best way to introduce it. Vercel makes it too complicated in the docs where everything is splitted into app/pages, creating a large ecosystem gap.
But from that real situation with props.dataSource, I would not expect the state from that useState to return a new value on prop update, even in a normal react app / without next. If you are not setting this client state (with the second method destructed from the hook) you could potentially ditch the useState completely and just run that data.slice(0, defaultShowItems) as is in the function body, or wrap in memo if calculation is expensive.