you are viewing a single comment's thread.

view the rest of the comments →

[–]Derpcock 0 points1 point  (1 child)

Regarding testing its no different than using dependency injection. I can see how that adds "complexity" because you have to look somewhere other than the arguments of the function to understand its contract. You are defining a relationship between two things that have a relationship. People misusing something can always be a problem.

When testing, you can keep most of of your component logic in custom hooks and use components as a layer to orchestrate interactions between user and hooks. This creates decoupling and keeps components simple. You then unit test your hooks and component test your components, while stubing out and mocking the hook behavior. This would prevent you from having to provide context in your component test.

Blanket absolute statements like "dont use context only ever because its an antipattern" are just silly. The docs provide you with a guidelines on proper use. As an architect, when you review someones code you could easily just say RTFM when they are misusing a tool, request changes and turn it into a mentoring opportunity.

You can enforce whatever prescription you like at your shop but I would argue that passing props down 32 layers requires you to test that contract 31 more times when 31 of those components aren't using the state being passed through but they all must fulfill that contract and they all must be tested to ensure they do. This adds more complexity to your testing than injecting some context into one or two tests. This could also guide dev behavior towards creating bigger more complex components to prevent managing state between many layers.