Intro
Hello there. I’m Lukman, and I’m a Frontend Chapter Manager. In this series of articles, I want to share a bit of my experience I’ve collected for over eight years in the field.
This series of articles is just a reminder to engineers that frontend code is software too. Therefore, its code should follow the principles described a long time ago, based on the tremendous experience, code lines, projects, and still relevant. The ideas and problems from this article are not new. Experienced engineers often already follow these principles. They have a problem and start thinking about similar topics, which makes them recall these principles from their memory.
I have known these principles for seven years, but understanding how to apply them to the front end came to me just a few years ago.
Basics
SOLID, KISS, DRY/DIE would be relevant always. Today we will talk a little about SOLID, KISS, and DRY/DIE for frontend applications. So let’s remember the basics of these simple principles in short. They are simple, straightforward, and don’t require learning a lot to remember and follow.
KISS — Keep It Simple, Stupid.
DRY/DIE — Don’t Repeat Yourself/Duplication Is Evil.
SOLID is not too simple to remember like KISS and DRY:
S — The Single Responsibility Principle. A module should be responsible to one, and only one, actor.
O — The Open-Closed Principle. A software artifact should be open for extension but closed for modification.
L — The Liskov Substitution Principle. Objects of a superclass shall be replaceable with objects of its subclasses without breaking the application.
I — The Interface Segregation Principle. Make fine-grained interfaces that are client-specific.
D — The Dependency Inversion Principle. Depend on abstractions, not on concretions.
I understand that SOLID mainly applies to OOP, but it still applies well to FP. The examples below would be an app based on React.
Before the next part, I would like to ask you a few questions:
Have you been struggling with legacy code?
Or maybe have you been creating a new project thought a lot about the right way of code writing?
How to write fast and clear from the start and not generate legacy?
Looking back on the projects I worked on for the last eight years, I see many engineers and leaders forget to follow these ideas and recommendations. I understand that the causes are different and have a place to be, but I have never seen any real valid reason not to spend a bit more time and think a bit about how to write in the right way from the start or to have a plan how to clean up the codebase.
Going to the frontend
I started a new project with Create React App from a typescript template to show how to structure your code from the start. For the first example, I decided to choose a login form. This form is small and simple — header, two fields, and a button. But under the hood, it keeps a bunch of components.
I have split all the components into two different styles — stupid (stateless) and smart (stateful). Components and modules. This is not the only way — the structure of the components can be in atomic style with atoms, molecules, and organisms.
The first group of components exists only to render information and never use hooks or connections to the application store.
The second — are features in the whole or independent part of features. These components have connections to the app store. They can handle changes in the data or implement some business logic at the component’s layer. These components can use services and communicate with other data layers, etc.
For the components, I decided to use the structure where you have a file for the component code, a file for styles, a file for types, and a file for the component’s helpers. This way allows for a clear structure, less code lines in a file, and keeping only things in the files that cause only the purpose.
-
A component file keeps only things to render and/or handle data causing the component’s rendering.
-
Stylesheet file is only to keep styles in one place and not mix styling with rendering and logic.
-
Types placed separately to keep the component’s file with fever code lines and keep them separately to import as additional service information.
-
Helpers file — is a place to store functions (helpers) that do not directly concern the component’s rendering. For example, it might be data transformation or calculations. Those helpers might be reused externally but relate to the component and component logic/functioning.
To be continued…
Let’s take a break and share your thoughts.
-
What is the idea of splitting components for different files?
-
Which principles have been applied, you think?
-
What are the pros and cons of this approach?
For the next part of the article, I will read your thoughts and provide my answers.
Then I’ll describe in short the ideas of how to organize services, data store, routes, etc. Thank you for reading. Stay tuned!