[Из песочницы] Динамический рендеринг компонентов в Angular 221.06.2017 04:18

Комментарии (19)

  • 20 июня 2017 в 18:57

    +2

    ↑

    ↓

    Если в сервисе есть ссылка на представление, значит что-то пошло не так.
    Уже вторая статья о динамическом контенте и о том как не нужно писать с использованием angular.

    • 20 июня 2017 в 19:11

      0

      ↑

      ↓

      И какой умник придумал тип Map? Я не верю в то, что компилятор не умолял переименовать тип, так как в js и ts есть встроенный тип Map…

      • 20 июня 2017 в 23:01

        –1

        ↑

        ↓

        есть встроенный тип Map…

        вот только в JS типы существуют в своей области видимости и вы вполне можете его переопределить для своего модуля. Не вижу проблемы. Компилятор спокойно разрулит что Map в текущем скоупе это тот Map который мы откуда-то импортировали и ему не на что ругаться. Причем все даже явно.

    • 20 июня 2017 в 21:28

      0

      ↑

      ↓

      А как делать всякие popup/modal сервисы без ComponentFactoryResolver и ComponentRef? Просто это то, что встречается везде. В каком направлении хотя бы копать?

      • 21 июня 2017 в 03:23

        0

        ↑

        ↓

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

  • 20 июня 2017 в 19:34

    +1

    ↑

    ↓

    А почему не стали использовать более более подходящий для этого ViewContainerRef#createComponent?

    А вообще, я не знаю, плакать мне или смеяться, столько геморроя из-за такой простейшей фичи… С кучей ограничений — компонент нужно явно указать в entryComponents, в сервисе вы обязаны знать про интерфейс компонента, чтобы руками насовать ему инпутов, про аутпуты я вообще молчу, ручные подписки/отписки выглядят как заклинания по призыву дьявола. И все ради того, чтобы не писать на одной библиотеке для ui, ей богу, мир сошел с ума.

  • 20 июня 2017 в 23:10

    0

    ↑

    ↓

    Не знаю, стоит ли этот труд времени, на яваскрипте классикой такое запрограммировать легко, я это выношу в отдельные библиотеки, не сервисы, которые потом использую и в ember и в Angular

    Я считаю, что основная задача Фрейворка — дать структуру и порядок, а писать совсем все под фрейворк — не благодарная работа — во-первых производительность спорная (так же поступали с Ангуляр 1, а он вообще дикий тормоз тех годов), так они все еще так быстро меняются

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

    • 20 июня 2017 в 23:18

      0

      ↑

      ↓

      на яваскрипте классикой такое запрограммировать легко

      не путайте «легко» и «просто». Вопрос масштабов. Если мы делаем страничку с парой попапов — то да, это все избыточно. А если мы пишем большое приложение, то сделать один раз и потом просто подменять какой компонент выводим — это как раз таки дает ту самую легкость в сопровождении.


      Другой вопрос что документация к тому же ангуляру этот вопрос в целом покрывает. И пример там более приближенный к реальности.

      • 20 июня 2017 в 23:23

        0

        ↑

        ↓

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

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

        • 20 июня 2017 в 23:29 (комментарий был изменён)

          0

          ↑

          ↓

          Добавлю, вот вы трудитесь на большой проект впервые и последний раз? (Риторический вопрос), Ангуляр уйдет из бизнеса, а Javascript останется и где унификация разработки? Фреймворки меняются так быстро, как мода, и это даже просто стильно, а бизнесу надо CRM делать не за 2 месяца, а за 2 недели, а с подобными подходами — вылизывать код под фреймворк, чтобы было красиво — далеко не уплывешь, теперь надо все сидеть и вылизывать под Vue?)

          — PS. Вы же не впервые работаете с картой, я обычно говорю «Ну сколько можно делать одно и тоже уже 10 лет»)))))

          — на яваскрипте классикой такое запрограммировать легко
          не путайте «легко» и «просто». Вопрос масштабов.

          Вообще как-то не в тему, я разве говорил писать кашей колбасу? Разве при помощи js нельзя все сделать красиво через классы, методы и тд… Тем более, внутри компонента

          • 20 июня 2017 в 23:52

            0

            ↑

            ↓

            Фреймворки меняются так быстро, как мода

            Вот с 2012-ого года я особо изменений кардинальных не заметил. Есть изменения в деталях реализации, суть и идеи остаются теми же. В целом же больше имеет место цикличность.


            Тут проблема в другом. Много хайпа. И этот хайп забивает людям голову. И они серьезно думают что «есть разница» на чем писать. Мало анализа, много «веры».


            а бизнесу надо CRM делать не за 2 месяца, а за 2 недели

            angular + material и будет сделано. Хотя я понимаю о чем вы. У меня был опыт сотрудничества с разработчиками которые эти 2 недели только webpack настраивали. Сотрудничество завершилось печально. Так же есть интересные метрики когда два разработчика делали задачи схожие по 24 часа, и еще один разработчик ту же задачу делал на тех же инструментах за 4 часа.


            То есть повторюсь, возможно проблема в головах?


            вылизывать код под фреймворк

            это называется «пилить интеграцию». Представьте на секундочку что у нас вообще нет фреймворка, или мы используем сферический в вакууме фреймворк. И для решения конкретной задачи мы нашли какую-то библиотечку на github. Выглядит она слегка заброшенной и написана криво, но задачу с большего решает. Что вы выберите:


            • размазать библиотечку повсюду, и потом тратить безумное количество времени когда вам придется заменять ее на что-то более подходящее (возможно написанное вами же, потому что задача специализированная и библиотек полностью удовлетворяющих требованиям не было)
            • применить инверсию зависимостей, задекларировать контракт на уровне какого-то компонента/модуля, изолировать в рамках этого модуля работу с библиотекой для того что бы иметь пространство для маневра в будущем.

            Более того, бездумно смешивать подходы тоже как-то не красиво. Мы же хотим какого-то единообразия если не во всем комьюнити (это остановит развитие на самом деле) —, а хотя бы в пределах нашего проекта.


            Разве при помощи js нельзя все сделать красиво через классы, методы и тд…

            в js нет классов. Но это все лирика. Я плохо понимаю вашу позицию. Вы предлагаете отказаться от фреймворков вообще? Предлагаете делать дикий микс из angular и jquery без явного разделения и изоляции?


            Как по мне — разработчики нынче плохо понимают идеи разделения ответственности, декомпозиции, не знают принципов проектирования, ведутся на хайп и все такое. Буквально недавно смотрел код одной команды, которая пилит проект на react. С таким пафосом они накидывали на то что angular это что-то плохое, а react это просто чудо из чудес, а потом другие ребята после них убирали тонны дублирования логики и выносили бизнес логику из UI компонентов.

            • 21 июня 2017 в 00:04 (комментарий был изменён)

              0

              ↑

              ↓

              С таким пафосом они накидывали на то что angular это что-то плохое, а react это просто чудо из чудес, а потом другие ребята после них убирали тонны дублирования логики и выносили бизнес логику из UI компонентов.
              С таким же пафосом и с пеной у рта просто все наперебой поют баллады «ангуляр для энтерпрайза!», «ангуляр для больших проектов!», «разделение ответственности!», «реакт для хипстеров ничего не может!»
              На выходе тот же говнокод, только на ровном месте в 10 раз сложнее.
              Вы абсолютно правы насчет голов, но не правы, что абсолютно все ведутся на хайп. Разные инструменты по-разному неудачно подходят к разным задачам.

              • 21 июня 2017 в 00:26

                0

                ↑

                ↓

                На выходе тот же говнокод, только на ровном месте в 10 раз сложнее.

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


                что абсолютно все ведутся на хайп.

                в каком конкретно месте у меня была фраза «абсолютно все»?


                Разные инструменты по-разному неудачно подходят к разным задачам.

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

              • 21 июня 2017 в 03:59

                0

                ↑

                ↓

                Такое ощущение, что кроме Ангуляра и Реакта выбирать больше не из чего.

            • 21 июня 2017 в 03:58

              0

              ↑

              ↓

              Вот с 2012-ого года я особо изменений кардинальных не заметил. Есть изменения в деталях реализации, суть и идеи остаются теми же.

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


              И классы в яваскрипте уже есть :-)

        • 20 июня 2017 в 23:36 (комментарий был изменён)

          0

          ↑

          ↓

          не обязательно же график весь переносить на ангуляр

          А в этой статье что-то подобное предлагается? я подобного не заметил. Изолируйте старичка jquery в отдельном компоненте и просто предоставьте интеграцию с остальным приложением и ничего страшного.


          Вы можете взять любую библиотеку для работы с попапами, но у вас всеравно будет проблема инстанцирования компонентов в рантайме которую всеравно придется решать. И статья как раз об этом.


          Я хотел бы обсудить желание все делать нативно

          наверное потому что сейчас необходимость тянуть jquery для задач вроде графичков (где jquery по сути будет вам помогать добраться до svg элемента, что вполне можно сделать нативно с теми же трудозатратами) не особо то и нужен.


          все это рисовалось методами Ангуляра путем напонения массива и его циклом в шаблоне

          потому что мы как разработчики хотим рулить стэйтом, а не DOM-ом. Ну или хотя бы так, что бы рулить этим всем надо было по отдельности, а не вместе.


          еще и форсили рендеринг

          не рендринг, а запускали $digest цикл возможно?


          считаю, что подобные вещи просто странные.

          Люди очень любят впадать в крайности. А еще есть культ карго. Это не фреймворков вина.

          • 21 июня 2017 в 00:05

            –1

            ↑

            ↓

            Вы слишком радикально меня воспринимаете, я за Фреймворки, я лишь утверждаю — что все фрейворки временные, и не философски, а реально и через 2 года Ангуляр уже будет шататься на своих позициях (он уже шатается).

            «потому что мы как разработчики хотим рулить стэйтом, а не DOM-ом.» Ну это ведь звучит смешно, вы как разработчики должны хотеть, чтобы интерфейс был плавным, а не валился на средне бюджетной сони Xperia)

            К тому же это тоже лирика, и еще раз, я не говорю, что это все ерунда, я это использую и тоже рулю стейтом, но не всегда это удобно, иногда такая рулежка стейтом приносит вред, а не пользу, все это не всегда «бесплатно»

            Вы ответили на интересующий меня вопрос, вы сказали, что не страшно изолировать старичка — я спокоен, меня волновало отношение к этому вопросу)

            • 21 июня 2017 в 00:35

              0

              ↑

              ↓

              что все фрейворки временные

              потому ваша бизнес логика не должна зависеть от фреймворка. А срок жизни UI-ки вашего приложения чаще даже меньше чем срок жизни фреймворка.


              а реально и через 2 года Ангуляр уже будет шататься на своих позициях (он уже шатается).

              То есть мы возвращаемся к теме хайпа вместо выбора инструментов? Ну ок. Да и любопытно почему же он шатается.


              чтобы интерфейс был плавным, а не валился на средне бюджетной сони Xperia)

              Так он и не валится.


              но не всегда это удобно

              ну когда речь о стэйте DOM-а проще сразу DOM-ом рулить, кто ж спорит.


              иногда такая рулежка стейтом приносит вред

              тут стоит конкретизировать что вы имеете ввиду под «такой рулежкой». Любую задачу можно решить как хорошо так и плохо. Фреймворки не особо регламентируют или форсируют определенные решения задач. Тут другой момент, и я помню на себе это прочувствовал лет 5 назад. Читаешь ты такой документацию, все красиво. И вот тебе пример кода где в маленький снипет всунули неплохой кусок логики для демонстрации возможностей. Вот только никто в этой самой доке не дописывал «не делайте так, это лишь для демонстрации, по хорошему вы должны бизнес логику вынести туда-то, взаимодействие с сетью — в отдельную штуку, а вот эта штука с формами — тут можно сделать так и так, но это чуть больше кода и сильно усложнит пример».


              А потом открываешь проекты через год и там все те же примеры из доки… размазанные повсюду. Потому что зачем разбираться?


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

              • 21 июня 2017 в 04:12

                0

                ↑

                ↓

                Фреймворки не особо регламентируют или форсируют определенные решения задач.

                Низкоуровневые не форсируют. Высокоуровневые ещё как форсируют.

© Habrahabr.ru