Примечание: то, о чем я буду говорить здесь, касается только использования Meteor и Redux в контексте клиента React Native.
Изначально я намеревался создать пакет поверх моего шаблона React Native Meteor, который упростил бы реализацию React Native и Redux при поддержке Meteor.
Когда я начал строить, я понял, что то, что я строил, было не тем, чем я на самом деле пользовался. Мне не нравится создавать решения, которые не соответствуют тому, что я на самом деле использую, поэтому я отказался от этого.
Вместо того, чтобы пытаться создать пакет, который творит много волшебства, я хочу показать вам, как я на самом деле использую Redux в сочетании с Meteor и React Native. Он не идеален, но именно его я использую для создания настоящих приложений каждый день.
Я расскажу об оптимистичных обновлениях, хранении состояния Meteor в магазине Redux, о том, как я получаю доступ к данным и почему у меня действительно возникают проблемы.
Если вы не знакомы с Redux, многое из этого может не иметь для вас смысла. Я предлагаю прочитать документацию, прежде чем продолжить.
Оптимистичные обновления через действие
Если вы смотрели мой шаблон, вы, вероятно, видели это
Это фрагмент отсюда. Теперь это может работать отлично, но ваши компоненты могут начать забивать логикой… особенно, когда задействовано оптимистичное обновление.
Поэтому вместо того, чтобы помещать много кода в мои компоненты контейнера, я использую их для простой отправки различных действий - действий, которые извлекают данные, и действий, которые вызывают некоторую модификацию данных.
Для этого вам также потребуется использовать библиотеку redux-thunk, потому что каждое действие, отправленное из компонента, само отправляет два действия. Давайте посмотрим на пример ...
Итак, в моем компоненте-контейнере у меня будет функция, которая при нажатии будет увеличивать счетчик числа.
Теперь, как на самом деле будет выглядеть действие incrementCount?
Вы можете видеть, что создатель действия выполняет 3 вещи. Сначала он отправляет другое действие, которое будет обрабатывать наше оптимистичное обновление, затем выполняет фактический вызов метода метеора и, наконец, обновляет хранилище с правильным результатом.
Теперь это бесполезно без редуктора, поэтому давайте взглянем на него.
Очевидно, это чрезвычайно простой пример, но вы можете начать понимать идею. Это может показаться утомительным, но вы полностью контролируете процесс, и вам нужно только реализовать его так, как вы считаете нужным - возможно, вам не нужно сейчас оптимистичное обновление… просто не создавайте его. Но когда вы это сделаете, вам нужно только создать новое действие, а затем изменить свой редуктор, чтобы что-то с ним сделать.
Мне нравится, что я могу улучшить функциональность своего приложения, не смешивая логику представления и бизнес-логику. Redux дает прекрасное разделение проблем.
Копирование данных из Meteor в Redux
Я уверен, что это одна из областей, которую можно улучшить, и я призываю людей подсказать мне, как это сделать. Иногда вы хотите сохранить некоторые данные Meteor в своем хранилище redux. Причина, по которой я хочу скопировать его, заключается в том, чтобы каждый компонент мог выглядеть одинаково и извлекать данные из Redux, вместо того, чтобы использовать Redux, некоторые используют метеор createContainer, а некоторые используют оба.
Эти фрагменты данных: Meteor.user (), Meteor.status () и Meteor.loggingIn (). Я хочу, чтобы в моем магазине redux всегда был последний результат этого.
Сначала нам нужно подключить компонент, чтобы узнать о Meteor. Мы собираемся сделать это только в нашем корневом компоненте. Каждый раз, когда меняются реквизиты, мы обновляем наш магазин Redux.
Помимо этого, нам нужно написать создатель действий, который довольно прост, поэтому я оставлю его в стороне, а также наш редуктор. Очевидно, вы можете называть вещи как хотите.
Все ваши данные Meteor теперь находятся в вашем магазине Redux и должны всегда быть актуальными.
Если у вас есть лучший способ сделать это, дайте мне знать. Здесь есть возможности для улучшения.
Доступ к данным
Теперь вы можете заметить, что, сделав это, у вас больше не будет доступа к Minimongo. Для меня и для моих целей это нормально. Выполняя подобные действия, мы получаем доступ к данным и их хранение одинаковым образом во всем приложении.
Я использую lodash для запроса своих данных. Это компромисс, который вам придется решить для себя.
К чему хлопот?
Очевидно, здесь есть дополнительная работа, и она определенно подходит не всем. Причина, по которой я делаю это таким образом, состоит в том, чтобы сохранить согласованность между всем моим приложением и экосистемой React в целом. Я создаю приложение React Native сначала как приложение React, а затем как приложение Meteor. Когда вы начинаете создавать приложение таким образом, вы понимаете, что единственное, где ваше приложение действительно знает о Meteor, - это ваши действия и где бы вы ни копировали данные из Meteor в Redux. Это позволяет легко изменять код и знать, где искать при возникновении ошибки.
Сначала создайте приложение React Native, а затем приложение Meteor.
Это также упрощает обновление. Допустим, вы создали специальную службу поиска для своего приложения, в которой есть REST API. Вам нужно всего лишь изменить свое действие, чтобы попасть по этому новому URL-адресу, а не погружаться в логику представления, рискуя проблемами.
Теперь вы можете сказать, что существует гораздо больше шаблонного кода, использующего этот метод, и я не соглашусь с вами. Но я могу написать еще 10 строк кода, если это означает, что я могу находить и исправлять ошибки в 10 раз быстрее. Когда вы работаете над приложением в течение нескольких месяцев или лет, вы тратите больше времени на рефакторинг и изменение существующего кода, чем на написание нового кода, так что упростите это.
С учетом сказанного, это не идеальный процесс, и есть много возможностей для улучшения. Я хотел бы услышать ваши мысли о том, как сделать это проще.
Если вы заинтересованы в создании приложений для iOS и Android с помощью React Native и Meteor, подпишитесь на мою рассылку, и я покажу вам, насколько это просто.
