example: add new example yeahub

[YeaHubTeam]

Background

This update adds YeaHub Platform as a new example — a large-scale production project that demonstrates:

• Full implementation of Feature-Sliced Design (FSD) v2
• A complete modern React ecosystem
• Both common and complex enterprise-level development cases

The project brings significant value to the community by serving as:

• A reference example of FSD adaptation for large applications
• A practical guide to scalable code organization
• A demonstration of real-world architectural best practices

---

Description

YeaHub Platform is a professional IT community platform built as a production-ready application with a complete FSD architecture.

---

Tech Stack

Core

• React 18
• TypeScript
• Webpack

State Management

• Redux Toolkit
• RTK Query

Routing

• React Router

UI

• Storybook
• Custom Design System

Infrastructure

• CI/CD
• ESLint
• Prettier

---

FSD Implementation Features

• Clear layer separation
• Flexible public API system
• Reusable modules
• Optimized builds

---

Links

• 🌐 Production: https://yeahub.ru/
• 💻 Source Code: https://github.com/YeaHubTeam/yeahub-platform

[YeaHubTeam]

FSD Linter Warnings & Decisions

During this PR, the Feature-Sliced Design linter is enabled and reports no critical errors.
However, several warnings remain and were left intentionally.

Below is a list of such cases with explanations. The goal is to preserve architectural clarity and avoid degrading the project structure for the sake of formal linting compliance.

---

1. useAppSelector dependency on app layer

File:
src/shared/libs/redux/useAppSelector/useAppSelector.ts

Warning:
Forbidden sidestep of public API when importing from "@/app/providers/store"

Rationale:
useAppSelector relies on the store type defined in the app layer.
The store itself aggregates Redux slices from all layers, which is its architectural responsibility.

Exposing or duplicating this type through a public API would introduce unnecessary indirection and maintenance overhead without practical benefits.

---

2. i18n configuration import in app

File:
src/app/index.tsx

Warning:
Forbidden sidestep of public API when importing from "@/shared/config/i18n/i18n"

Rationale:
The app layer initializes i18n using direct imports.
Using the public API here would pull in additional dependencies that are not required at the application entry point.

This deviation is a conscious decision aimed at reducing coupling and avoiding redundant imports.

---

3. Single-usage slice warnings

Warning:
This slice has only one reference in slice "...". Consider merging them

Rationale:
These warnings are intentionally ignored.

Following this recommendation would require moving most features and widgets into the pages layer, which contradicts the principles and goals of Feature-Sliced Design.

The purpose of this project is to clearly demonstrate layer responsibility and functional ownership, not to optimize structure based on heuristic rules.

---

4. State type and higher-layer imports

File:
src/shared/config/redux/State.ts

Warning:
Forbidden import from higher layer "entities"

Rationale:
The State type aggregates Redux states from multiple layers and is subsequently used in selectors across those layers.

Centralizing such imports in a single file is preferable to spreading the same warnings across the entire codebase.
This keeps architectural deviations localized and easier to reason about.

---

Summary

Not all FSD linter warnings were fixed intentionally.
Some of them reflect practical architectural decisions that:

• Preserve project readability
• Avoid unnecessary complexity
• Align with the goal of demonstrating FSD in a real-world, production-scale application

We are open to discussion and recommendations, but the current state is considered acceptable and justified.

[YeaHubTeam]

🇷🇺 Русская версия

@illright, добрый день!

Буду признателен, если сможете взглянуть на этот PR.

Мы считаем, что наш проект — это хороший пример крупного, реального production-проекта, который:

• активно развивается,
• следует архитектуре Feature-Sliced Design,
• и отражает реальные архитектурные компромиссы, с которыми сталкиваются большие приложения.

В проекте представлено множество реальных бизнес-сущностей и практик, характерных для enterprise-разработки:

• большое количество доменных сущностей,
• использование различных архитектурных и технических подходов,
• полный набор CRUD-операций,
• система авторизации и ролей,
• графики, аналитика и сложные UI-сценарии,
• разнообразные модули и взаимодействие между слоями.

Проект open source, и мы видим в нём высокую образовательную ценность:
новички и практикующиеся разработчики могут изучать FSD на живом, масштабном проекте, который растёт и эволюционирует так же, как продукты в больших компаниях.

Будем рады, если вы рассмотрите возможность включения проекта в качестве примера в документацию FSD:
https://feature-sliced.github.io/documentation/ru/docs/get-started/overview

Считаем, что это может стать важным шагом для сообщества и поможет лучше понять практическое применение FSD.

