Allow nested layers within a slice

[H1op3ts]

The main idea is allowing the same layers structure but within a slice. If some slice (let it be some page for example) has it's own UNIQ business logic we can use the same FSD approach to structurize that logic within a slice folder i.e we can place "features" and "widgets" folders alogside with model/api/ui within that page slice. The rules are exactly the same as for root layers: only one direction relations. Layers within a slice could ONLY start with the layer below the slice layer, i.e if a slice is an instance of pages it's own layers could start with widgets, if a slice is instance of widgets then it's own layers could start from features, etc. This will allow to limit nesting structure by layers depth and nesting will be finite. There is no violation in case if some nested feature imports some "global feature layer" feature, because nested feature relates to it's higher slice, there couldn't be cross imports issues. Possibly it's better to place nested layers within a "model" folder.

Nested structure example

-app
|-pages
|---page-slice
|---|--model
|---|--ui
|---|--lib
|---|--api
|---|--widgets
|---|--|--page-slice-uniq-widget
|---|--|--|--model
|---|--|--|--ui
|---|--|--|--features
|---|--|--|--|--page-slice-uniq-widget-feature
|---|--|--|--|--|--model
|---|--|--|--|--|--ui
|---|--features
|---|--|--page-slice-uniq-feature
|---|--|--|--model
|---|--|--|--ui
 ...
|-widgets
|---widget-slice
|---|--model
|---|--ui
|---|--lib
|---|--api
|---|--features
|---|--|--widget-slice-uniq-feature
|---|--|--|--model
|---|--|--|--ui
|-features
  ...
|-entities
  ...

[illright]

There has been some talk in the core-team about fractal FSD structure, but none of it has been released yet.

As for your proposal, my main question is: why do we need this? Layer names have semantic meaning, so when we consider the term "FSD Widget", we expect to find all of them in src/widgets, but with this proposal we would also have to check all higher layers for other widgets. Of course, we might consider distinguishing between global widgets and local widgets, but then why do we even need to call the local widgets widgets? I think it can just as easily be a plain component.

I think that the main struggle that this proposal is trying to address is how to organize a lot of code within a single slice. It's a very valid struggle, but addressing it properly would probably require some examples of complex logic inside a slice when a simple division by segments is no longer enough. Could you come up with some example that illustrates the benefits of this proposal over the existing structure?

[sanua356]

@H1op3ts Of course you can stick to the established set of rules in your case, but I don't think it is necessary to make it the FSD standard.

[H1op3ts]

@sanua356 Can't agree more, I don't insist on that to be a standard, much less on that to be mandatory. Just to officially ALLOW use such a nesting

[illright]

Well, FSD is extendable, so there's nothing stopping you from implementing this in your projects, but then you would be responsible for maintaining the documentation for this extension. The reason I'm hesitant to pull it into the main documentation is because it might complicate the learning process even more than it is already.

[sanua356]

@illright Yes. I agree. Could you please review pull request #711?

[illright]

@sanua356 I will review that pull request when I have the time and energy. I remember about it, no need to remind about it further.

[noveogroup-amorgunov]

Hi! I’d like to bring this topic back up, as the idea has become especially relevant after the release of version 2.1.

Page slices are becoming quite large and starting to contain a significant amount of code. Let’s take https://samokat.ru/ as an example. On the homepage, there are various sliders with products, sliders with promo selections and recipes, category listings, and informational banners. Overall, this is similar to any admin dashboard.

If we place all this in page segments, we end up with so-called destructive decoupling, where modules are split across different segments of the page.

src
  pages
    home
      index.ts
      ui
        MainPageContainer/
        AwesomeProductSlider/
        AwesomeProductSliderCard/
        RecipeSlider/
        RecipeSliderCart/
        CategoryListing/
        CategoryCard/
        ShowcaseInformersGrid/
        ... // a lot of other components
      model
        awesomeProductSlice.ts
        pageSlice.ts
        types.ts
      api
        awesomeProductApi.ts
        showcaseInformerApi.ts
        categoryTreeApi.ts
        ...
      lib
        ...apiMappers

For instance, the "awesome products" slider ends up scattered across page segments. It would be great to group it into a standalone slice (like a widget). Moving it to the global widgets layer is not an option, since it isn’t used anywhere else yet.

If sub-slices (similar to fractals) were allowed, the project structure could look something like this:

src
  pages
    home
      index.ts
+      @local-entities
+         recipe/
+      @local-widgets
+        awesome-product-slider/
+          ui/
+            AwesomeProductSlider/
+            AwesomeProductSliderCard/
+          model/
+            awesomeProductSlice.ts
+            types.ts
+          api
+            awesomeProductApi.ts
+          lib
+            mapAwesomeProductsDto.ts
+        recipe-slider/
+        category-listing/
+        showcase-informers-grid/
+        ...
      ui
        // only base components for page
        MainPageContainer/
      model
        pageSlice.ts
        types.ts

Довран wrote about introducing fractals in https://t.me/feature_sliced/1/136388. In my opinion, it’s a great idea that doesn’t break current compatibility and adds a lot of flexibility - sub-slices. Additionally, it would help promote the page-first approach, where we build applications starting from the page layer.

Довран also suggested limiting the nesting to one level, which I agree with. Exactly how to structure fractals doesn’t seem that critical. Let it be an additional segment, with a prefix like @... to explicitly distinguish it in the structure.

With fractals, I think the blocker lies elsewhere—what are the rules for creating them? For example, is it appropriate to have a pages or app layer within a fractal inside pages/X/?

In response to the question above, I’d suggest not enforcing strict rules, but as a recommendation, advise against using fractals of layers above the current one (for example, allow local widgets within a widget, but discourage local pages inside a widget).

This feature should be documented separately (just like @x) in an advanced section of the documentation.

[noveogroup-amorgunov]

I prepare example with this approach https://github.com/noveogroup-amorgunov/fsd-lessons/tree/main/packages/custom-fractal-sub-slices

[sanctionic]

@noveogroup-amorgunov In our team we eventually agreed on moving the slides (in your exaple it's "awesome products" widget) into root fsd/wigdets but under a specific folder like fds/widgets/@home that holds everything related to the "home" page. So in general it still in the root widgets slice even though it's not used anywhere except for "home". I personoally don't like it, but I decided to not go against the team:)

[sanctionic]

BTW @H1op3ts is my previous account

[noveogroup-amorgunov]

@sanctionic The team is sacred, so you made the right choice :) But in my opinion, it’s not very scalable for two reasons:

• In addition to widgets for pages, we might also need sub-widgets for widgets, or features for pages/widgets. And the @home notation only covers one use case (widgets for pages).
• If we have many pages (say 50 or more) and they are grouped (grouped slices), we’ll also need to maintain this structure separately on the widgets layer.

But overall, I completely agree that sub-slices give a big boost to expanding the methodology.

[sanctionic]

@noveogroup-amorgunov yeah that's exactly what I don't like in our current approach, however as @illright already mentioned - "Well, FSD is extendable, so there's nothing stopping you from implementing this in your projects"