Since the structure is standardized, projects become more uniform, which makes onboarding new members easier for the team. * **Stability in face of changes and refactoring**
A module on one layer cannot use other modules on the same layer, or the layers above.
This allows you to make isolated modifications without unforeseen consequences to the rest of the app. * **Controlled reuse of logic**
Depending on the layer, you can make code very reusable or very local.
This keeps a balance between following the **DRY** principle and practicality. * **Orientation to business and users needs**
The app is split into business domains and usage of the business language is encouraged in naming, so that you can do useful product work without fully understanding all other unrelated parts of the project. ## Incremental adoption[β](#incremental-adoption "Direct link to heading") If you have an existing codebase that you want to migrate to FSD, we suggest the following strategy. We found it useful in our own migration experience. 1. Start by slowly shaping up the App and Shared layers module-by-module to create a foundation. 2. Distribute all of the existing UI across Widgets and Pages using broad strokes, even if they have dependencies that violate the rules of FSD. 3. Start gradually resolving import violations and also extracting Entities and possibly even Features. It's advised to refrain from adding new large entities while refactoring or refactoring only certain parts of the project. ## Next steps[β](#next-steps "Direct link to heading") * **Want to get a good grasp of how to think in FSD?** Check out the [Tutorial](/documentation/docs/get-started/tutorial.md). * **Prefer to learn from examples?** We have a lot in the [Examples](/documentation/examples.md) section. * **Have questions?** Drop by our [Telegram chat](https://t.me/feature_sliced) and get help from the community. --- # Tutorial ## Part 1. On paper[β](#part-1-on-paper "Direct link to heading") This tutorial will examine the Real World App, also known as Conduit. Conduit is a basic [Medium](https://medium.com/) clone β it lets you read and write articles as well as comment on the articles of others.  This is a pretty small application, so we will keep it simple and avoid excessive decomposition. Itβs highly likely that the entire app will fit into just three layers: **App**, **Pages**, and **Shared**. If not, we will introduce additional layers as we go. Ready? ### Start by listing the pages[β](#start-by-listing-the-pages "Direct link to heading") If we look at the screenshot above, we can assume at least the following pages: * Home (article feed) * Sign in and sign up * Article reader * Article editor * User profile viewer * User profile editor (user settings) Every one of these pages will become its own *slice* on the Pages *layer*. Recall from the overview that slices are simply folders inside of layers and layers are simply folders with predefined names like `pages`. As such, our Pages folder will look like this: ``` π pages/ π feed/ π sign-in/ π article-read/ π article-edit/ π profile/ π settings/ ``` The key difference of Feature-Sliced Design from an unregulated code structure is that pages cannot reference each other. That is, one page cannot import code from another page. This is due to the **import rule on layers**: *A module (file) in a slice can only import other slices when they are located on layers strictly below.* In this case, a page is a slice, so modules (files) inside this page can only reference code from layers below, not from the same layer, Pages. ### Close look at the feed[β](#close-look-at-the-feed "Direct link to heading")  *Anonymous userβs perspective*  *Authenticated userβs perspective* There are three dynamic areas on the feed page: 1. Sign-in links with an indication if you are signed in 2. List of tags that triggers filtering in the feed 3. One/two feeds of articles, each article with a like button The sign-in links are a part of a header that is common to all pages, we will revisit it separately. #### List of tags[β](#list-of-tags "Direct link to heading") To build the list of tags, we need to fetch the available tags, render each tag as a chip, and store the selected tags in a client-side storage. These operations fall into categories βAPI interactionβ, βuser interfaceβ, and βstorageβ, respectively. In Feature-Sliced Design, code is separated by purpose using *segments*. Segments are folders in slices, and they can have arbitrary names that describe the purpose, but some purposes are so common that thereβs a convention for certain segment names: * πΒ `api/` for backend interactions * πΒ `ui/` for code that handles rendering and appearance * πΒ `model/` for storage and business logic * πΒ `config/` for feature flags, environment variables and other forms of configuration We will place code that fetches tags into `api`, the tag component into `ui`, and the storage interaction into `model`. #### Articles[β](#articles "Direct link to heading") Using the same grouping principles, we can decompose the feed of articles into the same three segments: * πΒ `api/`: fetch paginated articles with like count; like an article * πΒ `ui/`: * tab list that can render an extra tab if a tag is selected * individual article * functional pagination * πΒ `model/`: client-side storage of the currently loaded articles and current page (if needed) ### Reuse generic code[β](#reuse-generic-code "Direct link to heading") Most pages are very different in intent, but certain things stay the same across the entire app β for example, the UI kit that conforms to the design language, or the convention on the backend that everything is done with a REST API with the same authentication method. Since slices are meant to be isolated, code reuse is facilitated by a lower layer, **Shared**. Shared is different from other layers in the sense that it contains segments, not slices. In this way, the Shared layer can be thought of as a hybrid between a layer and a slice. Usually, the code in Shared is not planned ahead of time, but rather extracted during development, because only during development does it become clear which parts of code are actually shared. However, itβs still helpful to keep a mental note of what kind of code naturally belongs in Shared: * πΒ `ui/` β the UI kit, pure appearance, no business logic. For example, buttons, modal dialogs, form inputs. * πΒ `api/` β convenience wrappers around request making primitives (like `fetch()` on the Web) and, optionally, functions for triggering particular requests according to the backend specification. * πΒ `config/` β parsing environment variables * πΒ `i18n/` β configuration of language support * πΒ `router/` β routing primitives and route constants Those are just a few examples of segment names in Shared, but you can omit any of them or create your own. The only important thing to remember when creating new segments is that segment names should describe **purpose (the why), not essence (the what)**. Names like βcomponentsβ, βhooksβ, βmodalsβ *should not* be used because they describe what these files are, but donβt help to navigate the code inside. This requires people on the team to dig through every file in such folders and also keeps unrelated code close, which leads to broad areas of code being affected by refactoring and thus makes code review and testing harder. ### Define a strict public API[β](#define-a-strict-public-api "Direct link to heading") In the context of Feature-Sliced Design, the term *public API* refers to a slice or segment declaring what can be imported from it by other modules in the project. For example, in JavaScript that can be an `index.js` file re-exporting objects from other files in the slice. This enables freedom in refactoring code inside a slice as long as the contract with the outside world (i.e. the public API) stays the same. For the Shared layer that has no slices, itβs usually more convenient to define a separate public API for each segment as opposed to defining one single index of everything in Shared. This keeps imports from Shared naturally organized by intent. For other layers that have slices, the opposite is true β itβs usually more practical to define one index per slice and let the slice decide its own set of segments that is unknown to the outside world because other layers usually have a lot less exports. Our slices/segments will appear to each other as follows: ``` π pages/ π feed/ π index π sign-in/ π index π article-read/ π index π β¦ π shared/ π ui/ π index π api/ π index π β¦ ``` Whatever is inside folders like `pages/feed` or `shared/ui` is only known to those folders, and other files should not rely on the internal structure of these folders. ### Large reused blocks in the UI[β](#large-reused-blocks-in-the-ui "Direct link to heading") Earlier we made a note to revisit the header that appears on every page. Rebuilding it from scratch on every page would be impractical, so itβs only natural to want to reuse it. We already have Shared to facilitate code reuse, however, thereβs a caveat to putting large blocks of UI in Shared β the Shared layer is not supposed to know about any of the layers above. Between Shared and Pages there are three other layers: Entities, Features, and Widgets. Some projects may have something in those layers that they need in a large reusable block, and that means we canβt put that reusable block in Shared, or else it would be importing from upper layers, which is prohibited. Thatβs where the Widgets layer comes in. It is located above Shared, Entities, and Features, so it can use them all. In our case, the header is very simple β itβs a static logo and top-level navigation. The navigation needs to make a request to the API to determine if the user is currently logged in or not, but that can be handled by a simple import from the `api` segment. Therefore, we will keep our header in Shared. ### Close look at a page with a form[β](#close-look-at-a-page-with-a-form "Direct link to heading") Letβs also examine a page thatβs intended for editing, not reading. For example, the article writer:  It looks trivial, but contains several aspects of application development that we havenβt explored yet β form validation, error states, and data persistence. If we were to build this page, we would grab some inputs and buttons from Shared and put together a form in the `ui` segment of this page. Then, in the `api` segment, we would define a mutation request to create the article on the backend. To validate the request before sending, we need a validation schema, and a good place for it is the `model` segment, since itβs the data model. There we will produce error messages and display them using another component in the `ui` segment. To improve user experience, we could also persist the inputs to prevent accidental data loss. This is also a job of the `model` segment. ### Summary[β](#summary "Direct link to heading") We have examined several pages and outlined a preliminary structure for our application: 1. Shared layer 1. `ui` will contain our reusable UI kit 2. `api` will contain our primitive interactions with the backend 3. The rest will be arranged on demand 2. Pages layer β each page is a separate slice 1. `ui` will contain the page itself and all of its parts 2. `api` will contain more specialized data fetching, using `shared/api` 3. `model` might contain client-side storage of the data that we will display Letβs get building! ## Part 2. In code[β](#part-2-in-code "Direct link to heading") Now that we have a plan, letβs put it to practice. We will use React and [Remix](https://remix.run). There's a template ready for this project, clone it from GitHub to get a headstart:
conduit
A place to share your knowledge.
{article.author.username}
{new Date(article.createdAt).toLocaleDateString(undefined, {
dateStyle: "long",
})}
{article.title}
{article.description}
Read more...-
{article.tagList.map((tag) => (
- {tag} ))}
conduit
A place to share your knowledge.
{articles.articles.map((article) => (
conduit
A place to share your knowledge.
{articles.articles.map((article) => (
Popular Tags
conduit
A place to share your knowledge.
{articles.articles.map((article) => (
Popular Tags
Sign up
Have an account?
{registerData?.error && (-
{registerData.error.errors.body.map((error) => (
- {error} ))}
Sign in
Need an account?
{signInData?.error && (-
{signInData.error.errors.body.map((error) => (
- {error} ))}
Popular Tags
conduit
A place to share your knowledge.
{article.author.username}
{new Date(article.createdAt).toLocaleDateString(undefined, {
dateStyle: "long",
})}
{article.title}
{article.description}
Read more...-
{article.tagList.map((tag) => (
- {tag} ))}
{article.article.title}
{article.article.body}
-
{article.article.tagList.map((tag) => (
- {tag} ))}
{currentUser !== null ? (
) : (
)}
{comments.comments.map((comment) => (
{comment.author.username}
{comment.createdAt}
{comment.author.username === currentUser?.username && (
)}
))}
);
}
```
And with that our article reader is also complete! The buttons to follow the author, like a post, and leave a comment should now function as expected.
Article reader with functioning buttons to like and follow
### Article editor[β](#article-editor "Direct link to heading")
This is the last page that we will cover in this tutorial, and the most interesting part here is how weβre going to validate form data.
The page itself, `article-edit/ui/ArticleEditPage.tsx`, will be quite simple, extra complexity stowed away into two other components:
pages/article-edit/ui/ArticleEditPage.tsx
```
import { Form, useLoaderData } from "@remix-run/react";
import type { loader } from "../api/loader";
import { TagsInput } from "./TagsInput";
import { FormErrors } from "./FormErrors";
export function ArticleEditPage() {
const article = useLoaderDataSign in or Sign up to add comments on this article.
{comment.body}
-
{actionData.errors.map((error) => (
- {error} ))}
{tagListState.map((tag) => (
[" ", "Enter"].includes(e.key) && removeTag(tag)
}
onClick={() => removeTag(tag)}
>{" "}
{tag}
))}
);
}
```
Now, for the API part. The loader should look at the URL, and if it contains an article slug, that means weβre editing an existing article, and its data should be loaded. Otherwise, return nothing. Letβs create that loader:
pages/article-edit/api/loader.ts
```
import { json, type LoaderFunctionArgs } from "@remix-run/node";
import type { FetchResponse } from "openapi-fetch";
import { GET, requireUser } from "shared/api";
async function throwAnyErrorsThis is the simplest solution, but it quickly becomes cumbersome, and if you don't have type safety, it's easy to forget. It's also not compatible with middlewares pattern for the API client in Shared. 2. **Expose the token to the entire app with a context or a global store like `localStorage`**
The key to retrieve the token will be kept in `shared/api` so that the API client can access it. The reactive store of the token will be exported from the User entity, and the context provider (if needed) will be set up on the App layer. This gives more freedom for designing the API client, however, this creates an implicit dependency on higher layers to provide context. When following this approach, consider providing helpful error messages if the context or `localStorage` are not set up correctly. 3. **Inject the token into the API client every time it changes**
If your store is reactive, you can create a subscription that will update the API client's token store every time the store in the entity changes. This is similar to the previous solution in that they both create an implicit dependency on higher layers, but this one is more imperative ("push"), while the previous one is more declarative ("pull"). Once you overcome the challenge of exposing the token that is stored in the entity's model, you can encode more business logic related to token management. For example, the `model` segment can contain logic to invalidate the token after a certain period of time, or to refresh the token when it expires. To actually make requests to the backend, use the `api` segment of the User entity or `shared/api`. ### In Pages/Widgets (not recommended)[β](#in-pageswidgets-not-recommended "Direct link to heading") It is discouraged to store app-wide state like an access token in pages or widgets. Avoid placing your token store in the `model` segment of the login page, instead choose from the first two solutions, Shared or Entities. ## Logout and token invalidation[β](#logout-and-token-invalidation "Direct link to heading") Usually, apps don't have an entire page for logging out, but the logout functionality is still very important. It consists of an authenticated request to the backend and an update to the token store. If you store all your requests in `shared/api`, keep the logout request function there, close to the login function. Otherwise, consider keeping the logout request function next to the button that triggers it. For example, if you have a header widget that appears on every page and contains the logout link, put that request in the `api` segment of that widget. The update to the token store will have to be triggered from the place of the logout button, like a header widget. You can combine the request and the store update in the `model` segment of that widget. ### Automatic logout[β](#automatic-logout "Direct link to heading") Don't forget to build failsafes for when a request to log out fails, or a request to refresh a login token fails. In both of these cases, you should clear the token store. If you keep your token in Entities, this code can be placed in the `model` segment as it is pure business logic. If you keep your token in Shared, placing this logic in `shared/api` might bloat the segment and dilute its purpose. If you're noticing that your API segment contains two several unrelated things, consider splitting out the token management logic into another segment, for example, `shared/auth`. --- # Autocomplete WIP The article is in the process of writing To bring the release of the article closer, you can: * π’ Share your feedback [at article (comment/emoji-reaction)](https://github.com/feature-sliced/documentation/issues/170) * π¬ Collect the relevant [material on the topic from chat](https://t.me/feature_sliced) * βοΈ Contribute [in any other way](https://github.com/feature-sliced/documentation/blob/master/CONTRIBUTING.md)
*π° Stay tuned!* > About decomposition by layers ## See also[β](#see-also "Direct link to heading") * [(Discussion) About the application of the methodology for the selection with loaded dictionaries](https://github.com/feature-sliced/documentation/discussions/65#discussioncomment-480807) --- # Browser API WIP The article is in the process of writing To bring the release of the article closer, you can: * π’ Share your feedback [at article (comment/emoji-reaction)](https://github.com/feature-sliced/documentation/issues/197) * π¬ Collect the relevant [material on the topic from chat](https://t.me/feature_sliced) * βοΈ Contribute [in any other way](https://github.com/feature-sliced/documentation/blob/master/CONTRIBUTING.md)
*π° Stay tuned!* > About working with the Browser API: localStorage, audio Api, bluetooth API, etc. > > You can ask about the idea in more detail [@alex\_novi](https://t.me/alex_novich) --- # CMS WIP The article is in the process of writing To bring the release of the article closer, you can: * π’ Share your feedback [at article (comment/emoji-reaction)](https://github.com/feature-sliced/documentation/issues/172) * π¬ Collect the relevant [material on the topic from chat](https://t.me/feature_sliced) * βοΈ Contribute [in any other way](https://github.com/feature-sliced/documentation/blob/master/CONTRIBUTING.md)
*π° Stay tuned!* ## Features may be different[β](#features-may-be-different "Direct link to heading") In some projects, all the functionality is concentrated in data from the server >
*π° Stay tuned!* > Errors, Alerts, Notifications, ... --- # i18n WIP The article is in the process of writing To bring the release of the article closer, you can: * π’ Share your feedback [at article (comment/emoji-reaction)](https://github.com/feature-sliced/documentation/issues/171) * π¬ Collect the relevant [material on the topic from chat](https://t.me/feature_sliced) * βοΈ Contribute [in any other way](https://github.com/feature-sliced/documentation/blob/master/CONTRIBUTING.md)
*π° Stay tuned!* ## Where to place it? How to work with this?[β](#where-to-place-it-how-to-work-with-this "Direct link to heading") *
*π° Stay tuned!* > About ways to initialize metrics in the application --- # Monorepositories WIP The article is in the process of writing To bring the release of the article closer, you can: * π’ Share your feedback [at article (comment/emoji-reaction)](https://github.com/feature-sliced/documentation/issues/221) * π¬ Collect the relevant [material on the topic from chat](https://t.me/feature_sliced) * βοΈ Contribute [in any other way](https://github.com/feature-sliced/documentation/blob/master/CONTRIBUTING.md)
*π° Stay tuned!* > About applicability for mono repositories, about bff, about microapps ## See also[β](#see-also "Direct link to heading") * [(Discussion) About mono repositories and plug-ins-packages](https://github.com/feature-sliced/documentation/discussions/50) * [(Thread) About the application for a mono repository](https://t.me/feature_sliced/2412) --- # Page layouts This guide examines the abstraction of a *page layout* β when several pages share the same overall structure, and differ only in the main content. info Is your question not covered by this guide? Post your question by leaving feedback on this article (blue button on the right) and we will consider expanding this guide! ## Simple layout[β](#simple-layout "Direct link to heading") The simplest layout can be seen on this page. It has a header with site navigation, two sidebars, and a footer with external links. There is no complicated business logic, and the only dynamic parts are sidebars and the switchers on the right side of the header. Such a layout can be placed entirely in `shared/ui` or in `app/layouts`, with props filling in the content for the sidebars: shared/ui/layout/Layout.tsx ``` import { Link, Outlet } from "react-router-dom"; import { useThemeSwitcher } from "./useThemeSwitcher"; export function Layout({ siblingPages, headings }) { const [theme, toggleTheme] = useThemeSwitcher(); return (
This is great for routers that support nesting, because you can group certain routes and apply the layout only to them. 2. **Just copy-paste it**
The urge to abstract code is often very overrated. It is especially the case for layouts, which rarely change. At some point, if one of these pages will need to change, you can simply do the change without needlessly affecting other pages. If you're worried that someone might forget to update the other pages, you can always leave a comment that describes the relationship between the pages. If none of the above are applicable, there are two solutions to include a widget in the layout: 1. **Use render props or slots**
Most frameworks allow you to pass a piece of UI externally. In React, it's called [render props](https://www.patterns.dev/react/render-props-pattern/), in Vue it's called [slots](https://vuejs.org/guide/components/slots). 2. **Move the layout to the App layer**
You can also store your layout on the App layer, for example, in `app/layouts`, and compose any widgets you want. ## Further reading[β](#further-reading "Direct link to heading") * There's an example of how to build a layout with authentication with React and Remix (equivalent to React Router) in the [tutorial](/documentation/docs/get-started/tutorial.md). --- # Desktop/Touch platforms WIP The article is in the process of writing To bring the release of the article closer, you can: * π’ Share your feedback [at article (comment/emoji-reaction)](https://github.com/feature-sliced/documentation/issues/198) * π¬ Collect the relevant [material on the topic from chat](https://t.me/feature_sliced) * βοΈ Contribute [in any other way](https://github.com/feature-sliced/documentation/blob/master/CONTRIBUTING.md)
*π° Stay tuned!* > About the application of the methodology for desktop/touch --- # SSR WIP The article is in the process of writing To bring the release of the article closer, you can: * π’ Share your feedback [at article (comment/emoji-reaction)](https://github.com/feature-sliced/documentation/issues/173) * π¬ Collect the relevant [material on the topic from chat](https://t.me/feature_sliced) * βοΈ Contribute [in any other way](https://github.com/feature-sliced/documentation/blob/master/CONTRIBUTING.md)
*π° Stay tuned!* > About the implementation of SSR using the methodology --- # Theme WIP The article is in the process of writing To bring the release of the article closer, you can: * π’ Share your feedback [at article (comment/emoji-reaction)](https://github.com/feature-sliced/documentation/issues/207) * π¬ Collect the relevant [material on the topic from chat](https://t.me/feature_sliced) * βοΈ Contribute [in any other way](https://github.com/feature-sliced/documentation/blob/master/CONTRIBUTING.md)
*π° Stay tuned!* ## Where should I put my work with the theme and palette?[β](#where-should-i-put-my-work-with-the-theme-and-palette "Direct link to heading") >
You can make your types accept type arguments as slots for connections with other entities, and even impose constraints on those slots. For example: entities/song/model/song.ts ``` interface Song
To make cross-imports between entities in FSD, you can use a special public API specifically for each slice that will be cross-importing. For example, if we have entities `song`, `artist`, and `playlist`, and the latter two need to reference `song`, we can make two special public APIs for both of them in the `song` entity with the `@x` notation: * π entities * π song * π @x * π artist.ts (a public API for the `artist` entity to import from) * π playlist.ts (a public API for the `playlist` entity to import from) * π index.ts (regular public API) The contents of a file `π entities/song/@x/artist.ts` are similar to `π entities/song/index.ts`: entities/song/@x/artist.ts ``` export type { Song } from "../model/song.ts"; ``` Then the `π entities/artist/model/artist.ts` can import `Song` like this: entities/artist/model/artist.ts ``` import type { Song } from "entities/song/@x/artist"; export interface Artist { name: string; songs: Array
*π° Stay tuned!* > Figma, brand uikit, templates, adaptability to brands ## See also[β](#see-also "Direct link to heading") * [(Thread) About the application for white-labels (branded) projects](https://t.me/feature_sliced/1543) * [(Presentation) About white-labels apps and design](http://yadi.sk/i/5IdhzsWrpO3v4Q) --- # Cross-imports WIP The article is in the process of writing To bring the release of the article closer, you can: * π’ Share your feedback [at article (comment/emoji-reaction)](https://github.com/feature-sliced/documentation/issues/220) * π¬ Collect the relevant [material on the topic from chat](https://t.me/feature_sliced) * βοΈ Contribute [in any other way](https://github.com/feature-sliced/documentation/blob/master/CONTRIBUTING.md)
*π° Stay tuned!* > Cross-imports appear when the layer or abstraction begins to take too much responsibility than it should. That is why the methodology identifies new layers that allow you to uncouple these cross-imports ## See also[β](#see-also "Direct link to heading") * [(Thread) About the supposed inevitability of cross-ports](https://t.me/feature_sliced/4515) * [(Thread) About resolving cross-ports in entities](https://t.me/feature_sliced/3678) * [(Thread) About cross-imports and responsibility](https://t.me/feature_sliced/3287) * [(Thread) About imports between segments](https://t.me/feature_sliced/4021) * [(Thread) About cross-imports inside shared](https://t.me/feature_sliced/3618) --- # Desegemented WIP The article is in the process of writing To bring the release of the article closer, you can: * π’ Share your feedback [at article (comment/emoji-reaction)](https://github.com/feature-sliced/documentation/issues/148) * π¬ Collect the relevant [material on the topic from chat](https://t.me/feature_sliced) * βοΈ Contribute [in any other way](https://github.com/feature-sliced/documentation/blob/master/CONTRIBUTING.md)
*π° Stay tuned!* ## Situation[β](#situation "Direct link to heading") Very often, there is a situation on projects when modules related to a specific domain from the subject area are unnecessarily desegmented and scattered around the project ``` βββ components/ | βββ DeliveryCard | βββ DeliveryChoice | βββ RegionSelect | βββ UserAvatar βββ actions/ | βββ delivery.js | βββ region.js | βββ user.js βββ epics/ | βββ delivery.js | βββ region.js | βββ user.js βββ constants/ | βββ delivery.js | βββ region.js | βββ user.js βββ helpers/ | βββ delivery.js | βββ region.js | βββ user.js βββ entities/ | βββ delivery/ | | βββ getters.js | | βββ selectors.js | βββ region/ | βββ user/ ``` ## Problem[β](#problem "Direct link to heading") The problem manifests itself at least in violation of the principle of \* \* High Cohesion\*\* and excessive stretching \* \* of the axis of changes\*\* ## If you ignore it[β](#if-you-ignore-it "Direct link to heading") * If necessary, touch on the logic, for example, delivery - we will have to keep in mind that it lies in several places and touch on several places in the code-which unnecessarily stretches our \* \* Axis of changes\*\* * If we need to study the logic of the user, we will have to go through the whole project to study in detail \* \* actions, epics, constants, entities, components\*\* - instead of it lying in one place * Implicit connections and the uncontrollability of a growing subject area * With this approach, the eye is very often blurred and you may not notice how we "create constants for the sake of constants", creating a dump in the corresponding project directory ## Solution[β](#solution "Direct link to heading") Place all modules related to a specific domain/user case - directly next to each other So that when studying a particular module, all its components lie side by side, and are not scattered around the project > It also increases the discoverability and clarity of the code base and the relationships between modules ``` - βββ components/ - | βββ DeliveryCard - | βββ DeliveryChoice - | βββ RegionSelect - | βββ UserAvatar - βββ actions/ - | βββ delivery.js - | βββ region.js - | βββ user.js - βββ epics/{...} - βββ constants/{...} - βββ helpers/{...} βββ entities/ | βββ delivery/ + | | βββ ui/ # ~ components/ + | | | βββ card.js + | | | βββ choice.js + | | βββ model/ + | | | βββ actions.js + | | | βββ constants.js + | | | βββ epics.js + | | | βββ getters.js + | | | βββ selectors.js + | | βββ lib/ # ~ helpers | βββ region/ | βββ user/ ``` ## See also[β](#see-also "Direct link to heading") * [(Article) About Low Coupling and High Cohesion clearly](https://enterprisecraftsmanship.com/posts/cohesion-coupling-difference/) * [(Article) Low Coupling and High Cohesion. The Law of Demeter](https://medium.com/german-gorelkin/low-coupling-high-cohesion-d36369fb1be9) --- # Routing WIP The article is in the process of writing To bring the release of the article closer, you can: * π’ Share your feedback [at article (comment/emoji-reaction)](https://github.com/feature-sliced/documentation/issues/169) * π¬ Collect the relevant [material on the topic from chat](https://t.me/feature_sliced) * βοΈ Contribute [in any other way](https://github.com/feature-sliced/documentation/blob/master/CONTRIBUTING.md)
*π° Stay tuned!* ## Situation[β](#situation "Direct link to heading") Urls to pages are hardcoded in the layers below pages entities/post/card ```
Click on the blue arrow to open the folder. π src * π actions * π product * π order * π api * π components * π containers * π constants * π i18n * π modules * π helpers * π routes * π products.jsx * π products.\[id].jsx * π utils * π reducers * π selectors * π styles * π App.jsx * π index.js ## Before you start[β](#before-you-start "Direct link to heading") The most important question to ask your team when considering to switch to Feature-Sliced Design is β *do you really need it?* We love Feature-Sliced Design, but even we recognize that some projects are perfectly fine without it. Here are some reasons to consider making the switch: 1. New team members are complaining that it's hard to get to a productive level 2. Making modifications to one part of the code **often** causes another unrelated part to break 3. Adding new functionality is difficult due to the sheer amount of things you need to think about **Avoid switching to FSD against the will of your teammates**, even if you are the lead.
First, convince your teammates that the benefits outweigh the cost of migration and the cost of learning a new architecture instead of the established one. Also keep in mind that any kind of architectural changes are not immediately observable to the management. Make sure they are on board with the switch before starting and explain to them why it might benefit the project. tip If you need help convincing the project manager that FSD is beneficial, consider some of these points: 1. Migration to FSD can happen incrementally, so it will not halt the development of new features 2. A good architecture can significantly decrease the time that a new developer needs to get productive 3. FSD is a documented architecture, so the team doesn't have to continuously spend time on maintaining their own documentation *** If you made the decision to start migrating, then the first thing you want to do is to set up an alias for `π src`. It will be helpful later to refer to top-level folders. We will consider `@` as an alias for `./src` for the rest of this guide. ## Step 1. Divide the code by pages[β](#divide-code-by-pages "Direct link to heading") Most custom architectures already have a division by pages, however small or large in logic. If you already have `π pages`, you may skip this step. If you only have `π routes`, create `π pages` and try to move as much component code from `π routes` as possible. Ideally, you would have a tiny route and a larger page. As you're moving code, create a folder for each page and add an index file: note For now, it's okay if your pages reference each other. You can tackle that later, but for now, focus on establishing a prominent division by pages. Route file: src/routes/products.\[id].js ``` export { ProductPage as default } from "@/pages/product" ``` Page index file: src/pages/product/index.js ``` export { ProductPage } from "./ProductPage.jsx" ``` Page component file: src/pages/product/ProductPage.jsx ``` export function ProductPage(props) { return ; } ``` ## Step 2. Separate everything else from the pages[β](#separate-everything-else-from-pages "Direct link to heading") Create a folder `π src/shared` and move everything that doesn't import from `π pages` or `π routes` there. Create a folder `π src/app` and move everything that does import the pages or routes there, including the routes themselves. Remember that the Shared layer doesn't have slices, so it's fine if segments import from each other. You should end up with a file structure like this: π src * π app * π routes * π products.jsx * π products.\[id].jsx * π App.jsx * π index.js * π pages * π product * π ui * π ProductPage.jsx * π index.js * π catalog * π shared * π actions * π api * π components * π containers * π constants * π i18n * π modules * π helpers * π utils * π reducers * π selectors * π styles ## Step 3. Tackle cross-imports between pages[β](#tackle-cross-imports-between-pages "Direct link to heading") Find all instances where one page is importing from the other and do one of the two things: 1. Copy-paste the imported code into the depending page to remove the dependency 2. Move the code to a proper segment in Shared: * if it's a part of the UI kit, move it to `π shared/ui`; * if it's a configuration constant, move it to `π shared/config`; * if it's a backend interaction, move it to `π shared/api`. note **Copy-pasting isn't architecturally wrong**, in fact, sometimes it may be more correct to duplicate than to abstract into a new reusable module. The reason is that sometimes the shared parts of pages start drifting apart, and you don't want dependencies getting in your way in these cases. However, there is still sense in the DRY ("don't repeat yourself") principle, so make sure you're not copy-pasting business logic. Otherwise you will need to remember to fix bugs in several places at once. ## Step 4. Unpack the Shared layer[β](#unpack-shared-layer "Direct link to heading") You might have a lot of stuff in the Shared layer on this step, and you generally want to avoid that. The reason is that the Shared layer may be a dependency for any other layer in your codebase, so making changes to that code is automatically more prone to unintended consequences. Find all the objects that are only used on one page and move it to the slice of that page. And yes, *that applies to actions, reducers, and selectors, too*. There is no benefit in grouping all actions together, but there is benefit in colocating relevant actions close to their usage. You should end up with a file structure like this: π src * π app (unchanged) * π pages * π product * π actions * π reducers * π selectors * π ui * π Component.jsx * π Container.jsx * π ProductPage.jsx * π index.js * π catalog * π shared (only objects that are reused) * π actions * π api * π components * π containers * π constants * π i18n * π modules * π helpers * π utils * π reducers * π selectors * π styles ## Step 5. Organize code by technical purpose[β](#organize-by-technical-purpose "Direct link to heading") In FSD, division by technical purpose is done with *segments*. There are a few common ones: * `ui` β everything related to UI display: UI components, date formatters, styles, etc. * `api` β backend interactions: request functions, data types, mappers, etc. * `model` β the data model: schemas, interfaces, stores, and business logic. * `lib` β library code that other modules on this slice need. * `config` β configuration files and feature flags. You can create your own segments, too, if you need. Make sure not to create segments that group code by what it is, like `components`, `actions`, `types`, `utils`. Instead, group the code by what it's for. Reorganize your pages to separate code by segments. You should already have a `ui` segment, now it's time to create other segments, like `model` for your actions, reducers, and selectors, or `api` for your thunks and mutations. Also reorganize the Shared layer to remove these folders: * `π components`, `π containers` β most of it should become `π shared/ui`; * `π helpers`, `π utils` β if there are some reused helpers left, group them together by function, like dates or type conversions, and move theses groups to `π shared/lib`; * `π constants` β again, group by function and move to `π shared/config`. ## Optional steps[β](#optional-steps "Direct link to heading") ### Step 6. Form entities/features from Redux slices that are used on several pages[β](#form-entities-features-from-redux "Direct link to heading") Usually, these reused Redux slices will describe something relevant to the business, for example, products or users, so these can be moved to the Entities layer, one entity per one folder. If the Redux slice is related to an action that your users want to do in your app, like comments, then you can move it to the Features layer. Entities and features are meant to be independent from each other. If your business domain contains inherent connections between entities, refer to the [guide on business entities](/documentation/docs/guides/examples/types.md#business-entities-and-their-cross-references) for advice on how to organize these connections. The API functions related to these slices can stay in `π shared/api`. ### Step 7. Refactor your modules[β](#refactor-your-modules "Direct link to heading") The `π modules` folder is commonly used for business logic, so it's already pretty similar in nature to the Features layer from FSD. Some modules might also be describe large chunks of the UI, like an app header. In that case, you should migrate them to the Widgets layer. ### Step 8. Form a clean UI foundation in `shared/ui`[β](#form-clean-ui-foundation "Direct link to heading") `π shared/ui` should ideally contain a set of UI elements that don't have any business logic encoded in them. They should also be highly reusable. Refactor the UI components that used to be in `π components` and `π containers` to separate out the business logic. Move that business logic to the higher layers. If it's not used in too many places, you could even consider copy-pasting. ## See also[β](#see-also "Direct link to heading") * [(Talk in Russian) Ilya Klimov β ΠΡΡΡΠΈΠ½ΡΠ΅ Π±Π΅Π³Π° Π±Π΅ΡΠΊΠΎΠ½Π΅ΡΠ½ΠΎΠ³ΠΎ ΡΠ΅ΡΠ°ΠΊΡΠΎΡΠΈΠ½Π³Π°: ΠΊΠ°ΠΊ Π½Π΅ Π΄Π°ΡΡ ΡΠ΅Ρ Π½ΠΈΡΠ΅ΡΠΊΠΎΠΌΡ Π΄ΠΎΠ»Π³Ρ ΡΠ±ΠΈΡΡ ΠΌΠΎΡΠΈΠ²Π°ΡΠΈΡ ΠΈ ΠΏΡΠΎΠ΄ΡΠΊΡ](https://youtu.be/aOiJ3k2UvO4) --- # Migration from v1 to v2 ## Why v2?[β](#why-v2 "Direct link to heading") The original concept of **feature-slices** [was announced](https://t.me/feature_slices) in 2018. Since then, many transformations of the methodology have taken place, but at the same time **[the basic principles were preserved](https://feature-sliced.github.io/featureslices.dev/v1.0.html)**: * Using a *standardized* frontend project structure * Splitting the application in the first place-according to *business logic* * Use of *isolated features* to prevent implicit side effects and cyclic dependencies * Using the *Public API* with a ban on climbing "into the insides" of the module At the same time, in the previous version of the methodology, there were still **weak points** that * Sometimes it leads to boilerplate code * Sometimes it leads to excessive complication of the code base and non-obvious rules between abstractions * Sometimes it leads to implicit architectural solutions, which prevented the project from being pulled up and new people from onboarding The new version of the methodology ([v2](https://github.com/feature-sliced/documentation)) is designed **to eliminate these shortcomings, while preserving the existing advantages** of the approach. Since 2018, [has also developed](https://github.com/kof/feature-driven-architecture/issues) another similar methodology - [**feature-driven**](https://github.com/feature-sliced/documentation/tree/rc/feature-driven), which was first announced by [Oleg Isonen](https://github.com/kof). After merging of the two approaches, we have **improved and refined existing practices** - towards greater flexibility, clarity and efficiency in application. > As a result, this has even affected the name of the methodology - *"feature-slice**d**"* ## Why does it make sense to migrate the project to v2?[β](#why-does-it-make-sense-to-migrate-the-project-to-v2 "Direct link to heading") > `WIP:` The current version of the methodology is under development and some details *may change* #### π More transparent and simple architecture[β](#-more-transparent-and-simple-architecture "Direct link to heading") The methodology (v2) offers **more intuitive and more common abstractions and ways of separating logic among developers.** All this has an extremely positive effect on attracting new people, as well as studying the current state of the project, and distributing the business logic of the application. #### π¦ More flexible and honest modularity[β](#-more-flexible-and-honest-modularity "Direct link to heading") The methodology (v2) allows **to distribute logic in a more flexible way:** * With the ability to refactor isolated parts from scratch * With the ability to rely on the same abstractions, but without unnecessary interweaving of dependencies * With simpler requirements for the location of the new module *(layer => slice => segment)* #### π More specifications, plans, community[β](#-more-specifications-plans-community "Direct link to heading") At the moment, the `core-team` is actively working on the latest (v2) version of the methodology So it is for her: * there will be more described cases / problems * there will be more guides on the application * there will be more real examples * in general, there will be more documentation for onboarding new people and studying the concepts of the methodology * the toolkit will be developed in the future to comply with the concepts and conventions on architecture > Of course, there will be user support for the first version as well - but the latest version is still a priority for us > > In the future, with the next major updates, you will still have access to the current version (v2) of the methodology, **without risks for your teams and projects** ## Changelog[β](#changelog "Direct link to heading") ### `BREAKING` Layers[β](#breaking-layers "Direct link to heading") Now the methodology assumes explicit allocation of layers at the top level * `/app` > `/processes` > **`/pages`** > **`/features`** > `/entities` > `/shared` * *That is, not everything is now treated as features/pages* * This approach allows you to [explicitly set rules for layers](https://t.me/atomicdesign/18708): * The **higher the layer** of the module is located , the more **context** it has *(in other words-each module of the layer - can import only the modules of the underlying layers, but not higher)* * The **lower the layer of the** module is located , the more **danger and responsibility** to make changes to it *(because it is usually the underlying layers that are more overused)* ### `BREAKING` Shared[β](#breaking-shared "Direct link to heading") The infrastructure abstractions `/ui`, `/lib`, `/api`, which used to lie in the src root of the project, are now separated by a separate directory `/src/shared` * `shared/ui` - Still the same general uikit of the application (optional) * *At the same time, no one forbids using `Atomic Design` here as before* * `shared/lib` - A set of auxiliary libraries for implementing logic * *Still - without a dump of helpers* * `shared/api` - A common entry point for accessing the API * *Can also be registered locally in each feature / page - but it is not recommended* * As before - there should be no explicit binding to business logic in `shared` * *If necessary, you need to take this relationship to the `entities` level or even higher* ### `NEW` Entities, Processes[β](#new-entities-processes "Direct link to heading") In v2 **, other new abstractions** have been added to eliminate the problems of logic complexity and high coupling. * `/entities` - layer **business entities** containing slices that are related directly to the business models or synthetic entities required only on frontend * *Examples: `user`, `i18n`, `order`, `blog`* * `/processes` - layer **business processes**, penetrating app * **The layer is optional**, it is usually recommended to use it when *the logic grows and begins to blur in several pages* * *Examples: `payment`, `auth`, `quick-tour`* ### `BREAKING` Abstractions & Naming[β](#breaking-abstractions--naming "Direct link to heading") Now specific abstractions and [clear recommendations for naming them](/documentation/docs/about/understanding/naming.md)are defined #### Layers[β](#layers "Direct link to heading") * `/app` β **application initialization layer** * *Previous versions: `app`, `core`,`init`, `src/index` (and this happens)* * `/processes` β [**business process layer**](https://github.com/feature-sliced/documentation/discussions/20) * *Previous versions: `processes`, `flows`, `workflows`* * `/pages` β **application page layer** * *Previous versions: `pages`, `screens`, `views`, `layouts`, `components`, `containers`* * `/features` β [**functionality parts layer**](https://github.com/feature-sliced/documentation/discussions/23) * *Previous versions: `features`, `components`, `containers`* * `/entities` β [**business entity layer**](https://github.com/feature-sliced/documentation/discussions/18#discussioncomment-422649) * *Previous versions: `entities`, `models`, `shared`* * `/shared` β [**layer of reused infrastructure code**](https://github.com/feature-sliced/documentation/discussions/31#discussioncomment-453020) π₯ * *Previous versions: `shared`, `common`, `lib`* #### Segments[β](#segments "Direct link to heading") * `/ui` β [**UI segment**](https://github.com/feature-sliced/documentation/discussions/31#discussioncomment-453132) π₯ * *Previous versions: `ui`, `components`, `view`* * `/model` β [**BL-segment**](https://github.com/feature-sliced/documentation/discussions/31#discussioncomment-472645) π₯ * *Previous versions: `model`, `store`, `state`, `services`, `controller`* * `/lib` β segment **of auxiliary code** * *Previous versions: `lib`, `libs`, `utils`, `helpers`* * `/api` β [**API segment**](https://github.com/feature-sliced/documentation/discussions/66) * *Previous versions: `api`, `service`, `requests`, `queries`* * `/config` β **application configuration segment** * *Previous versions: `config`, `env`, `get-env`* ### `REFINED` Low coupling[β](#refined-low-coupling "Direct link to heading") Now it is much easier to [observe the principle of low coupling](/documentation/docs/reference/slices-segments.md#zero-coupling-high-cohesion) between modules, thanks to the new layers. *At the same time, it is still recommended to avoid as much as possible cases where it is extremely difficult to "uncouple" modules* ## See also[β](#see-also "Direct link to heading") * [Notes from the report "React SPB Meetup #1"](https://t.me/feature_slices) * [React Berlin Talk - Oleg Isonen "Feature Driven Architecture"](https://www.youtube.com/watch?v=BWAeYuWFHhs) * [Comparison with v1 (community-chat)](https://t.me/feature_sliced/493) * [New ideas v2 with explanations (atomicdesign-chat)](https://t.me/atomicdesign/18708) * [Discussion of abstractions and naming for the new version of the methodology (v2)](https://github.com/feature-sliced/documentation/discussions/31) --- # Migration from v2.0 to v2.1 The main change in v2.1 is the new mental model for decomposing an interface β pages first. In v2.0, FSD would recommend identifying entities and features in your interface, considering even the smallest bits of entity representation and interactivity for decomposition. Then you would build widgets and pages from entities and features. In this model of decomposition, most of the logic was in entities and features, and pages were just compositional layers that didn't have much significance on their own. In v2.1, we recommend starting with pages, and possibly even stopping there. Most people already know how to separate the app into individual pages, and pages are also a common starting point when trying to locate a component in the codebase. In this new model of decomposition, you keep most of the UI and logic in each individual page, maintaining a reusable foundation in Shared. If a need arises to reuse business logic across several pages, you can move it to a layer below. Another addition to Feature-Sliced Design is the standardization of cross-imports between entities with the `@x`-notation. ## How to migrate[β](#how-to-migrate "Direct link to heading") There are no breaking changes in v2.1, which means that a project written with FSD v2.0 is also a valid project in FSD v2.1. However, we believe that the new mental model is more beneficial for teams and especially onboarding new developers, so we recommend making minor adjustments to your decomposition. ### Merge slices[β](#merge-slices "Direct link to heading") A simple way to start is by running our linter, [Steiger](https://github.com/feature-sliced/steiger), on the project. Steiger is built with the new mental model, and the most helpful rules will be: * [`insignificant-slice`](https://github.com/feature-sliced/steiger/tree/master/packages/steiger-plugin-fsd/src/insignificant-slice) β if an entity or feature is only used in one page, this rule will suggest merging that entity or feature into the page entirely. * [`excessive-slicing`](https://github.com/feature-sliced/steiger/tree/master/packages/steiger-plugin-fsd/src/excessive-slicing) β if a layer has too many slices, it's usually a sign that the decomposition is too fine-grained. This rule will suggest merging or grouping some slices to help project navigation. ``` npx steiger src ``` This will help you identify which slices are only used once, so that you could reconsider if they are really necessary. In such considerations, keep in mind that a layer forms some kind of global namespace for all the slices inside of it. Just as you wouldn't pollute the global namespace with variables that are only used once, you should treat a place in the namespace of a layer as valuable, to be used sparingly. ### Standardize cross-imports[β](#standardize-cross-imports "Direct link to heading") If you had cross-imports between in your project before (we don't judge!), you may now take advantage of a new notation for cross-importing in Feature-Sliced Design β the `@x`-notation. It looks like this: entities/B/some/file.ts ``` import type { EntityA } from "entities/A/@x/B"; ``` For more details, check out the [Public API for cross-imports](/documentation/docs/reference/public-api.md#public-api-for-cross-imports) section in the reference. --- # Usage with Electron Electron applications have a special architecture consisting of multiple processes with different responsibilities. Applying FSD in such a context requires adapting the structure to the Electron specifics. ``` βββ src βββ app # Common app layer β βββ main # Main process β β βββ index.ts # Main process entry point β βββ preload # Preload script and Context Bridge β β βββ index.ts # Preload entry point β βββ renderer # Renderer process β βββ index.html # Renderer process entry point βββ main β βββ features β β βββ user β β βββ ipc β β βββ get-user.ts β β βββ send-user.ts β βββ entities β βββ shared βββ renderer β βββ pages β β βββ settings β β β βββ ipc β β β β βββ get-user.ts β β β β βββ save-user.ts β β β βββ ui β β β β βββ user.tsx β β β βββ index.ts β β βββ home β β βββ ui β β β βββ home.tsx β β βββ index.ts β βββ widgets β βββ features β βββ entities β βββ shared βββ shared # Common code between main and renderer βββ ipc # IPC description (event names, contracts) ``` ## Public API rules[β](#public-api-rules "Direct link to heading") Each process must have its own public API. For example, you can't import modules from `main` to `renderer`. Only the `src/shared` folder is public for both processes. It's also necessary for describing contracts for process interaction. ## Additional changes to the standard structure[β](#additional-changes-to-the-standard-structure "Direct link to heading") It's suggested to use a new `ipc` segment, where interaction between processes takes place. The `pages` and `widgets` layers, based on their names, should not be present in `src/main`. You can use `features`, `entities` and `shared`. The `app` layer in `src` contains entry points for `main` and `renderer`, as well as the IPC. It's not desirable for segments in the `app` layer to have intersection points ## Interaction example[β](#interaction-example "Direct link to heading") src/shared/ipc/channels.ts ``` export const CHANNELS = { GET_USER_DATA: 'GET_USER_DATA', SAVE_USER: 'SAVE_USER', } as const; export type TChannelKeys = keyof typeof CHANNELS; ``` src/shared/ipc/events.ts ``` import { CHANNELS } from './channels'; export interface IEvents { [CHANNELS.GET_USER_DATA]: { args: void, response?: { name: string; email: string; }; }; [CHANNELS.SAVE_USER]: { args: { name: string; }; response: void; }; } ``` src/shared/ipc/preload.ts ``` import { CHANNELS } from './channels'; import type { IEvents } from './events'; type TOptionalArgs
My Custom App component
Loading...
;
}
if (isError || !post) {
return <>{error?.message};
}
return (
Post id: {post.id}
{post.title}
{post.body}
Owner: {post.userId}
Components on this layer should not contain business logic, but it's okay for them to be business-themed. For example, you can put the company logo and page layout here. Components with UI logic are also allowed (for example, autocomplete or a search bar). * `π lib` β a collection of internal libraries.
This folder should not be treated as helpers or utilities ([read here why these folders often turn into a dump](https://dev.to/sergeysova/why-utils-helpers-is-a-dump-45fo)). Instead, every library in this folder should have one area of focus, for example, dates, colors, text manipulation, etc. That area of focus should be documented in a README file. The developers in your team should know what can and cannot be added to these libraries. * `π config` β environment variables, global feature flags and other global configuration for your app. * `π routes` β route constants or patterns for matching routes. * `π i18n` β setup code for translations, global translation strings. You are free to add more segments, but make sure that the name of these segments describes the purpose of the content, not its essence. For example, `components`, `hooks`, and `types` are bad segment names because they aren't that helpful when you're looking for code. ### Entities[β](#entities "Direct link to heading") Slices on this layer represent concepts from the real world that the project is working with. Commonly, they are the terms that the business uses to describe the product. For example, a social network might work with business entities like User, Post, and Group. An entity slice might contain the data storage (`π model`), data validation schemas (`π model`), entity-related API request functions (`π api`), as well as the visual representation of this entity in the interface (`π ui`). The visual representation doesn't have to produce a complete UI block β it is primarily meant to reuse the same appearance across several pages in the app, and different business logic may be attached to it through props or slots. #### Entity relationships[β](#entity-relationships "Direct link to heading") Entities in FSD are slices, and by default, slices cannot know about each other. In real life, however, entities often interact with each other, and sometimes one entity owns or contains other entities. Because of that, the business logic of these interactions is preferably kept in higher layers, like Features or Pages. When one entity's data object contains other data objects, usually it's a good idea to make the connection between the entities explicit and side-step the slice isolation by making a cross-reference API with the `@x` notation. The reason is that connected entities need to be refactored together, so it's best to make the connection impossible to miss. For example: entities/artist/model/artist.ts ``` import type { Song } from "entities/song/@x/artist"; export interface Artist { name: string; songs: Array
For example, if you have an index for the feature "comments", `π features/comments/index.js`, there's no reason to have another index for the `ui` segment of that feature, `π features/comments/ui/index.js`. 3. If you have a very big project, there's a good chance that your application can be split into several big chunks.
For example, Google Docs has very different responsibilities for the document editor and for the file browser. You can create a monorepo setup where each package is a separate FSD root, with its own set of layers. Some packages can only have the Shared and Entities layers, others might only have Pages and App, others still might include their own small Shared, but still use the big one from another package too. --- # Slices and segments ## Slices[β](#slices "Direct link to heading") Slices are the second level in the organizational hierarchy of Feature-Sliced Design. Their main purpose is to group code by its meaning for the product, business, or just the application. The names of slices are not standardized because they are directly determined by the business domain of your application. For example, a photo gallery might have slices `photo`, `effects`, `gallery-page`. A social network would require different slices, for example, `post`, `comments`, `news-feed`. The layers Shared and App don't contain slices. That is because Shared should contain no business logic at all, hence has no meaning for the product, and App should contain only code that concerns the entire application, so no splitting is necessary. ### Zero coupling and high cohesion[β](#zero-coupling-high-cohesion "Direct link to heading") Slices are meant to be independent and highly cohesive groups of code files. The graphic below might help to visualize the tricky concepts of *cohesion* and *coupling*:  Image inspired by