v2.1: Pages come first!

[illright]

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:

1. 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.
2. 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 (feat: rewrite the overview #685).
• New partial translations: Korean (docs: types page translated into Korean #739, docs: examples Authentication page translated into Korean #736, docs: guide example page translated into Korean #735, docs: layout page translated into Korean #742, docs: guides page translated into Korean #732, feat: main, tutorial, and FAQ pages translated into Korean #730, feat: translate get-started folder index, overview to Korean #715), Japanese (feat: Japanese full support #728).
• The tutorial was rewritten. Technical details were stripped out, more FSD theory has been added (feat: add the second part of the tutorial #665).
• Guides on how to deal with common frontend issues like page layouts (feat: add the guide for page layouts #708), types (First draft of the types guide #701), authentication (feat: rewrite the guide about authentication #693).
• Guides on how to use FSD with Nuxt (feat: added config routing to nuxtjs guide #710, fix: change alias path in the Nuxt guide #689, Статья "Использование в NuxtJs": Поправлен файловый роутинг примера #683, feat: added usage with nuxt guide #679), SvelteKit (feat: added sveltekit-usage guide #698), Next.js (fix: fix a section in the Next.js guide and add an example #699, Update with-nextjs.mdx #664, docs: usage with NextJS article updated #644), and TanStack Query (feat: add react query example #673).
• A new feedback widget, powered by PushFeedback! Go give it a try and let us know what you think of the new pages (feat: integrate PushFeedback to collect feedback about docs #695).
• Comparison of FSD with Atomic Design (docs: added atomic design alternative docs #671).

Changed

• The migration guide from a custom architecture (formerly known as "from legacy") has been actualized (feat: rewrite and complete the migration guide from custom arch #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 (fix: unlist the decomposition cheatsheet temporarily #649).

---

This discussion was created from the release v2.1: Pages come first!.

[alexdeia]

You're alive!