Спасибо за ваш труд и вклад в развитие архитектуры!

---

🇬🇧 English version

@illright, hello!

I would really appreciate it if you could take a look at this PR.

We believe that our project is a strong example of a large, real-world production application that:

• is actively evolving,
• follows the Feature-Sliced Design architecture,
• and reflects real architectural trade-offs commonly found in large-scale applications.

The project includes many real-life business entities and enterprise-level patterns, such as:

• a wide range of domain entities,
• multiple architectural and technical approaches,
• full CRUD workflows,
• authentication and role-based access control,
• charts, analytics, and complex UI scenarios,
• diverse modules and interactions across layers.

The project is open source, and we see strong educational value in it:
beginners and practicing developers can learn FSD from a living, large-scale codebase that grows and evolves in the same way as real products in big companies.

We would be happy if you consider including this project as an example in the FSD documentation:
https://feature-sliced.github.io/documentation/ru/docs/get-started/overview

We believe this could be an important contribution to the community and help demonstrate practical usage of FSD.

Thank you for your work and for developing the architecture!

[illright]

Hello! I would personally prefer not to add new examples to the docs, but I'm willing to make an exception for projects that would make a good showcase. The one biggest point of concern I have with this project is the following:

3. Single-usage slice warnings

Warning:
This slice has only one reference in slice "...". Consider merging them

Rationale:
These warnings are intentionally ignored.

Following this recommendation would require moving most features and widgets into the pages layer, which contradicts the principles and goals of Feature-Sliced Design.

The purpose of this project is to clearly demonstrate layer responsibility and functional ownership, not to optimize structure based on heuristic rules.

It wouldn't contradict the principles or goals of Feature-Sliced Design, in fact, it's the essence of pragmatic application of FSD and the reason why there was a minor version bump to FSD 2.1 — this is the currently preferred direction of FSD. I used to think there was value in showing an example of layer responsibility even when it's not practical, but I no longer think that. I think practicality trumps dogma and I would like the new learners of FSD to adopt this idea as well.

This point is currently a blocker for adding this project as an example. If you would be willing to reconsider your stance on this issue, I would consider adding this project. If you'd like to discuss these ideas and express your disagreement with my position, you're very welcome in our Telegram chat :)

[YeaHubTeam]

@illright
Our team would like to experiment with the architecture and create a separate branch where we apply changes based on your feedback.

Could you please confirm whether it would be acceptable if we:

• prepare such a branch,
• share it with your team for review,
• and then let you decide whether the project can be added to the documentation examples based on that version?

We would also really appreciate any additional suggestions or remarks regarding the project — we’re happy to take them into account and improve the example accordingly.

Repository link:
https://github.com/YeaHubTeam/yeahub-platform

One more clarification regarding structure:
if we move some features or entities into the Pages layer, is it expected that they should be additionally grouped into subfolders, or is it acceptable to keep them directly under the page scope, for example:

pages/

• users/
  -- ui/
  --- AddUserForm/
  --- UserCard/

Thank you in advance for your feedback!

[YeaHubTeam]

Hi @illright,

We’ve created a separate branch with all the changes based on your previous feedback.

Could you please take a look and let us know your thoughts? We’d really appreciate any additional suggestions or remarks to help make this project a suitable example for the documentation.

Branch link: https://github.com/YeaHubTeam/yeahub-platform/tree/feature/YH-1611

Thank you in advance for your time and feedback!

Best regards,
@YeaHubTeam

[illright]

Thanks, and sorry for the long response, I've been quite busy with other things lately...

Your project seems to be very large, and it doesn't seem like there are any Steiger errors, great job! I'll let others from the core-team take a look at the project, and I would also suggest that you go to the Telegram chat of FSD and show this project to some people who were looking for examples — recently there have been a couple messages about that.

I'm very curious about your experience refactoring your project to FSD 2.1 — do you feel like the project is easier or harder to navigate than before?

[YeaHubTeam]

Hi @illright,

Thank you for your kind words and for developing FSD — we really appreciate the work the team is doing. We actively use FSD in our projects and also try to popularize the approach, as we want it to be more accessible and understandable for both beginners and experienced developers.

Our goal is to make this project a solid real-world example of using FSD in a large codebase. We want it to be useful not only as a reference, but also as a learning resource. We’ll also think about writing an article describing our experience in more detail.

Regarding your question about refactoring to FSD 2.1 — we’ll prepare a more detailed response. We plan to outline what was challenging during the migration, what trade-offs we encountered, and what the refactoring ultimately led to in terms of project structure and navigation.

Thanks again for your feedback and interest in the project!