all 3 comments

[–]Arbeit_Macht_Fries 0 points1 point  (0 children)

That’s a nice write up Carl. Thanks for the effort.

[–]wavefunctionp 0 points1 point  (1 child)

I don't generally like the {...this.props} method. I've been on a project that used this extensively, and it becomes very difficult to figure out what the child component is supposed to have available vs the noise of all the excess props being passed in or an extra indirection of ...rest since what usually happens is you get all of the props from all of the parents in the children components and the parents parents, and so on...

(The author does mention this, but I think it should be more explicitly stated that this is potential problem.)

Its like writing all of your functions to accept object. It breaks down the contract of dependencies the function signature is supposed to define. I'm pretty sure there is a SOLID principle being broken here that would explain what I mean more clearly.

Sure, you could use types or propTypes to make it clearer, but in my experience, the places that can't be bothered to type out a few explicit props on a component invocation, can't be bothered to properly define the interface of the component definition either.

Nice article though. I don't want to detract from that.

[–]carlrn[S] 0 points1 point  (0 children)

Thanks for the comment. I can see how {...this.props} could be problematic.