Bug: Folder name "entity-card/ui" in "shared/ui" is reserved for segment names

[EliseyMartynov]

Правило: no-reserved-folder-names.
Не совсем понятно что именно тут нарушается.

Sandbox: https://codesandbox.io/p/devbox/steiger-test-g4f4wp

[illright]

This is a rule that forbids having folders with segment-like names inside segments: https://github.com/feature-sliced/steiger/blob/master/packages/steiger-plugin-fsd/src/no-reserved-folder-names/README.md

For example, you can't have shared -> ❗️ ui -> entity-card -> ❌ ui to avoid confusion

[EliseyMartynov]

But wait.. Segments can be complicated, and entity-card can have their own segment ui just because it can be complicated.
So we can just turn off this rule?

[illright]

It's true that segments can be complicated, but I don't see how you would need to subdivide to ui if you (theoretically) have already excluded all non-UI code. For instance, for this structure:

• 📂 shared/ui/complicated-thing/
  • 📂 ui
  • 📂 api // ← this doesn't make sense inside shared/ui

[EliseyMartynov]

It doesn't make sense with api, but make sense with other segments like model (why not)?

[illright]

but make sense with other segments like model (why not)?

If I'm inside a segment ui, I expect to only find code related to UI, not the data model. The data model has its own segment, model, which is where I'd go to look for that code. So for me, it never makes sense to have segments inside of segments

[EliseyMartynov]

Can't accept that. There are plenty UI elements that can have internal state, such as select-box. So where should I place logic? In UI segment?

[illright]

Not every instance of state needs to be a model. For example, a select box might track the state of selected options, but this is not business logic, so I would simply write that state inside the component, or in a sibling file.