Стоит ли использовать Redux с приложением Meteor / React?

Question

Я неплохо использовал Meteor, и мне это нравится, модель публикации / подписки, то, как продуман весь фреймворк, простота написания кода на стороне сервера ... и я использовал React с Meteorи это тоже круто.

Однако я недавно сделал не-Метеорный проект в React / Redux, и есть много чего полюбить в Redux. Установка требует больше усилий, но единый магазин и все связанные с ним инструменты / системы очень хороши.

Мое веб-приложение будет активно взаимодействовать с базой данных и нуждается в оптимистичном интерфейсе.

ИтакМне интересно, стоит ли использовать Meteor / React / Redux для моего следующего проекта, тем более что в MiniMongo есть некоторые ограничения (например, нет поддержки массивов). Однако я не нахожу много соответствующих руководств о том, как их соединить, например, этому уже почти 3 года. Это заставляет меня сомневаться в том, что многие люди используют эту настройку, и смогу ли я заставить ее работать легко: из прошлого опыта я знаю, что мне нужны пошаговые руководства для преодоления первоначальных препятствий с новой настройкой, затем послечто я могу все уладить для себя.

Я точно буду использовать Meteor / Redux. Я их знаю, они мне нравятся. Вопрос в том, стоит ли добавлять Redux накладные расходы? Я надеюсь, что это подходящий вопрос для StackOverflow, если нет, я постараюсь опубликовать его в другом месте.

Я хотел бы услышать причины использовать или не использовать Redux с Meteor / React, а также любые рекомендации для учебных пособий. Спасибо.

Answer 1

Я думаю, что Redux применим в неметеорном мире, хотя теперь есть альтернативы с локальным состоянием graphql или использованием контекстного API React (который, благодаря React Hooks, больше не считается устаревшим)

В любом случае, вернемся к истории ...

У меня есть два отдельных приложения Meteor, одно из которых использует Redux, а другое - нет.

Redux хорошо работает с Meteor, он делаетасинхронная вещь довольно хорошо, но это добавляет целые много сложностей для спорнога выгоды. В неметеорном приложении, где вы делаете гораздо больше для организации асинхронных вызовов API, это имеет смысл, поскольку вы можете эффективно отделить обработку данных от пользовательского интерфейса.

Но в типичном MeteorПриложение, использование публикаций и подписок означает, что данные в любом случае передаются естественным путем. Кнопка пользовательского интерфейса запрашивает внутреннее действие. Метод Meteor выполняет свою работу и обновляет базу данных, и эти данные автоматически обновляются в пользовательском интерфейсе.

Давайте рассмотрим сценарий, который я недавно реализовал. Члены моего приложения должны проверить работу с детьми. Им присваивается номер, и когда мы обрабатываем продление membershio, нам необходимо убедиться, что номер остается в силе. Это инициируется кнопкой в ​​пользовательском интерфейсе, которая вызывает метод Meteor, который, в свою очередь, выполняет вызов API. Метод просто обновляет результаты проверки (даже если она не проходит) в записи базы данных участника. Возвращаемое значение из вызова Meteor позволяет нам сделать тост-уведомление для пользователя, и pub / sub просматривает после обновления нового статуса в пользовательском интерфейсе.

Это также может быть сделано с Redux, но в значительной степени всевсе вышеперечисленное необходимо сделать в любом случае.

Я предпочитаю Redux, поскольку есть альтернативы, и кажется, что это уровень разработки, который отвлекает вас от написания приложения.