Patterns from Other Languages and Frameworks to Enhance Your Frontend Projects

I've been programming for twelve years and have worked with many languages. These include , , , , , and finally, . Every language or framework has its own rules. For example, uses for function names. C C++ Java Python C# JavaScript Rust snake-case However, there are certain rules, tools, and patterns that I've grown to appreciate. I incorporate these into my frontend applications. These rules just resonate with me more and make coding a smoother process. Here are a few that I particularly favor: Functional Programming My first tip comes from C, the first language I learned. Remember when we used to write ? Just thinking about it gives me chills. When React switched to functional components, it made the code not only easier to read but also easier to test. React with classes It also aligns better with the principles of Functional Programming. This approach works great with frontend frameworks because they often focus on creating reusable pieces of code. Using Functional Programming in frontend development has always been a helpful strategy for me to understand this concept and also to build new frontend features. Following Functional Programming principles is a must-have in my every frontend application. If you're not familiar with Functional Programming, I highly recommend exploring it . This point isn't at the beginning of this list without reason. The benefits it can bring to your development process are substantial. further Code Formatters When I first started programming, I didn't pay much attention to code formatting. I guess it all started at university where I was learning C++ on my cool with a white theme. CodeBlocks IDE Looking back at , I can see that I used only spaces for formatting. I didn't use any tools to automatically take care of this. my old code from 2016 on GitHub Now, I realize that was a mistake. If you can automate something in your project, you definitely should. Now, I always set up and at the start of every project. If you don't want to spend a lot of time on this, you can use pre-made configurations like the one from . Prettier ESLint Airbnb Trust me, you won't regret it! Oh and don’t forget to set up in your IDE an autoformatting on file save action! Pre-commit Actions Now that you have awesome formatters, let's automate them! I can't quite remember when I started using pre-commit hooks, but they've been a great help in my projects. Why format manually when it can be automated before every commit? Tools like and make this automation possible. husky lint-staged Kebab-case for Filenames Even though has many fans and critics, I like to focus on the positive. Angular is often the first choice for big companies and large applications. I think many of the decisions made in Angular were meant to keep things easy to maintain. Angular That's why I decided to use kebab-case for all my frontend projects. It offers a few benefits, like: : I don't have to worry about whether to use pascal-case, camel-case, or snake-case (if you prefer). With kebab-case, there's just one option. Simplicity : If you're working on a team, adopting a single naming convention like kebab-case can help ensure everyone is on the same page and the project stays organized. Don’t forget that you can force using kebab-case via eslint rule using package: Consistency unicorn 'unicorn/filename-case': [ 'error', { case: 'kebabCase', }, ], : Different operating systems handle file names differently. For example, Windows doesn't care about capitalization, but Linux does. By using kebab-case, which uses lowercase letters and hyphens, I avoid any issues. Cross-platform compatibility : There's an issue with renaming a file from lowercase to uppercase in git. Using kebab-case, I don't have to worry about it. No git issues I like to keep things simple. If I can make my life easier and get some benefits from it, I'm all for it. Using Tags for File Types Another thing I borrowed from Angular is how they name files. Angular recommends naming files in a way that reflects their function and type. I find that it makes it easier for me to navigate and understand a project's structure. In Angular, the filename usually has three parts: the feature area, the file's role, and the type of file. For example, shows that the file is a component for the feature and it's a TypeScript file. is a service for . heroes.component.ts heroes heroes.service.ts heroes I'm not a big fan of , but I use a similar structure for my React components. Here's an example: services my-component ├── my-component.component.tsx ├── my-component.type.ts ├── my-component.style.css ├── my-component.spec.tsx └── my-component.story.mdx I also use this pattern for my hooks and functions. This pattern also teach me to put my tests next to the files related to them. Automate Code Generation The pattern I mentioned before is very helpful, but we can make it even better with automation. automatically, and I always use to do the same. Plop's template system is very powerful, but most importantly, it saves time. Angular CLI lets users generate code plop With automation, I don't have to spend much time thinking about the basic structure of a component. This task can be automated, which allows me to focus on what I really want to do. Using a 'Domain' I'm not going to explain what a is in detail here. If you want to learn more about it, I recommend reading . Right now, I'm working with a team of full-stack developers, and we've found that having a layer in our frontend project is really useful. domain this article domain It's where we put all our main types and operations. It serves as the 'source of truth' in our app. If you want to see how I handle 'domains' in my apps, you can check out . I spend there a lot of time describing this topic. this article Testing Your Architecture In our work with , we once encountered a problem where logic got mixed up across multiple layers, like using a type defined in the repository inside our domain. This is a no-go from a Clean Architecture standpoint, but everyone makes mistakes. Kotlin That's when we discovered , a tool for unit testing our architecture. It basically checks if we're correctly adhering to our architecture. ArchUnit If you're maintaining a certain architecture, it can be useful to have a tool to check if it hasn't been broken at some point. A tool like can be invaluable in this regard. dependency-cruiser And that concludes my essential list of patterns from other languages and frameworks for enhancing your frontend projects. I hope you found this information helpful and that at least one of these strategies has inspired you to implement it in your own work!