Clarification on fsd/insignificant-slice rule in Steiger

[chertik77]

I'm doing a todo app, I have 4 pages and my main page is dashboard. I've got the structure similar to something like this:

src
├── features
│   ├── card
│   │   ├── add-card
│   │   ├── edit-card
│   │   └── delete-card
│   ├── column
│   │   ├── add-column
│   │   ├── edit-column
│   │   └── delete-column
│   └── user
│       ├── change-theme
│       └── toggle-sidebar
├── widgets
│   ├── header
│   ├── sidebar
│   └── kanban-board
│       ├── filters
│       ├── card
│       │   ├── CardList.tsx
│       │   └── CardListItem.tsx
│       ├── column
│       │   ├── ColumnList.tsx
│       │   └── ColumnListItem.tsx
│       └── board
└── pages
    ├── welcome
    ├── signin
    ├── signup
    └── dashboard

These features are not reusable, cause it all happens on the same page, steiger suggests me move all slices to the layer above, so to the kanban-board widget, doing that, my widget would become a complete mess with a lot of ui and lib folders. Do you have any suggestions how i can accomplish this?

And also features like toggle-sidebar, and change-theme - it works only in one place, but moving everything to widgets would become unreal to maintain.

[illright]

my widget would become a complete mess with a lot of ui and lib folders

There are ways to avoid that with simple principles:

1. Reusable styles and trivial UI-kit components like buttons and cards should go to shared/ui — that way you get rid of the majority of style-related code in your kanban board widget
2. Components that look the same and represent the same thing but have minor visual differences could also be moved to shared/ui, even when they have a bit of UI logic to them. Changing parts can be inserted through the slots pattern. For example, if you have similarities between the UI of add-card, edit-card, and delete-card, that's a great way to unload the kanban board widget.
3. Not every user action needs to be a separate component, or worse, a separate slice. For example, from the names of slices, the UI seems pretty trivial to me. Add and Edit can be represented with the same UI, Delete is just a single button and a confirmation dialog (good candidate for shared/ui as well).

And also features like toggle-sidebar, and change-theme - it works only in one place, but moving everything to widgets would become unreal to maintain.

How big are these features? Seems to me that each of them can comfortably fit inside a single file. Besides, things like theme management can be placed in shared/ui as well, and the state of the sidebar can be encapsulated within the sidebar itself

[chertik77]

Hey, thanks for your reply.

1. All my style kit, reusable components are in shared, i'm talking about logic, each my slice like add-card of edit consists of api + lib + model + ui (like dialog + form + api call)

And i dont really get your meaning on moving everything to shared, if ui goes to shared/ui, what to do with server logic or lib folder? Moving everything to entities or widgets?

Almost of all your examples have features like add-post, edit-post, which are used only in one place, like in https://github.com/yurisldk/realworld-react-fsd

Could you plese provide more context of how i should structure?

[illright]

Yeah, most example projects on the website are built for FSD 2.0, not FSD 2.1

what to do with server logic

You can keep it all in the kanban board widget/page

Not sure what you have in lib, so I can't really give concrete suggestions on where to move things

[chertik77]

Hey, I would like to add some context to my response to illustrate how my structure looks like:

Here are card features - https://github.com/chertik77/TaskPro-frontend/tree/main/src/features/card

The same applies to column features, they all are related to one widget - kanban-board
https://github.com/chertik77/TaskPro-frontend/tree/main/src/widgets/kanban-board

Kanban board widget it's just a set of blocks like card list or column list which uses small blocks like features on entities.

If you advise me to move those features to kanban widget, so widget could become unmaintainable?

Because the main rule of the features to be reusable in many places, so widget should handle all the logic?

And thanks for your overall help, I'm looking for to discover fsd deeper and deeper over the time.

[illright]

It's hard for me to say how to refactor your code such that it wouldn't become unmaintainable — there's a lot of ways to do that and many decisions to take. I suggest you give it a try and once you have more specific questions, you can ask them in our Telegram chat — https://t.me/feature_sliced