Открыть список
Как стать автором
Обновить

Комментарии 11

В данном примере все просто, но вот если в параметрах запроса есть параметры которые завязаны на кучу других компонентов (поиск, сортировка или фильтрация) то все будет не так тривиально. Про связь мутация+форма+валидация я вообще промочу.


В моем случае пришлось написать подобие orm для всего этого и обернуть её в redux, хотя сейчас я бы лучше использовал для этого mobx.

Спасибо за идею добавлю запрос с параметром в пример
Если уж совсем от redux хочется избавится, то можно попробовать apollo-link-state (https://github.com/apollographql/apollo-link-state).
На данный момент мне не очень понравилась работа с кэшем, но обещают в новой версии добавить хелперы на все случаи жизни.
Я думаю что такие решения как apollo-link-state это развитие темы в немного другую сторону — от чистой декларативности к управлению состоянием. Мои планы в ближайшее время посмотреть в сторону relay. Я его долгое догонял но сейчас кажется есть небольшая надежда

Сразу уточню. Apollo graphql client использует redux под капотом — уже нет. с версии 2 Apollo перестали использовать Redux под капотом

Спасибо уточню текст
В запросе получения всех постов («allPosts») нет аргумента «limit» :)
Исправил limit на first.
А что делать, если двум и более компонентам надо работать с общими данными?
Если использовать подход декларативный то стора не существует. Есть тоько описание того что мы показываем. Если будутв другом компоненте запрошены данные те же самые то они будут там отбражены согласно описанию этого компонента. Также данные кшируются чтобы избежать лишних запросов к бэкэнду.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.