Как стать автором
Обновить

Комментарии 17

Ваша статья не содержит слов Service, Rx, EventEmittir, dispatch, emit, а это означает что читать её вредно, так как она может навредить не сформировавшимся личностям.
Допустил опечатку EventEmittir -> EventEmitter, но сути не меняет, просто уточнил.
Хочу добавить, что для понятия angular, нужно научится понимать архитектуру приложения в виде слоев.
Для примера в последнее время, очень часто о реакте пишут, что flux это тот же mvc, хотя flux это архитектурный слой view компонентов и ни о каком mvc речи там быть не может. Вот если взять связь между слоями-городами, то это будет либо железная дорога, либо самолеты. Но слой view, чем являются компоненты + логика которую они содержат, это слой-город. И это нужно понимать буквально, ведь то что поезда быстрее машин не означает что нам нужно отказаться от машин и добираться до соседнего квартала на самолете.
Это первый шаг к постижения mvcs архитектуры, view у которой построена на компонентах (ещё может быть на слоях shape, но это другая история, я об этом сказал просто для справки).
mvcs, это mvc + service. Да, это не прошлый век, а все ещё самая лучшая архитектура приложения и таковой она и будет до конца программирования в том виде, в котором мы его знаем сейчас. Все статьи, которые гласят что это не так, неправы, ведь они так же как и эта, ошибочны и все дело в том, что mvc пытаются засунуть не на тот слой.
Опять мысль упустил :) Я все это к чему, да к тому, что в service архитектуре вся логика приложения, а также логика компонентов выносится в сервисный слой, который в данной статье полностью отсутствует. А само создание компонента-popup или tooltip должно происходить в худшем случаи по вызову метода сервиса, а в лучшем по событию. Но ничего этого нет.
Статья построена по принципу «от простого к сложному» и если дочитать ее до конца, то можно увидеть пример где добавление компонента в DOM происходит из сервиса.
Да Вы правы, ознакомление с материалом я всегда начинаю с беглого просмотра и если что не читаю.
И да Вы правы, у Вас есть упоминание о сервисе —
Теперь у нас есть компонент и нам осталось понять, как вставить его в DOM из сервиса.

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

Здесь одно из двух — либо Вы хотите добавить компонент из сервиса, либо передать компонент при помощи сервиса. Оба варианта в корне неправильны, а подкрепление картинкой, которая гласит что с помощью angular простые вещи выглядят как недоразумение, это вообще ни в какие рамки не лезет.
Любой создаваемый проект не обходится без динамического создания элементов. Рано или поздно вам понадобится либо создать tooltip для элемента, показать модальное окно, или вовсе сформировать некоторые блоки динамически подгружая их с сервера.

Всегда считал это дичайшем костылем, когда часть интерфейса грузится с сервера.
А как делать плагинную систему по другому? В нашем проекте с сервера мы грузим плагины в виде ангуляровских модулей.
Забавно слышать слово плагин в контексте веб разработки, а именно разработки SPA приложений… Это вообще как?
Легко. Например у Вас есть enterprise приложение, которое расширяется плагинами. Пример такого — Jira от atlassian. У нас такая же ситуация — хочет клиент модуль отчетности — ставится сервис на бэк и плагин в GUI.
в первом примере нужно template вместо templateUrl
Спасибо, исправил.
При решении таких задач я зачастую определяю зрелость фреймворка, который использую: насколько просто я могу в нем создавать динамический контент
С учетом того, сколько кода нужно писать, я бы назвал ангуляр перезрелым.
Я не хочу доказывать что лучше, а что хуже, но скажу так — я давно пишу на реакте + typescript и могу сказать не по наслышке, по объему кода angular не отличается от react. Те же компоненты, те же шаблоны, те же библиотеки.
Все зависит от того, кто пишет код.
Тут уже были шаблонизируемые компоненты для angular 2, если сравнить объем кода: ~250 строк для Angular 2, и 30 строк для Angular Light.
Что то подход оооочень смахивает на Jquery. Это ж не наш метод :-)
А кто-то сталкивался с ошибкой «createEmbeddedView is not a function» при попытке this.viewContainerRef.createEmbeddedView(this.tpl);?
Зарегистрируйтесь на Хабре , чтобы оставить комментарий