This is a great question and not one that many feel comfortable asking.
Just like any software architecture decision, there's almost never a right or wrong answer. It's a skill that you'll get better with over time. I think of it as intuition-based skill. Here are some of the lessons that I have learned that may help with learning.
Take a small amount of time (actual amount will depend on the size of the feature) and think about your architecture before you write any code.
Write a brief outline/mind map (it doesn't have to be super detailed), organizing your components and where the business logic will go within those components.
Breaking up the business & view logic will help you get a birds eye view of the feature rather than trying to keep it all in your head as you're implementing it.
Many engineers jump into coding to figure it out as they go. This step is a simple way to save yourself time by forcing yourself to outline the components before hand. You'll spot patterns and be able to see where you may be repeating logic.
Imagine what is likely/unlikely to change.
Let's say that you're about to implement a simple Button component. Imagine that you are yourself in 3 months (or 6 months or a year etc...) and for whatever reason, your requirements have completely changed. What is still going to be true regardless of those requirements and what would likely change? In the most simple case, you know a button is always going to have certain functionality that's inherent to buttons, but popular style trends change with the weather. What does this tell you about implementing the button?
It's easy to get carried away with this one. Don't over-optimize and try to think of every scenario. It's okay if you have to go back and change your code.
Don't invest extra time to make your component adapt to your predicted future requirements. This is important. This is the over-optimizing fallacy. The benefit of this step is that you should only spend the same amount of time/effort as you would if you were to naively implement the component.
Avoid Paralysis by Analysis.
I struggle with this one a lot. It's not important that your code is perfect from the start. Try time boxing your architecture decisions and if you're not confident by the end of the time box, then just go with it. You can always change code later.
Reflect on every decision post-implementation.
You'll realize that you made mistakes... don't get discouraged. That's how you learn this type of skill.
Sometimes your decision that ended up being a mistake was the right decision given what you knew at the time. Be honest with yourself. Reflect on whether you could have made the right decision given the information that you had at the time.
I highly recommend Clean Code by Bob C. Martin & Pragmatic Programmer by Andrew Hunt & David Thomas. Both are really great books on this topic.
This is a great question and not one that many feel comfortable asking.
Just like any software architecture decision, there's almost never a right or wrong answer. It's a skill that you'll get better with over time. I think of it as intuition-based skill. Here are some of the lessons that I have learned that may help with learning.
Take a small amount of time (actual amount will depend on the size of the feature) and think about your architecture before you write any code.
Imagine what is likely/unlikely to change.
Avoid Paralysis by Analysis.
Reflect on every decision post-implementation.
I highly recommend Clean Code by Bob C. Martin & Pragmatic Programmer by Andrew Hunt & David Thomas. Both are really great books on this topic.
I hope that this helps.
Thats some really good tips there, thanks for sharing.