Thank you, I glad you enjoyed my article. About your comment, I think you are partly correct. I think you can split my answer into two parts - real-world projects (very big projects) and side/learning projects (small-medium project)
big projects - In big projects, you are right. You shouldn't break your components into small parts because it's tough to manage them and "remember" what you already have.
small - medium projects - In my opinion, it's a good practice to break your components into small parts in this case. Because when you will work on a big codebase, you will have this design pattern as part of your abilities (you just need to modify it to fit big projects design).
But of course, there isn't only one correct way, mostly if you talk about design pattern please don't take my examples as is. Try yourself, and modify them to your needs.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thank you, I glad you enjoyed my article. About your comment, I think you are partly correct. I think you can split my answer into two parts - real-world projects (very big projects) and side/learning projects (small-medium project)
But of course, there isn't only one correct way, mostly if you talk about design pattern please don't take my examples as is. Try yourself, and modify them to your needs.