Рабочий дневник: День 186
Привет Tastack-query-Vue

😥 Переписал проект уже в пятый раз. На этот раз виновник – Tanstack Query.

Думал, что это рудимент из Wagmi, который под капотом использует Tanstack, но скоро понял, что это новый король запросов!

Так в чём его фишка? Почему нельзя просто остаться на axios (или fetch) и не мучить себя новым? Всё дело в новой (для меня) концепции состояния сервера.

☕️ Оказывается, все эти годы, ковыряясь с REST и CRUD, я бессознательно воевал с состоянием сервера.

Лоадеры, реактивность, кеширование – всё это было попыткой решить одну проблему: как понять, актуальны ли данные, и когда их нужно обновлять?

🎸 Tanstack решает эту задачу из коробки! Каждый запрос кешируется в оперативке, но можно продублировать в localStorage.

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

🤯 Когда увидел обсуждение, что Tanstack Query может заменить Pinia, задумался, а нужен ли мне теперь этот стейт-менеджер? Ведь Tanstack уже отвечает за состояние!

🚀 Оказалось, нужен. Только теперь Pinia – это чисто локальное состояние (темы, языки, локальные переменные), которое обновляется реактивно за счёт того, что Tanstack вовремя сообщает о новых данных.

Похожую роль могут выполнять composables. Но они усложняют поддержку: не каждый поймёт вашу логику. А структуру Pinia знают все.

Крч, теперь это выглядит как домино: действие (создание канала) обновляет блокчейн → Tanstack ловит изменение → обновляет локальное состояние в Pinia → подхватывает эти изменения и раздаёт их компонентам, обновляя UI

Интеграция Tanstack и Wagmi вышла настолько гладкой, что мне пришлось снести 20% кодовой базы.

🔨 Доволен как слон: приложение реально стало реактивным, динамичным и быстрым. Что дальше? Возможно, шестой рефакторинг…

📊 #статистика День 1224 == 2852 час в IT