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

Я считаю себя полиглотом как в отношении языков программирования, так и в отношении серверных и интерфейсных фреймворков. В последнее время я потратил время на изучение и использование React и Vue в реальных проектах перед их возможной поддержкой со стороны Ionic, и меня поразило, насколько они похожи на Angular, как 1.5+, так и 2.x + (ps я наслаждаюсь ими обоими очень!)

Во всех этих фреймворках у нас есть простая компонентная модель (pre-component () angular была особой уникальностью, я вам это дам). Мы можем устанавливать свойства компонентов, обновлять их в однонаправленном режиме и эффективно отображать их только при необходимости, сводя к минимуму модификации DOM и избегая классических ловушек производительности внешнего интерфейса. Состояние может быть установлено для компонентов через настраиваемую систему состояний, а именно React, или данные экземпляра класса, как Angular 2.x + (с помощью zone.js). Мы даже можем начать ориентироваться на среды, не относящиеся к DOM, в большинстве этих фреймворков, если захотим.

Только когда я попробовал использовать Redux, я понял, что все мы были обмануты: настоящие 100-кратные инновации во фронтенд-разработке вообще не на уровне компонентов, а на уровне управления государством.

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

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

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

Вместо этого мое увлечение внешним интерфейсом почти полностью сосредоточено на Redux и улучшенном управлении состоянием. Ничто не улучшило и не изменило мои отношения с программированием так кардинально, как внедрение Redux, и я рад, что эта модель внедряется во все основные фреймворки (примеры: vuex, ngrx / Store).

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

Это 2017 год. Все фреймворки, ориентированные на компоненты, великолепны, пора создать совместимость и сосредоточиться на следующих крупных инновациях в управлении состоянием.