Данными они становятся только в виде дампа, отправленного на сервер, но для самого клиента это часть логики, а не маппинг данных из базы к представлению. Зачем заставлять UI слать внутри себя запросы к самому себе, да ещё и на языке, который придуман не для событийной модели, а для сетевого взаимодействия? GraphQL для данных - круто, действительно революция, и автоматическое кэширование данных тоже здорово. Но само приложение в отрыве от данных тут не причём, интерфейсом пусть занимается какой-нибудь легковесный effector / reatom, а на сервер максимум дамп настроек пусть уходит.
Почему это не данные? Есть какие-то объективные причины не ситать это данными? Я скорее представляю данными все, что может прийти в компонент и изменить его состояние/отображение. Да, эти данные могут быть разными, что не исключает необходимости работы.с ними в одном потоке. А уж где и как их хранить, обрабатывать, отправлять ли их на сервер для синхронизации и когда это делать – будет решаться где-то в другом месте. Это вопрос каждый разработчик решает сам в силу своего опыта и навыков. Но компонент всегда имеет единый интерфейс описания нужных ему данных (fragment) и ввод/вывод для stateful (query/mutation). Я, например, не хочу хранить 2 раза хоть какие-то данные (кеш+менеджер), не вижу никакого выигрыша в этом (ни в скорости, ни в удобстве) и рад, что у меня есть возможность сделать единый интерфейс для работы с ними. Да, я сам намучался с кешем в версии 2, это реально набор костылей без каких-то особых плсов, но сейчас уже гуд и я спокойно могу сосредоточится на сложности самого интерфейса, не думая про уровень данных. Про effector / reatom я лучше промолчу – это не тема этого обсуждения. И да, дамп нужно не только отправлять, а еще построить кучу всего вокруг, если с этим дальше как-то работать.
Обсуждают сегодня