Реагировать на архитектуру для огромного бизнес-приложения

Таким образом, мы недавно выбрали React в нашей компании в качестве интерфейсной технологии для создания нашего огромного веб-приложения для бизнеса. Говоря недавно, я имею в виду, что у нас нет предыдущего опыта работы с React (у нас есть огромный фон AngularJS), и, говоря огромное приложение, я имею в виду, что он действительно огромный и очень динамичный с множеством и множеством разных функций и функций.

Поскольку у нас будет много огромных компонентов, которые играют очень важную роль и имеют сложную логику внутри них, а потому, что мы хотим, чтобы они были легко подключаемыми и многоразовыми, мы хотим, чтобы они были как можно более изолированными от внешнего мира и других части нашего приложения, поскольку в противном случае из-за их размера и сложной функциональности было бы практически невозможно разработать и поддерживать их. Это причина, по которой мы решили НЕ использовать Redux, по крайней мере, вначале, в то время как мы разрабатываем только отдельные компоненты, потому что это ставит под угрозу изоляцию компонентов и делает невозможным понять всю логику потока данных приложения, когда существует так много сложных компоненты. Хотя я считаю, что наш выбор может быть неправильным, потому что, как я уже упоминал, у нас нет опыта с React.

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

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

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

Причина, по которой я пишу этот вопрос, заключается в том, что я надеюсь получить представление о людях, имеющих солидный опыт работы с огромными внешними приложениями. Я хотел бы знать, можно ли разработать такое приложение с React, независимо от того, подходит ли React для такой сложности и динамики, действительно ли нам нужен Redux или что-то еще, какой путь, методы, идеологии должны мы следовать. Если вы правильно поняли мой вопрос, это скорее сторона архитектуры, с которой мы боремся, чем технологическая. Может быть, мы просто идем по пути, который ведет к все большему количеству борьбы и сложности, но не к производству.

Ответ 1

Нет абсолютно никаких сомнений в том, что React/Redux может (и широко) использоваться для разработки приложений, которые вы описываете. Ничто в вашем описании не делает то, что вы строите настолько уникально, что исключает React как платформу для его создания. Мы активно работаем с крупным корпоративным клиентом, который строит свой внешний интерфейс - с 100 + SPA (одностраничные приложения) в React. Это команда из более чем 100 разработчиков в течение 2-3-летнего проекта.

То, как мы это структурировали, имеет решающее значение -

Во-первых, вы хотите выбрать библиотеку компонентов пользовательского интерфейса. Несколько примеров ниже:

В основном мы взяли одну из них и создали из них библиотеку компонентов, потому что наши компоненты очень индивидуальны.

Во-вторых, мы создали модульную архитектуру, где каждый модуль (SPA) представляет собой пакет npm с основным компонентом контейнера и хранилищем redux.

Наконец, у нас есть центральный серверный пакет, в котором зарегистрирован каждый из модулей. Серверный сервер отвечает за аутентификацию, авторизацию, протоколирование, маршрутизацию и т.д.

Суть этого ответа заключается не в том, чтобы советовать о том, как структурировать большое приложение React, но чтобы вы знали, что React может быть (и используется) для разработки приложений, похожих на то, что вы описываете.

Ответ 2

Начинать писать более сложные приложения в React действительно может быть борьбой, я точно знаю, что она чувствует!

Как вы говорите, React - это UI lib, а не фреймворк событий. Для этого вам обычно нужна библиотека для обработки событий, например Redux. Вы четко заявляете, что решили не использовать Redux (вы даже не использовали заглавные буквы :)). Я бы сделал шаг назад, если бы был вами и пересмотрел это решение. Вы говорите, что причина не в использовании Redux заключается в том, что вы не можете сохранять свои компоненты легко подключаемыми и многоразовыми при использовании Redux. Я бы сказал, что это неверно. Redux полностью отделен от ваших компонентов React. Redux обрабатывает только принимаемые события и управляет состоянием. С точки зрения компонентов React, он просто получает данные в реквизитах и отправляет события, вызывая регулярные функции. Можно по-прежнему проводить единичные тесты, повторное использование и т.д.

Я бы предложил вам взглянуть на Redux с учетом этого. Рад помочь, если у вас есть еще вопросы!

Ответ 3

Вы пригвоздили проблему в своем question- реагировании, это библиотека представлений, а не инфраструктура приложения. Реальный вопрос: подходит ли React + Redux (или другая система управления государством) для большого приложения LOB.

Я расскажу о некоторых впечатлениях от опыта наших команд в этой области. Крупные приложения большого размера были разработаны с использованием шаблонов проектирования MVC/MVP/MVVM в течение десятилетий. Это проверенные и проверенные модели, которые поставляют программное обеспечение. Пара, что с инъекцией зависимости, и у вас есть модульное, проверяемое, поддерживаемое приложение. AngularJS (2. 0+) основывается на этих принципах и глубоко их использует. По этой причине мы используем AngularJS для всех наших корпоративных бизнес-приложений.

Реагировать, с другой стороны, - это легкий, эффектный рендеринг, который является превосходным для небольших приложений и облицовок клиентов (например, для динамического просмотра или простой панели инструментов). Мы часто обращаемся к React и VueJS здесь, потому что полный стек AngularJS является излишним и слишком тяжелым.

Ответ 4

Сейчас я в подобной ситуации. У меня есть опыт работы с крупными настольными приложениями (ERP, LOB - WinForms, WPF) - 1000+, очень динамичными (более 70% пользовательского интерфейса было создано с помощью входных данных/конфигурации), добавив новые функции, (не касаясь исходного кода).

