Hi Toth
I have few questions about your reply.
So far I understand very well what Scott thinks about React clean components and the good guidance how to refactor it.
In his article, he described very well with concrete examples and why it’s better to do so.
On the other hand, I feel that your opinion seems to be bit vague.
If system requirements are complicated, the both case (having few huge components or many tiny components) will have same complexity.
Because we need to adapt same complicated and huge business requirements. I think we can’t avoid it.
After reading article of Scott, I agree that the idea of single responsibility component helps at least readability and maintenance cost.
For instance, about readability if we make components tiny, we can have meaningful & readable names for these components.
It helps developer to have insights for these components & responsibility easily and quicker. These points I could get from this article.
To understand your opinion well, it would be helpful for me that you could provide with concrete examples and use cases so that we can apply your practice to the real projects.
E.g. about your comments :
Sometimes separation is good, it helps manages huge complexity by replacing it with moderate complexity.
So for which use cases or example, can you suggest to avoid separation ?
You liked your blog post (https://arpytoth.com/2018/01/25/solid-premature-optimizations/), but I couldn’t read it…
