The new revision of Feature-Sliced Design is here! The main difference with FSD 2.0 is the new approach to decomposition — “pages first”.
What's “pages-first”?
You do “pages first” by keeping more code in pages. For example, large blocks of UI, forms and data logic that are not reused on other pages should now stay in the slice of the page that they are used in. The division by segments (ui, api, model, etc.) still applies to all this code, and we encourage you to further split and organize code into folders inside of segments — don't just pile all the code into a single file.
In the same way, widgets are no longer just a compositional layer, instead they should also store code that isn't currently needed outside of that widget, including its own stores, business logic, and API interactions.
When you have a need to reuse code in several widgets or pages, consider putting it in Shared. If that code involves business logic (i. e. managing specific modal dialogs), consider breaking it up into infrastructural code, like the modal manager, and the business code, like the content of the modals. The infrastructure can then go to Shared, and the content can stay in the pages that use this infrastructure.
How is it different?
In FSD 2.0 we explained how to identify entities and features in your application, and then combine them in widgets and pages. Over time we started disliking this approach, mostly for the following reasons:
- Code cohesion is much worse in this approach
- You need to jump around several folders just to make changes to a single user flow
- Unused code is harder to delete because it's somewhere else
- Finding entities and features is still an advanced skill that needs to be developed over time
- It requires understanding of the business context, which not all developers want to bother with
- On the other hand, splitting by pages is natural and requires little training
- Different developers have different understandings of these concepts, which leads to everyone having their own idea of FSD, which causes conflict and misunderstanding
Is it hard to migrate from FSD 2.0?
This is a non-breaking change, so you don’t even necessarily need to migrate your current FSD projects to FSD 2.1, but we still think the new way of thinking will lead to a more cohesive and less opinionated structure. We’ve compiled a few steps you can take in the migration guide.
What else happened since the last release?
Another exciting new thing in the FSD ecosystem is our architectural linter, Steiger. It's still in active development, but it is production-ready.
A couple more minor clarifications to the docs were made as well:
- Application-aware things like the route constants, the API calls, or company logo, are now explicitly allowed in Shared. Business logic is still not allowed, but these things are not considered to be business logic.
- Imports between segments in App and Shared were always allowed, but it's been made explicit too.
And here's what happened to the documentation website:
Added
- Slightly rewritten and expanded overview page to give some details about FSD right away (#685).
- New partial translations: Korean (#739, #736, #735, #742, #732, #730, #715), Japanese (#728).
- The tutorial was rewritten. Technical details were stripped out, more FSD theory has been added (#665).
- Guides on how to deal with common frontend issues like page layouts (#708), types (#701), authentication (#693).
- Guides on how to use FSD with Nuxt (#710, #689, #683, #679), SvelteKit (#698), Next.js (#699, #664, #644), and TanStack Query (#673).
- A new feedback widget, powered by PushFeedback! Go give it a try and let us know what you think of the new pages (#695).
- Comparison of FSD with Atomic Design (#671).
Changed
- The migration guide from a custom architecture (formerly known as "from legacy") has been actualized (#725).
Removed
- The decomposition cheatsheet is now unlisted for an undefined period of time. It proved to be more harmful than useful, but maybe it can be saved later (#649).