feat: update structure

guides/frontend_styleguide.md

@@ -4,13 +4,13 @@
 Все наши проекты должны быть в одном стиле во всем - наименование, структура и тд.
 Единообразие и следование правилам важнее чем то, что гласят отдельные правила.
 
-За основу берем [конфиг от typescript book](https://github.com/basarat/typescript-book/blob/master/docs/styleguide/styleguide.md).
-
 Стараемся большую часть работы по проверки качества кода свалить на софт. Люди ошибаются постоянно, компьютеры - никогда.
 Поэтому eslint, prettier, etc - наше все.
 
 ## Linting
 
+За основу берем [конфигурацию от typescript book](https://github.com/basarat/typescript-book/blob/master/docs/styleguide/styleguide.md).
+
 ### [eslint-config-bestdoctor](https://github.com/best-doctor/eslint-config-bestdoctor)
 Используем во всех проектах, при необходимости добавляем специфичные для проекта правила/плагины (например штуки про react-native для мобилки).
 
@@ -41,19 +41,18 @@
 
 В `src` проекта находятся/могут находиться папки:
 
-- `entities` - корневая директория содержащая код относящийся к бизнес-сущностям
+- `entities` - корневая директория кода относящегося к бизнес-сущностям
   + `[Имя_сущности]` - корневая директория для конкретной бизнес-сущности (e.g. `User`)
     * `components` - компоненты отвечающие за view слой сущности;
     * `contexts` - контексты используются **только** в случае необходимости глобального использования сущности для избегания пропс-дриллинга, директория содержит всё относящееся к контекстам;
     * `hooks` - хуки сущности, содержит базовые хуки для работы с api (`queries`, `mutations`) и хуки специфичные для сущности. Инвалидаторы и фабрика ключей кэша запросов также находятся здесь;
     * `pages` - компоненты отвечающие за отображение страниц, относящихся к сущности.
-- `features` - корневая директория для кода не относящегося к конкретной бизнес сущности, содержит в себе директории фичей, структуры, которых идентичны структуре в `entities`. Примеры фичей: 
+- `services` - глобальные вещи, по смыслу схожие с идеологией синглтонов (существует в единственном экземпляре, к которому есть подключения из различных мест), примеры:
   * `auth` - всё, что связано с авторизацией - хуки, компоненты вывода информации об пользователе, страница с ошибкой о недостатке прав;
+  * `api` - слой подключения к внешнему api, хранящий необходимые настройки, не путать с конкретными запросами, которым место в entities;
+- `features` - корневая директория для кода не относящегося к конкретной бизнес сущности, содержит в себе директории фичей, структуры, которых идентичны структуре в `entities`. Примеры фичей: 
   * `text` - функции плюрализации, компоненты вывода заголовков, абзацев и т.д.
-  * `forms` - компоненты для создания форм (поля ввода, выпадающие списки и т.д.), хуки хранения значения форм 
-- `typings` - общие для приложения типы данных, которые нельзя отнести к какой-то бизнес сущности (e.g. типизация модуля не имеющего нормальной типизации).
-- `utils` - вспомогательные функции, которые шарятся между многими компонентами. У папки есть тенденция превращения в помойку, нужно стараться распределять функции между `entities` и `features`
-- `constants` - статичные константы, например цвета, брейк поинты и тд. Если значение является вычисляемым - например ширина конечной области зависящая от размера экрана, это должно быть в `utils`. Аналогично `utils` имеет тенденцию превращения в помойку и нужно стараться избегать.
+  * `date` - функции и константы для работы с датами (форматирование, парсинг, маски)
 
 В корне проекта могут лежать базовые вещи типа инстанса истории браузера, роутер, тема визуализации, но лишь пока они атомарны, в случае наращивания функционала следует перенести в features
 
@@ -251,17 +250,6 @@ Field - указание на поле, если действие произво
 #### Глобальные стейты
 По возможности избегаются. Всё что может быть локальным - делается локальным. Исключениями могут быть только вещи, которые действительно используются глобально - авторизация, стейт виджета, используемого на множестве страниц и т.д., для них допускается использование контекста.
 
-### features и entities
-#### Зачем все это надо
-1. Разделение на фичи и сущности позволяет отделить бизнес-логику от общей
-1. Модульная структура позволяет легко переиспользовать компоненты и шарить их между разными частями приложения или разными приложениями.
-1. Разделение по сущностям способствует работе tree-shaking - чаще требуется несколько компонентов связанных отношением к одной сущности, а не внешне похожих
-
-#### Размер файла
-
-Чем меньше - тем лучше. Проще воспринимать 5 файлов по 100 строк чем один по 500. При этом разбиение должно быть максимально логичным - выделяем обособленные куски и выносим их в component parts либо subcomponents.
-Объемную логику выносим в utils.
-
 ## Names
 ### Общее
 
@@ -328,7 +316,7 @@ Boolean - с префиксами is, has, can, has, have, was etc.
 
 #### Параметры функции
 
-Если параметров один или два то можно передавать обычно ( `function foo(a: number, b: number)` ), иначе оборачиваются в объект ( `function foo({ a: number, b: number, c: string })` ). Можно даже единственный аргумент сразу заворачивать в объект для упрощения добавления новых в будущем.
+Если параметров один или два то можно передавать обычно ( `function foo(a: number, b: number)` ), иначе оборачиваются в объект ( `function foo({ a: number, b: number, c: string })` ). Допускается оборачивание в объект единственного аргумента, если планируется или допускается расширение функционала/конфигуриремости.
 
 #### Композиция функций