Я глубоко изучаю современные веб-технологии, и я все больше убеждаюсь, что React не подходит для этого. Реакция действительно сияет в приложениях малого и среднего размера, где вы (и другие члены команды) разрабатываете каждую страницу/компонент "вручную" (не динамически генерируемую), и вы хотите иметь одно глобальное состояние. Но это не поможет вам создавать крупномасштабное приложение из коробки - это только библиотека пользовательского интерфейса (так что поддержка модулей, маршрутизации, форм, привязки, HTTP-запросов, статической типизации (машинописных файлов) и т.д.) Не поддерживается. Удивительно, что нет поддержки стилизации/инкапсуляции стиля (вам нужно интегрировать, например, CSS-модули, самостоятельно). И в конце вы должны постоянно беспокоиться об управлении версиями библиотек (чтобы они всегда работали вместе, это действительно время и энергия).

У меня большой опыт работы с Angular 2/4+, и я думаю, что на данный момент это лучшая технология для таких приложений (если вы знаете WPF, это очень похоже). Это полная структура, которая готова к масштабированию из коробки. Вы можете разделить ваше приложение на независимые модули (указав, какие компоненты будут видны во внешнем мире), каждый компонент имеет общедоступный api (статически типизированный, входы/выходы) и инкапсулированные стили css (между другими нет никаких помех). Для глобального состояния (вход в систему пользователя, глобальная конфигурация и т.д.) Вы все равно можете использовать библиотеку ngrx/store (которая реализует шаблон Redux и поставляется с дополнительными приятными вещами, такими как "эффекты" и очень хорошо интегрируется в систему Angular).

Я пытался делать в Angular действительно сумасшедшие вещи (динамически генерируя все приложение из конфигурации бэкэнд), и все работало отлично, как и ожидалось.

Ответ 5

React, Redux упростит работу, поскольку, когда дело доходит до сложных приложений, вы можете создать хорошо структурированный объект данных. то вы можете управлять полным пользовательским интерфейсом через React и его материалы... Есть несколько причин, почему это правильный выбор

  1. Государственное управление,
  2. Обработка данных структуры дерева,
  3. Уменьшите код,
  4. Вы будете знать, где были сделаны изменения (Действия, Редукторы)
  5. Ваш компонент будет заботиться только о пользовательских интерфейсах

То, что вам нужно сделать, это структурирование ваших данных

Ответ 6

Полностью понять ваши чувства, когда вы начинаете с React и Redux. Мы были в такой же ситуации, когда начинали с React в нашей компании. Сначала React имеет другой подход, чем другие фреймворки. Да конечно это не фреймворк, это просто библиотека. Вы должны начать думать в стиле React, а именно: компоненты React просто визуализируют состояние (как будто вы визуализируете сцену на вашей графической карте вначале, вы должны подготовить сцену, затем вы можете визуализировать), все, что может сделать компонент, - это диспетчеризировать действия, или лучше называть просто создателями действий.

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

Мы также используем TypeScript с комбинацией React, Redux. Вы должны написать больше кода, чем чистый JS, но статический контроль типов бесценен, когда вы работаете над большим проектом.

Логика разделения компонентов является нативным подходом к реагированию... вы должны отделить логику и написать "фиктивные компоненты", а затем использовать это снова с помощью connect. Или передать значения в качестве реквизита.

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

Что мне нравится в реакции/избыточности, так это как реализовать асинхронные вызовы и т.д. Первый компонент дизайна для отображения всех состояний

1) вроде у меня нет данных 2) загрузка данных 3) загрузка выполнена 4) ошибка загрузки

Для этого вам понадобится только один семафор в вашем состоянии и несколько проверок в методе рендеринга. Затем один создатель действия, который будет загружать данные и основывать на действии диспетчерское действие, описывающее прогресс.

Что также здорово, что в приложении реакции/редукции у вас есть единый поток данных, это хорошо, когда новый разработчик вступает в проект.

Для пользовательского интерфейса мы используем Material UI, да, у этого фреймворка есть некоторые проблемы, но ничего такого, с чем вы не сможете справиться.

Мы используем также Маршрутизатор для навигации в приложении.

В начале я буду избегать рендеринга на стороне сервера, потому что вам будет гораздо проще начать только с рендеринга на стороне клиента и с начального состояния.

При запуске для нас был полезен этот шаблон, где все работает в одном проекте JavaScriptServices

Тогда, конечно, отличные учебники Абрамова.

Для оформления компонентов очень пригодится сборник рассказов

Мы можем написать, зачем использовать или нет React в течение долгого времени... но Что я могу сказать... для нас это был хороший выбор, с некоторой болью в попрошайничестве, но теперь у нас хорошая окупаемость.

Ответ 7

Я нахожусь в аналогичной ситуации, оценивая Angular и React для перемещения пользовательского интерфейса ERP. В настоящее время он генерирует формы, таблицы данных, списки и т.д. На лету из данных конфигурации и по запросу (вероятно, аналогично вашему случаю). Я был довольно успешным с Angular в создании прототипов этих частей, хотя большинство структур пользовательского интерфейса (материальный интерфейс, Clarity и т.д. В Angular носят скорее декларативный характер), и вроде как проверяю, потому что я чувствую, что Angular немного "склонен" в определенных аспектах Я хотел бы (как разработчик), поэтому я смотрел на React как на простую библиотеку, а не на самоуверенную.

Однако я делаю шаг назад и ищу более крупный готовый продукт с точки зрения структуры/архитектуры, модулей, повторно используемых компонентов, простоты обслуживания и т.д. И наткнулся на ваш пост.

Так любопытно узнать, как ты справился с этим? Вы продолжали реагировать? @Salivan