Целый новый мир, часть 1: размышления о переходе на React
В Gather мы исторически разрабатывали наши интерфейсные приложения на AngularJS (за некоторыми исключениями). Однако недавно мы решили перейти на React по трем причинам:
- Идти в ногу с современными веб-стандартами, переходя на Angular 2+, по сути, было бы переделкой, поэтому мы решили оценить различные варианты.
- React решил несколько болевых точек, которые у нас были с Angular — в основном односторонний поток данных, более точный контроль над управлением данными и акцент на компонуемых и повторно используемых компонентах.
- Растущая популярность React обеспечила большие ресурсы и богатую экосистему.
Мы все еще продвигаемся к тому, чтобы стать полностью React-приложением, но пока довольны достигнутым прогрессом. Вот 3 важных вывода из наших первоначальных усилий.
Учитесь в идеальных условиях
Прежде чем мы были готовы погрузиться в React с головой, мы хотели начать работать над двумя проектами вне нашего основного приложения:
- Прототип нового продукта, который мы изучали. В итоге мы двинулись в другом направлении, но опыт, полученный при пилотировании технологии, оказался ценным.
- Обновление нашего мобильного приложения с использованием комбинации React Native и React.
Помимо изучения того, как создать приложение React, это позволило нам понять, каким наше текущее приложение AngularJS могло бы быть, если бы оно было полностью React, и помогло принять несколько решений более высокого уровня при начале работы. добавьте React в наше основное приложение.
Создавайте и уважайте границы
В качестве одной из наших первых попыток внедрить React в наше основное приложение мы создали небольшие компоненты пользовательского интерфейса в React, используя ngReact, чтобы использовать их в качестве компонентов AngularJS. Со временем мы могли бы скомпоновать эти более мелкие компоненты в более крупные компоненты и органично вырасти в приложение React с нуля.
Это закончилось неудачей.
Эти несколько компонентов были фактически компонентами AngularJS, написанными на React. Функции, которые продавались нам в React, такие как односторонняя привязка данных (ngReact настраивает для вас двустороннюю привязку 😬) и состав компонентов, были невозможны на этом уровне детализации, поэтому это просто создало ненужную трещину.
Наша инициатива React была отложена на какое-то время, и когда мы снова взялись за нее, наш подход изменился, чтобы попытаться сделать React как можно более огороженным садом из AngularJS. Между ними должны были быть точки соприкосновения, минимизация этих точек соприкосновения была большим акцентом в нашем подходе.
Мы также пытались быть более строгими в том, что мы хотели бы написать в React. Вместо небольших гранулированных компонентов работа, написанная на React, должна быть достаточно большой, чтобы быть относительно независимой. Хотя мы, вероятно, продолжим писать простые настройки, такие как добавление дополнительных полей формы в AngularJS, новые страницы или функции будут первыми кандидатами для React.
Выкопайте «яму успеха»
Яма успеха: в отличие от вершины, пика или путешествия по пустыне, чтобы найти победу через множество испытаний и сюрпризов, мы хотим, чтобы наши клиенты просто научились побеждать, используя нашу платформу и фреймворки. В той мере, в какой мы упрощаем попадание в неприятности, мы терпим неудачу. (источник)
Большинство людей, включая разработчиков программного обеспечения, идут по пути наименьшего сопротивления. Просто наличие возможности использовать React вместо AngularJS не означает, что использование React будет набирать обороты. Часто будут причины не создавать новые функции внешнего интерфейса в React, но они никогда не должны включать в себя плохой опыт разработки или механику этого.
Первая проблема заключалась в том, как заставить компоненты React жить в приложении Angular. Есть много разных способов подойти к проблеме, но наше решение в первую очередь должно было абстрагироваться от лежащего в основе подхода от разработчиков, пишущих на React. Никаких запутанных или хрупких конфигураций, странной структуры компонентов и т. д. Затраченные усилия для создания безупречного опыта стоили 100% дополнительного времени и усилий.
Заранее потратив время на обдумывание особенностей этого, мы также установили несколько упрямых барьеров для шаблонов, которые мы хотели разрешить или запретить (двусторонняя привязка данных 🤨). Это усложняло возникновение проблем при внедрении умных решений и помогало принимать обоснованные решения о том, писать ли что-то на React.
Во-вторых, многие люди, не являющиеся разработчиками, участвуют в процессе разработки и не заботятся о том, AngularJS или React. Что их действительно волнует, так это такие факторы, как скорость разработки и риск, связанный с выполнением определенного набора работ. Благодаря тому, что разработка React стала быстрее и безопаснее, чем AngularJS, стало намного проще получить поддержку от всех участников.
В следующих постах мы рассмотрим более конкретные аспекты этой работы, так что следите за обновлениями!
