Абстракции: искусство или необходимость в коде?

🌱 Абстракция в коде нужна не чтобы было «красиво» и не чтобы показать, что слой есть. Нужна, когда одну и ту же боль больше не хочется решать на каждой странице.

Пример из практики. Списки. Фильтры, пагинация, сортировка живут в query. Человек шарит ссылку, обновляет страницу, возвращается назад, и состояние должно остаться. В URL всё строки. А в приложении нужны числа, булевы, диапазоны дат, массивы id. Если каждый экран сам парсит page, сам клеит дату, сам решает, писать в URL дефолты или нет, через месяц получаешь зоопарк. Где-то страница это число, где-то строка. Где-то три фильтра дают три перехода по роутеру. Где-то дефолты затирают то, что уже было в ссылке.

✋🏻 Плохая абстракция тут выглядит так: обернули route.query в функцию с красивым именем, а парсинг, сериализация и гонки всё равно остаются снаружи. Слой есть, пользы нет. Это как раз «смотри, сделал».

👌🏻 Нормальная абстракция закрывает задачу целиком. Общий слой принимает дефолты и говорит, как поле живёт в URL: число, флаг, диапазон дат, массив. Дальше он сам синхронизирует состояние с query, сам приводит типы туда и обратно, сам копит несколько изменений и пишет их одним обновлением адреса, сам не затирает ссылку дефолтами при первом заходе. Над этим ещё один слой для таблиц: страница описывает фильтры, а пагинация и query уже не её забота.

Польза простая. Новая страница не изобретает сериализацию. Ссылка работает одинаково во всём продукте. Баг с датой или с page=2 чинится один раз. Код на экране короткий не потому что «архитектура», а потому что грязная работа уже сделана там, где ей место.

Критерий простой. Если слой убирает повторяющуюся ошибку и экономит думанье на каждом экране, это абстракция. Если без него всё равно надо знать внутренности URL, это декорация.

Абстракции: искусство или необходимость в коде? | Сетка — социальная сеть от hh.ru