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

Вначале был MVC

Я пользуюсь Ember.js еще до версии 1.0, когда он действительно был фреймворком модель-представление-контроллер. Тогда было достаточно просто сказать новым разработчикам: «Ember - это MVC в браузере», и они поняли. Существовали очевидные различия по сравнению с фреймворками MVC на стороне сервера - например, маршруты также играли огромную роль в браузере, тогда как в большинстве серверных сред они обычно были простым файлом конфигурации, - но фундаментальные принципы были одинаковыми на очень высоком уровне. Тот факт, что Ember следует хорошо зарекомендовавшему себя шаблону, сделал его привлекательным выбором для пользователей таких фреймворков, как Ruby on Rails или Cocoa.

Затем на сцену вышли веб-компоненты и все изменили. Polymer, React, Angular и т. Д. Все начали объединяться вокруг этого общего понятия расширения DOM, создавая, по сути, наши собственные пользовательские элементы, которые можно легко использовать с простым старым HTML и CSS. Эта модель взяла штурмом мир веб-интерфейсов, и Ember претерпела серьезные изменения, чтобы не отставать от него, добавляя компоненты, отбрасывая представления и (большинство) контроллеров, и коренным образом изменив способ написания большинства приложений Ember.

Тот факт, что Ember смог осуществить этот переход, сохранив при этом четкий путь обновления, делает этот фреймворк таким замечательным, и это одна из причин, по которой мне до сих пор нравится этот фреймворк. Это действительно основа стабильности без застоя, и есть масса вещей, которые освещены в других сообщениях блога # EmberJS2018, которые я хотел бы увидеть в дорожной карте на следующий год. В произвольном порядке:

  • Вызов угловой скобки
  • Пользовательские компоненты / компоненты Glimmer
  • Маршрутизируемые компоненты
  • Разделение кода / упаковка
  • Родные классы
  • Первоклассная поддержка NPM
  • Унификация модуля
  • Исправление Runloop
  • Ember Data RecordData (и открытие новых шаблонов данных в целом)

Однако, если есть что-то, что, на мой взгляд, нужно Эмберу больше всего на свете, это обновить то, как мы думаем о ментальной модели. Нам нужно сказать новым пользователям, что «Ember - это ___ фреймворк», и заставить их получить это.

M-V-What?

Новые пользователи, которые сегодня заходят в Ember, часто жалуются, что слишком много концепций, которые нужно изучить, что много чего происходит, много магии, и это слишком сбивает с толку. В структуре есть много важных концепций, и сложно выделить их в один из существующих TLA (трехбуквенных сокращений). Это:

  • MVC?
  • MVP?
  • MVVM?
  • Модель-Контроллер-Маршрут-Компонент-Сервис? MCRCS?

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

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

Компоненты

Начиная с последней серии Ember 1.x, компоненты стали центральным элементом всего в Ember. Способ, которым Ember реализует компоненты, является ядром фреймворка, и у вас не может быть Ember без компонентов Ember.

Я бы сказал, что любая другая концепция необязательна. Это может показаться смехотворным для людей, которые используют этот фреймворк со времен Ember 1.x, когда маршрутизатор был самым большим аргументом в пользу Ember, но на самом деле это то, что основная команда сообщала об этом в прошлом. . Ember постепенно движется к модели структуры пакетов, в которой пользователи смогут выбирать те части Ember, которые лучше всего соответствуют их потребностям, и при необходимости добавлять дополнительные основные функции. Вы можете увидеть начало этого в Разделении Ember на пакеты RFC и в ключевой заметке EmberConf 2017 от Тома и Иегуды.

Однако, когда вы удаляете все остальное, по сути, то, что делает современный Ember Ember, - это его компонентная система. Теоретически вы можете создать целое приложение, просто используя компоненты в application.hbs, и никогда не касаться ни одного файла route.js, controller.js или model.js - и я предполагаю, что это именно то, что мы делаем для нового введения в руководства Ember.

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

  • Компоненты с сохранением состояния / без состояния
  • Контейнерные / презентационные компоненты
  • Компоненты высшего порядка
  • Контекстные компоненты
  • Уступка (и определение общедоступного API для вашего компонента с выходами)

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

