🚦Роутинг

Или как мы топчемся на месте.

Современная веб разработка приучила нас к тому, что "роут" - компонент на какому-то пути.
Все популярные решения (react-router, Next.js, Angular, Vue и пр.), каждый со своими фичами сбоку, обыгрывают именно этот концепт.
Если попробовать дать им общее определение, то будет что-то вроде "Роутинг - механизм связи URL, данных и интерфейса".

Достаточно ли этого?
Действительно ли роутинг в вебе это просто {path, element, loader, …}?
Для начала попробую сформулировать общее определение.

Роутинг в клиентских приложениях - механизм управления переходами между узлами пользовательских сценариев, состоянием этих узлов и их связью с внешним миром.

Покрывают ли это мейнстримные решения?
Безусловно, но настолько изолировано, ограничено и с привязкой к конкретному окружению, что мы не можем связать роутинг с остальной логикой без костылей, а всё, что не заложено в решение (а заложено только `.push("/another/path”)`), будет физически невозможно и придется реализовывать это самим.

Что такое роут?

Роутом, или, как я сформулировал выше, "узлом" может быть любой самодостаточный элемент пользовательского пути, например:
- Любая страница/лейаут
- Виджет выбора эмоджи
- Диалоговое окно
- Полноэкранный поиск (популярный нынче `⌘K`)
- Окно с выбором стикеров в телеграме в виде тултипа, открываемого при наведении

В приложенном коде я наметил возможную реализацию последнего примера, тултипа со стикерами в телеграме, на effector и atomic-router.

В тот момент, когда логика "что-то открылось/закрылось" перестает быть неважной деталью реализации и становится явным звеном пользовательского сценария, это "что-то" становится роутом.

Неважно открыт тултип или нет, это просто подсказка в интерфейсе, но, когда в нём целый виджет, "неважная деталь реализации" становится ключевой, у виджета появляется роут и логика работы с ним.
И не имеет значения что это - тултип, страница или модалка, это просто способ связи роута и внешнего мира.

Внешний мир

То, что мы привыкли считать неотъемлемыми частями роутинга, - лишь частные случаи.
В мобильных приложениях и виджетах нет URL.
В тестах не нужны компоненты.
В коде большинства продуктов нет голых путей, все работают через какую-то абстракцию по типу .push(routes.product.edit({ id: ... })), ведь строки - неудобный и откровенно дырявый способ идентификации роутов.
Люди делают приложения, роутинг которых почти полностью построен на модалках.

В логике нет путей, в логике нет компонентов, всё это - внешний мир.

Расширяемость

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

Ограниченная модель:
- Прибита к компонентам и к URL/файлам
- Нет явных сущностей роутов, вся работа через строки
- Любая "фича" - частный случай, а не системное решение (react-router тут явно лидирует)
- Реализует под капотом самопальную реактивную систему

Расширяемая модель:
- Строится поверх общей реактивной системы
- Дает базовые примитивы - явные сущности роутов и основные методы для построения логики
- Все "фичи" и сайд-эффекты (URL / компоненты / ...) реализуются поверх базовых примитивов
- Логика роутинга напрямую связана со всей остальной логикой

Ограниченная модель реализуется поверх расширяемой, но не наоборот.

Мораль

А нет её, в мейнстриме всё плохо, второй десяток лет с завидным упорством запрягаем старую клячу, надеюсь, мы всё же увидим прогресс.
А пока можете попробовать atomic-router.

Блокировка cookies замедляет веб, к радости Google

Многие наверняка уже слышали о скорой всеобщей блокировке third party cookies, на которой строится заработок рекламных и партнерских программ и заметной части веба в целом. В safari и firefox трекинг пользователя через куки на сторонних сайтах выключен уже довольно давно, но Chromium, разрабатываемый бизнесом построенным на рекламе, бан кукис всё откладывает и откладывает, хотя британские законодатели давят на них и в конце концов вынудят полностью отказаться от такого трекинга.

Казалось бы, замечательно, улучшение приватности, одни плюсы? Оказалось, что у этой медали есть вторая сторона: отсутствие нормальных альтернатив. Недавно, я в свой практике увидел несколько новых заходов на то, как вскоре будут работать все: жесткий кастомный фингерпринтинг. Бизнес, построенный на рекламе то умирать не планирует, а раз нельзя трекать через куки, но можно вставлять свои скрипты партнерам, то каждая сеть лично для себя начнёт собирать свой собственный слепок пользователя для идентификации.

Фингерпринт скрипт — это код, который пытается собрать как можно больше информации о системе и юзере, проверяя на расхождения в реализациях различных браузеров и девайсов. Вы вот например знали, что в V8 есть console.context чтобы вылезти мимо оберток типа роллбара и писать в консоль напрямую? А скрипт знает, и запишет, что у юзера движок V8 в таком-то диапазоне версий. Создаст невидимый canvas чтобы проверить нюансы работы gpu. Проверит все плагины браузера. Попробует написать в почивший WebSQL. Заглянет к typeof document.all. Короче задействует как можно больше дырок чтобы создать уникальную комбинацию параметров, чтобы отличить одного юзера от другого. Можете себе представить, насколько медленно это работает?

А теперь представьте, что вскоре у каждой партнерки будет свой скрипт фингерпринта, потому что практики переиспользования кода в этой части индустрии нет, каждый скрипт уникальный и независимый.

В итоге, количество скриптов будет ограничено только количеством партнерок у сайта. Ну, к примеру, штук 15. Каждый скрипт в 80-400 кб веса и по 200 мс работы.

Кажется, я представлял себе будущее с запретом на трекинг слегка иначе

И тут возникает вопрос, а как планирует жить гугл, почему он не торопится сделать альтернативу? А у него оказывается всё хорошо. Спасибо недавнему сливу документации к движку гугла, теперь мы знаем, что для себя любимых в гугл оставили возможность собирать данные напрямую с пользователей Chrome и для них этот запрет уже роли не играет, это пройденный этап. Этап на пути к процветанию в технологической монополии: для нас есть метрики прямо в браузере, для вас — 5 метров фингерпринтов.

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

The UK wants to make sure that Google isn't making changes to Chrome to prop up its advertising business at the expense of competitors.

Гугл пробует что-то сделать, но пока это выглядит довольно странно, технология Related Website Sets для работы требует открытия PR на гитхабе, мержить который будут сотрудники гугла. Очень удобно, спасибо, это точно поможет снизить уровень монополизации.

И тут возникает интересный вопрос — а куда мы в итоге движемся?

Я вижу столкновение двух непреодолимых сил: желания рекламных бизнесов выжить и стремление европейских регуляторов снизить уровень чужой слежки за своими гражданами. Отказ от кукис не обсуждается, это явно проблема с приватностью, но ведь и фингерпринты же по прежнему работают? Если ввести аналоги кукис но урезанный на пол шишечки, то что мешает новой Cambridge analytica вновь слить все наработанные данные на сторону? Зачем всё это противостояние, если конечная проблема не техническая реализация cookies а сама модель рекламного бизнеса? Зачем это всё, если всё останется как есть, но с фингерпринт-скриптами?

Много вопросов, мало ответов