It's been 4 months that I've learnt just enough React to build some very basic apps that consume API and can also dynamically handle routes.
So far, I've build a number of projects with React that just work fine, but something that always seem to be in common with these projects are the lack of a solid structure and organisation to the project.
I strive to make my code follow the 'SOLID' principles and other such best practices, but I have frequently found myself in situation where I'm deep into a project and some feature addition requires either a lot of refactoring or duplicating the code.
Also, off-topic, something that I noticed is how rapidly Typescript is being adopted in almost every React project and is growing in demand among the tech companies.
So in all, I have few questions to ask the veterans and this community.
Where do I go from here to develop production grade React clients?
Does Typescript solve some part or all of the above problem?
I know, I'll need a lot of practice and I'm totally down for it, but I don't want to become a world-class spaghetti chef by cooking spaghetti all the time, instead I just need a way to learn about the design patterns and philosophies that Pro React Devs use.
A deep gratitude If someone is possibly open to guide me or mentor me in any way. Thank youđ
Thank you for reading.
Top comments (26)
This is a sign of growth and itâs a great and normal thing. The fact that youâve made it this far means youâve cleared the most difficult hurdle.
To help you power through this, I would recommend not focusing on a specific technology (i.e. TypeScript) and instead focus on building something interesting to you. In doing that, youâll be pushing through challenges youâd never even encounter when trying to find tutorials and build other peopleâs examples. This, of course, assumes you arenât working for a company already building a production app.
Iâd also note that refactoring code to add new feature is learning. Itâs an important part and you shouldnât run from it. You should pat yourself on the back for every refactor and every new thing you learn đ
Agree! In fact, in my opinion every feature you add should involve some amount of refactoring, or youâve been doing to much (potentially wasteful) work prematurely.
Besides: continuous refactoring is one of those good old practices that are all too often forgotten these days. As I see it, the only way to write maintainable code is to constantly maintain it.
âGetting it right the first timeâ rarely happens. And when it does, it only means that in three years it will be seen as âthat scary legacy codeâ no one dares touch with a ten foot pole because they have no idea how it works.
Thanks alot, Justin! đđ
Add tests & linters, choose a style guide to follow, use Husky to add git hooks and it will check your code before every commits/pushes.
I do this even if the project is small to get good at making the code cleaner every time I touch it. In Javascript world things changed rapidly, I make sure to be ready for any changes with high test coverage & clean codebase. I have no fear if I replace Redux with Recoil (or replace all JS with TS) if my tests still passes, for instance. I like to see the project "grow" with me, as a developer :)
If you have been using create-react-app, you should have a look at Next.js or GatsbyJS. Both are used in production by companies. While learning them, you will write more server-side code which can help you gain exposure. You will also learn more about performance since it is what those frameworks optimize for.
To learn more about best practices, thanks to the internet we now have different ways to access the wisdom of other devs. Here are some of my favorites:
Building side projects is the best way to get a job. They can be a Codepen, hosted website, or coursework(check out Wes's courses above). You mentioned you have "built a number of projects with React that just work fine". Showcase them in your resume and I am sure you can find a junior web developer job. Look for a position that uses modern stacks and has a good team that you can learn from.
Regarding TypeScript, my suggestion is don't sweat it. Yes, there are companies that use TypeScript and I like it myself. But I am sure you can find a job that doesn't use TypeScript or doesn't require you to be a TS expert. From my personal experience, it can be frustrating to learn TypeScript and React/Nextjs/Gatsby together. Instead, you can try to use TypeScript in a side project with a framework that you are already familiar with, such as CRA. For your future reference, React TypeScript Cheatsheets will be helpful.
We all have our time of confusion. The important thing is we are making progress towards our goals. đ»
This a super comment, useful links there. Thanks alot!
You are welcome. I turned it into a post to include more resources. Hope it helps. Cheers!
Hello! Well, I think knowing TypeScript is in huge demand everywhere, not only with React, so it could be definitely worth it if you made the transition into it. I've seen a lot of posts here in Dev about how to start using TypeScript in React, I would look into one of those. Not really related to "design patterns" or anything but I'm just curious, are you working with vanilla React? (I.e.: Create React App)? Because if you are, learning React based frameworks like Gatsby or Next.js (particularly Next) could be a good next step for you as a React dev. Other than keeping the code clean, using frameworks like Next.js allows you to build production ready React apps with neat features like code splitting, static generated pages, server side rendering, etc, that overall improve the performance of your apps. It even helps with SEO (which by the way is awful in vanilla React). Knowing how to use Next (or even Gatsby if you want) could improve your changes on landing a React job. Good luck!
Alright Johnny, thanks a lot, will surely look into learning those. Thank you.
There is no magic bullet.
Learning is driven by surprise, failure, and practice.
Take the time to understand what surprises you properly and deeply enough that it won't surprise you again.
Take the time to understand the root causes of your failures. This will generally not be obvious to you (because if it were obvious, you wouldn't have failed that way).
Take care to practice doing things right -- if you practice doing things wrong, you'll get better at ... doing things wrong.
Now go out, fail in surprising ways frequently, practice being right, and be fruitful. :)
Hi Sandeep
This means you are on the right path! You understand that the code needs to be clean in order to add features.
Now, how to code to avoid the constant need to refactor... This is tough question indeed; unfortunately even mature projects sometimes require refactorings or even complete rewrites. And that's not always because of design mistakes: not everything may be foreseen in the beginning.
SOLID principles are certainly helpful. But keep in mind they are designed mainly for OOP which is not considered today as the only way to code. The most universal principle IMO is orthogonality: try to design different parts of application so that they don't depend on others implementation details. That's not 100% possible but can be achieved to some degree.
Helpful thing is defining boundaries between components, and that's where TypeScript shines. It allows you to clearly define API: object shapes, functions etc which are used to transfer data between components.
Keep going and good luck!
Thanks alot aleksei!!
Put together a list of projects that you want to create. Something exciting and that will challenge you. For the projects make sure that they increase in complexity so that you are forced to learn new things. And then just build!
You can even take it one step further and work on projects that solve real world problems. Make them open source and put them on GitHub.
Hey don't pick your brain to hard on this.
We had the same issue with comse clients at times. They completly wanna change the flow of a system and it means refactoring the whole system. It is normal and this is why you should have a strong testing pipeline to align with such consequential changes.
One thing tho think about when building an APP (regardless of language) is to think scalability. Take a simple notification system you could do it very easily as a json payload but then what. What if in the future you want to add an action to the notification or also add tracking of interactions (views / clicks). What if you want to add priority to notifications?
The idea is any feature asked from a client should be easily scalable this might mean that you will need to put extra work at the beginning to make it easily scalable. This is why when building an app it is also important to understand where the business is gonna go. What are their future plans to make sure that the piece you create will also be compatible for any other future dev they have planned.
Ideally you should always be thinking on how will the feature be expanded in the future.
On the note of Typescript do learn it and do use it if you can. It forces you to write much more rigorous and structured code.
Was on the fence with learning typescript, now its clear typescript is the way to go. Thank you.
Hi Sandeep. Some actionable advice, I hope
I think the best way to go about doing this is to collaborate with others and work on some open-source project. When you do hobby projects, you learn the framework/language. You would also pick up some design patterns, but you learn 10x when you work with "veterans" on production grade projects. These you learn though code reviews, discussions on issues etc.
I recently came across Typescript website... and they have done a lot to make it collaborator friendly. There is a roadmap here: github.com/microsoft/TypeScript-We...
Look for issues labelled "You can do this" (github.com/microsoft/TypeScript-We...)
Raise a few PRs.. PRs against "You can do this" might be accepted. You will learn a lot when you make the changes, and but learn twice as much when your PR gets reviewed.
That is useful link, thank you!!
Hello. The concern you currently have is a very good one. It shows that you are interested in learning how to write better software and not just get stuff to work. That's a very healthy ambition.
One thing that helped me to learn this was building projects with folks that are more advanced than I am. I have found that one or two of these kinds of projects can help you learn a ton(literally every day of working with these senior folks).
So if you have any in your network you could do well to interact with them on this idea
Finally, I think you are very correct, TypeScript is something you need in your arsenal. However, I think solving the spaghetti issue should be of higher priority(you can do both at the same time you see)
Thanks Chidiebere, stepping up!