This content originally appeared on Bits and Pieces - Medium and was authored by Pavel Pogosov
Learn About “Feature Sliced” Design, Its Pros And Cons
In today's world of ever-changing business requirements, it can be difficult to find an appropriate and reliable architecture to stick to. You need something that is flexible, easy to scale, maintain, and understandable, enabling new developers to get up to speed quickly.
That’s why in this article, I want to introduce you to “Feature Sliced Design”, which is one of the most modern and reliable architectures designed especially for frontend projects. It can fit almost any business conditions, solve everyday problems, and be intuitive for new developers.
This article will cover the basics of the approach and provide you with the essential knowledge to start. Of course, I will attach the link to the original docs at the end of the piece. Without any further words, let’s start!
Table Of Contents
- Architecture Overview
- Pros and Cons of the Architecture
- Comparison with the “Simple Modular” Architecture
- Want to learn more?
Architecture Overview
“Feature Sliced” design has been gaining more and more popularity among the frontend community for its undeniable benefits. It has proven to be highly scalable and reliable, making it an excellent choice for large teams working on complex projects.
The huge advantage of that approach, which helps it stands out from any other frontend architecture, is its business orientation. This makes it suitable for almost any project and makes it easy to keep things well-organized as new features are added. Moreover, it can be adopted incrementally, which is incredible news as you can implement it in an already existing product. However, keep in mind that this methodology is designed to be used only for the frontend.
In “Feature Sliced Design” a project consists of layers, each layer is made up of slices, and each slice is made up of segments. Before going deeper into the layers, slices, and segments, I suggest you take a glance at the global picture below.
Layers
Top-level folders of “Feature Sliced Design” are called “Layers” and are the first level of application partitioning. We have a strict number of possible layers and some of them are optional. Layers are standardized and at the current moment, there are seven of them:
- Shared layer. It contains various reusable, independent of business logic functionality. Perfect examples of that can be UI-kit, helpers, and loggers
- Entities layer. It contains business entities, which are specific to the project. For example User, Payments, Products, and so on
- Feature layer. It contains user stories. Code that brings business value to the user. For example ChangePassword, MakePayment, BuyProduct
- Widgets layer. It contains components that combine entities and features. For example UserSettings, PaymentsList, ProductsList
- Pages layer. It contains application pages. That is the compositional layer that is constructed from entities, features, and widgets
- Processes layer. It contains complex inter-page scenarios. For example authentication and captcha
- App layer. It contains application settings, styles, and providers. For example withAuth HOC
Each of the layers has its own zone of responsibility and as you can notice they are highly business oriented. Also, they have a stepped hierarchy, which you can see in the picture below. It is done in that way as it creates an understandable unidirectional data flow that plays a significant role in approach usability.
The lower the module is placed in the hierarchy, the more it is dangerous to refactor it. For example, if you change Modal the component in the shared layer that can hugely affect the rest of the application.
🌟 Don’t forget to subscribe to learn more important things about Frontend!
Slices
Now it’s time to talk about “Slices”. They are simply subfolders of a layer and are dependent on project specifics, team, and technology stack. Also, they are not coupled to some abstract things like layers, each slice represents a specific thing. You can understand them as modules, which have rules you should follow:
- Slices of the same layer cannot use each other directly
- Their composition should be placed on the upper layer relative to the current one
- In most cases, you should avoid nesting in slices, and use only structural grouping by folders
Here are examples of slices for each of the possible layers:
├── app/
| # Application composition layer
| # Only contains abstract initialization logic and static assets, and thus mustn't contain any Slices
|
├── processes/
| # Slices implementing page-independent workflows or workflows involving multiple pages
| ├── auth
| ├── payment
| ├── quick-tour
|
|
├── pages/
| # Slices implementing complete application views
| ├── feed
| |
| ├── profile
| | # Due to routing specifics, this layer can contain nested structures
| | ├── edit
| | └── stats
| |
| ├── sign-up
|
|
├── widgets/
| # Slices implementing various combinations of abstract and / or business units from lower layers,
| # to deliver isolated atomic User Interface fragments
| ├── chat-window
| ├── header
| ├── feed
|
|
├── features/
| # Sliced implementing user scenarios, which usually operate on business entities
| ├── auth-by-phone
| ├── create-post
| ├── write-message
|
|
├── entities/
| # Slices implementing business units in terms of which application business logic works
| ├── account
| ├── conversation
| ├── post
| ├── wallet
|
|
├── shared/
| # This layer is a set of abstract Segments
| # It means that it must not contain any business units or business-related logic
Segments
Each slice consists of smaller modules called “segments”. There are meant to help with separating code within a slice by its technical purpose. Here is a list of the most common segments, but you can be flexible and omit or add more.
- UI segment. It simply contains UI logic
- Model segment. It contains business logic, such as stores, actions, effects, and reducers
- Lib segment. It contains infrastructure logic, such as utils and helpers
- Config segment. It contains the configuration of the slice
- API segment. It contains the logic of API requests such as requests themselves or API instances.
Public API
Every “Slice” and “Segment” must have its own declaration of “Public API”. That is simply an index file that represents an access point to the module’s internals and defines how the outer world can interact with the module.
└── features/ #
├── auth-form / # Internal structure of the feature
| ├── ui/ #
| ├── model/ #
| ├── {…}/ #
| ├── index.ts # Entrypoint with its public API
As the “Public API” is the entry point for the module, here are some rules you should follow:
- Other parts of the application can use only those module entities that are presented in the public interface
- The internal part of the module outside the public interface is accessible only to the module itself
The well-declared public interface should be convenient for use by the rest of the application and be sustainable for changes inside the module, so you don’t have to change imports in plenty of places when something is modified.
Pros and Cons of the Architecture
Undoubtedly, “Feature Sliced Design” brings a ton of value to the table. It excels in almost any realm when compared to other approaches. The main pros are:
- Orientation to business and user needs
- Controlled reuse of logic
- Stability in face of changes and refactoring
- High scalability in terms of architecture and team
- Incremental adoption
- Independence of technological stack
- High standardization
- Perfect documentation and a big community
Cons:
- It adds more project knowledge from the start as you have to learn an approach to start creating value. But to be honest, it also hugely decreases project knowledge as the project broadens due to standardization
- Not suitable for MVP or short-living projects, as you increase development time and don’t get any significant benefits on short distances
- It requires special team culture and strict code review to follow all the architectural principles
Overall, “Feature Sliced Design” is a powerful approach that brings a ton of value to your project. By breaking down the application into small, modular components, we create low-coupled and highly cohesive code.
Tip: It’s worth mentioning that an open-source toolchain like Bit is an ideal tool to use in conjuction with the “Feature Sliced Design” approach. After identifying common components across your micro-frontends and isolating them, you can use Bit to manage, version, and share them across projects. This is an elegant and maintainable solution that will help both scalability and reusability, and enable better collaboration between your teams. Find out more here.
Extracting and Reusing Pre-existing Components using bit add
Comparison with the “Simple Modular” Architecture
For reference, the “Simple Modular” architecture was previously discussed in this article.
Frontend Architectures: “Simple Modular” Approach
It seems to me that for any middle/high complexity projects, you should always prefer “Feature Sliced Design” over “Simple Modular” architecture. As it really solves plenty of fundamental architectural issues almost without any cons.
In terms of simplicity and development speed, “Simple Modular” approach excels “FSD”. For MVPs and small, short-lived projects, the Simple Modular approach may be more appropriate.
If you want to learn “Feature Sliced Design” deeper, feel free to check out the official documentation.
Welcome | Feature-Sliced Design
Want to learn more?
- Frontend Architectures: “Classic” Approach (No Architecture)
- 4 React Tips to Instantly Improve Your Code
- 5 React useState Mistakes That Will Get You Fired
- React “Polymorphic Components” With TypeScript
Thanks for reading!
I hope, you found this article useful. If you have any questions or suggestions, please leave comments. Your feedback helps me to become better.
Don’t forget to subscribe⭐️
Build Apps with reusable components, just like Lego
Bit’s open-source tool help 250,000+ devs to build apps with components.
Turn any UI, feature, or page into a reusable component — and share it across your applications. It’s easier to collaborate and build faster.
Split apps into components to make app development easier, and enjoy the best experience for the workflows you want:
→ Micro-Frontends
→ Design System
→ Code-Sharing and reuse
→ Monorepo
Learn more:
- How We Build Micro Frontends
- How we Build a Component Design System
- How to reuse React components across your projects
- 5 Ways to Build a React Monorepo
- How to Create a Composable React App with Bit
Understand The Most Reliable Frontend Architecture was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Bits and Pieces - Medium and was authored by Pavel Pogosov
Pavel Pogosov | Sciencx (2023-02-25T07:02:44+00:00) Understand The Most Reliable Frontend Architecture. Retrieved from https://www.scien.cx/2023/02/25/understand-the-most-reliable-frontend-architecture/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.