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.