Structure Your Project Standartly, Enough Classic Ways!

So, you're writing code & building projects one after another, there is the possibility that you just don't care about how you structure your projects, the thing that matters is finishing the project delivering a feature, or completing a task.

But, after a while, you left the project then came back, and boom!! You don't know what is going on (especially if the project you built is a little bit) you may spend days to reunderstand the project, which happens to almost all new developers especially self-taught ones unless you are blessed by a good mentor to clear the way you'll go through in the future.

It is now time to revamp the way you structure your project, this will show your projects stand out from those who mess up even the small-sized projects, in this blog I will discuss two approaches that are very useful and standard for you to build scalable and maintainable projects, as well as discuss avoid No-Approach way of structuring your project, but first let's understand what is the Frontend Architecture.

Frontend Architecture

Frontend architecture refers to how the code of an application is organized and structured. It outlines how different modules within the system communicate with one another, defines the interfaces of individual modules, and prescribes best practices for their development.

An effective front-end architecture is essential for maintaining a manageable and comprehensible codebase. It significantly streamlines the process of implementing new features, refactoring existing code, and preventing unexpected errors. The optimal architecture comprises modules that are loosely interconnected and closely aligned in purpose

Avoid Classical Structure Approach

If you still don't know what is the classic approach to avoid it, how it look like! actually there is no specific rules for it, if you follow youtube tutorial projects, most of them(if not all) are using that way because it is simple and easy to comeup with, it typically looks like this

There is a lot of problems with this approach, like navigating through the project becomes challenging due to poor organization, making it difficult to locate components and comprehend their relationships within the codebase. As a result, the learning curve for new developers steepens significantly, requiring an extended period to familiarize themselves with the project's intricacies. Maintenance becomes an arduous task over time, compounded by the accumulation of code complexity and the presence of unexpected bugs stemming from subpar code quality. Ultimately, these factors contribute to prolonged feature delivery timelines, impeding the project's overall progress and efficiency.

It is fine to use this approach if your project doesn't need future updates or maintenance, or simple project, otherwise there is no reason for using this appreaoch.

Modular Approach

One alternative approach or structure for the classic approach is using the module approach for your small or medium-sized project since it is easy to understand also using this will prepare you for an advanced approach for a large code basis which is FSD(we'll have a look next).

In most cases, it consists of only four parts: pages, modules, components, and UI.

• UI: This directory contains UI components like buttons, selects, and inputs.
• Components: This directory houses less independent pieces of code, such as ProductCard. However, items within this directory should not contain specific business logic to ensure high reusability.
• Modules: This directory is designated for independent modules of the application. For instance, SignInForm serves as an isolated module with its own logic and objectives.
• Pages: This directory manages the application routes.

Overall, this approach surpasses the "Classical" one, offering a more robust structure. Its benefits are evident and pronounced:

• Enhanced project navigation, simplifying the discovery of components, functions, and more.
• Clear and intuitive structure, facilitating ease of understanding.
• Reduced coupling and increased cohesion within the system.
• Improved maintenance and scalability.
• Expedited feature delivery resulting from significantly enhanced developer experience.
• Accommodation for larger developer teams, enabling seamless collaboration.

While this approach offers clear advantages, it may not be ideal for extensive and intricate projects. Managing a large volume of features and business logic can pose challenges within this architecture.

Feature Sliced Design (FSD)

Feature Sliced Design stands out as one of the most contemporary and dependable architectural paradigms crafted specifically for front-end projects. It seamlessly adapts to various business scenarios, addresses common challenges, and offers an intuitive experience for newcomers to development.

In "Feature Sliced Design," a project is structured into layers, with each layer comprising slices, and each slice containing segments. Before delving deeper into the intricacies of layers, slices, and segments, it's beneficial to first gain a broad understanding of the overall framework.

The top-level folders of "Feature Sliced Design" are referred to as "Layers," constituting the initial level of application segmentation. These layers adhere to a predefined set, some of which are optional. Currently, there are seven standardized layers:

1. Shared Layer: This encompasses reusable functionalities independent of business logic, such as UI-kit components, helpers, and loggers.
2. Entities Layer: Here reside the project-specific business entities, such as User, Payments, and Products.
3. Feature Layer: Comprising user stories and code that directly adds business value, like ChangePassword or MakePayment functionalities.
4. Widgets Layer: Housing components that amalgamate entities and features, facilitating the creation of composite elements like UserSettings or PaymentsList.
5. Pages Layer: This layer constitutes the application pages, crafted by combining entities, features, and widgets to create comprehensive user interfaces.
6. Processes Layer: Hosting complex inter-page scenarios, such as authentication and captcha functionalities.
7. App Layer: Serving as the repository for application settings, styles, and providers, exemplified by components like withAuth HOC.

Feature Sliced Design offers numerous advantages that make it a highly favorable choice. It outperforms other approaches across various aspects. Here are the main pros:

• Business and User-Centric: The architecture is structured around fulfilling business requirements and user needs effectively.
• Controlled Logic Reusability: It promotes the systematic reuse of logic, ensuring efficient utilization across different parts of the application.
• Resilience to Changes: The design maintains stability even in the face of frequent changes and refactoring, minimizing disruptions to the development process.
• Scalability: It exhibits high scalability both in terms of architectural growth and team expansion, accommodating project evolution and increased workforce seamlessly.
• Incremental Adoption: "Feature Sliced Design" allows for gradual integration and adoption, enabling teams to transition smoothly without major overhauls.
• Technology Stack Agnostic: It offers independence from specific technological stacks, allowing flexibility in choosing tools and frameworks best suited for the project.
• Standardization: The architecture promotes uniformity and consistency, facilitating ease of understanding, maintenance, and collaboration among team members.
• Comprehensive Documentation and Support: With robust documentation and a thriving community, "Feature Sliced Design" ensures accessibility to resources and assistance for developers.

Conclusion

Neglecting project structure in favor of rapid feature delivery can lead to significant challenges in the long term. Returning to a disorganized codebase can be daunting, particularly for new developers, and can hinder maintenance and scalability efforts. By adopting a modular approach or embracing the Feature Sliced Design architecture, developers can ensure their projects are scalable, maintainable, and adaptable to future changes. Prioritizing project structure not only enhances developer productivity but also improves code quality, streamlines maintenance efforts, and ultimately leads to more successful and sustainable projects.