Услуги

Прежде чем я заявил, что каждая основная концепция в Ember, по сути, является либо компонентом, либо службой - давайте проверим это утверждение:

  • Маршруты - управляются внутренней службой маршрутизатора и теоретически необязательны. Выпускник Ember Алекс Матчнир недавно работал над новой службой маршрутизации на основе ограничений, которая показывает, что здесь определенно есть возможности для роста и, возможно, даже альтернативных реализаций.
  • Модели - создаются и управляются службой Ember Data store, которая автоматически вводится во многих местах, но является необязательной. Существуют альтернативные сервисы передачи данных, такие как Ember Apollo, Ember Redux и т. Д.
  • Контроллеры. Это одна из концепций, которая не вписывается ни в компонент, ни в службу, поскольку контроллеры также привязаны к шаблону, а службы в целом не имеют шаблона. Тем не менее, в конечном итоге контроллеры могут быть полностью удалены из структуры, но пока вы можете думать о них как о «службе, связанной с маршрутом».

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

Что такое службы?

Сервисы (и, что более важно, внедрение зависимостей) - это ответ Ember на вопрос «как мы храним долгосрочное состояние?» Компоненты сами по себе мощны, но одна из их самых сильных сторон также является одной из их слабостей - они временны. Как только компонент удаляется из DOM, его состояние исчезает навсегда.

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

Каждый фреймворк разработал какой-то ответ на сохранение долгосрочного состояния (некоторые из них, например, система Provider в React-Redux, на самом деле работают так же, как внутренние службы). Ember выбрала проверенное в боях решение Dependency Injection. Эта концепция имеет действительно отличную разбивку по сравнению с документацией Glimmer, и мы должны внести это в документацию Ember, чтобы укрепить понимание пользователями того, как работает фреймворк. Итак, я должен внести поправки в свое предыдущее утверждение - у вас не может быть Ember без компонентов или контейнера!

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

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

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

Стандартные службы Ember

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

Затем мы можем погрузиться в Ember Data и, возможно, другие решения для обработки данных (или дополнения для Ember Data, как только будет реализована RecordData), и показать пользователям, как они могут стандартизировать на уровне модели вместо простого использования $.ajax или fetch. Здесь также можно обсудить другие типы полезных сервисов, такие как решения для аутентификации и системы флагов функций, а также другие вещи, предоставляемые надстройками сообщества.

Связать все вместе

В конце концов, я считаю, что современный Ember проще, чем когда-либо. Рассматривая структуру через призму Component-Service, легко увидеть, как все сочетается друг с другом и как это можно разобрать. Ember легче предложить людям, которые предпочитают небольшие решения и постепенное внедрение, и его легче обучить новым пользователям. Он также подчеркивает наши сильные стороны как основы - Компоненты и DI - и не акцентирует внимание на аспектах, которые, хотя и актуальны и необходимы (Контроллеры), сначала сбивают с толку и делают Ember слабым на первый взгляд.

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

Раздел будущих гайдов на emberjs.com мог бы выглядеть примерно так:

Getting Started
Building a Todolist
Components
  What are Components?
  Defining Components
  Templates
  Arguments & Actions 
  Yielding
  Component Patterns
  ...
  
Services
  What are Services?
  Defining Services
  
  The Router Service
    Defining Routes
    Defining Controllers
    ...
  The Data Service
    Defining Models
    Finding Records
    Creating, Updating, and Deleting
    ...
  Other Services
  ...
The Object Model
Application Concerns
Testing
...

Самое лучшее в этом умственном сдвиге - это то, что это низко висящий плод, с которым может помочь каждый. Это не потребует серьезных изменений в структуре Ember - это просто изменит то, как мы говорим об этом и преподаем его сегодня!