Задача, которую я нашел довольно легко решаемой Apollo Client, - это реактивность пользовательского интерфейса. В какой-то момент при написании веб-приложений вы, вероятно, думали об эффективном способе обновления пользовательского интерфейса после изменения данных на стороне сервера. Здесь действительно сияет Apollo GraphQL.
Давайте нырнем!
Представьте, что у вас есть Bill модель, и у вас есть кнопка с надписью «Оплатить счет», которая запускает событие для оплаты счета на сервере; вот модель:
Чтобы пометить Bill как оплаченный, нам нужно использовать мутацию GraphQL, это должно обновить базу данных, и нам нужно это обновленное значение с сервера для обновления пользовательского интерфейса.
Вот интерфейс перед оплатой счета:
Вот это после:
Обновление практически мгновенное. Пока вы получаете id и обновленные свойства - в нашем случае это поле paid - после мутации Apollo будет обновлять пользовательский интерфейс реактивно. Нам не нужно было писать лишнюю строчку кода. Меньше написанного кода, меньше кода для отладки.
Приведенный выше пример полезен в случаях, когда мы хотим обновить один объект. Что, если нам нужно обновить массив объектов? Скажем, у нас есть список счетов, и мы хотим добавить его, когда создадим новый из приложения? Apollo обрабатывает это по-другому, поскольку нам нужно вручную обновить этот список.
Нам нужно передать функцию в свойство Мутации update. Эта функция обновляет кеш Apollo новым объектом, например:
Функция updateBillsCache, переданная в опору обновления, считывает старый список из кеша, как любой запрос GraphQL, затем обновляет кеш, добавляя новое значение в массив. Таким образом, пользовательский интерфейс повторно отображается с обновленным значением.
Вот и все, с клиентом Apollo все просто! Приложение для оплаты счетов находится здесь: код
