Comments 64
Уже вторая статья о динамическом контенте и о том как не нужно писать с использованием angular.
есть встроенный тип Map…
вот только в JS типы существуют в своей области видимости и вы вполне можете его переопределить для своего модуля. Не вижу проблемы. Компилятор спокойно разрулит что Map в текущем скоупе это тот Map который мы откуда-то импортировали и ему не на что ругаться. Причем все даже явно.
А как делать всякие popup/modal сервисы без ComponentFactoryResolver и ComponentRef? Просто это то, что встречается везде. В каком направлении хотя бы копать?
В направлении более динамичных фреймворков :) Вот читаю я подобные статьи и не понимаю, зачем люди используют столь дубовые технологии.
1. Использовать Transclusion
2. Использовать вторичные роуты (якоря на заголовки на странице глючат, поэтом если вас перекинет не туда, сделайте поиск по странице: «Displaying multiple routes in named outlets»).
ViewContainerRef#createComponent?А вообще, я не знаю, плакать мне или смеяться, столько геморроя из-за такой простейшей фичи… С кучей ограничений — компонент нужно явно указать в entryComponents, в сервисе вы обязаны знать про интерфейс компонента, чтобы руками насовать ему инпутов, про аутпуты я вообще молчу, ручные подписки/отписки выглядят как заклинания по призыву дьявола. И все ради того, чтобы не писать на одной библиотеке для ui, ей богу, мир сошел с ума.
@ViewChild('foo', {read: ViewContainerRef}) foo;
В этой статье мы хотим рендерить компоненты в popup'ах, следовательно на его контейнер нужно сослаться. Сделать этого не вижу возможности, если Вы поможете, буду только благодарен!
Я пошел таким путем: попап явно умеет рендерить в нужное место у себя в шаблоне некий темплейт/компонент. Есть сервис со стримом этих компонентов, который используется в попапе. Собственно дальше понятно — инжектим сервис и пушим в стрим там, где надо.
Я считаю, что основная задача Фрейворка — дать структуру и порядок, а писать совсем все под фрейворк — не благодарная работа — во-первых производительность спорная (так же поступали с Ангуляр 1, а он вообще дикий тормоз тех годов), так они все еще так быстро меняются
Многие вещи действительно круто делать, управлять шаблонами, роутинг, сервисы, но переписывать то, что уже сделано тысячу раз — я, наверное, уже старый и хочу отдыхать, а не писать попапы всю свою жизнь на JS десятками способов.
на яваскрипте классикой такое запрограммировать легко
не путайте "легко" и "просто". Вопрос масштабов. Если мы делаем страничку с парой попапов — то да, это все избыточно. А если мы пишем большое приложение, то сделать один раз и потом просто подменять какой компонент выводим — это как раз таки дает ту самую легкость в сопровождении.
Другой вопрос что документация к тому же ангуляру этот вопрос в целом покрывает. И пример там более приближенный к реальности.
Я хотел бы обсудить желание все делать нативно, знаете, я сталкивался на первом ангуляре с таки: есть коменент, в нем десятки блочков, которые можно Драг и Дроп и тд, все это рисовалось методами Ангуляра путем напонения массива и его циклом в шаблоне, еще и форсили рендеринг, потому что тот не реагирован на каждое движение мышки — считаю, что подобные вещи просто странные.
— PS. Вы же не впервые работаете с картой, я обычно говорю «Ну сколько можно делать одно и тоже уже 10 лет» )))))
— на яваскрипте классикой такое запрограммировать легко
не путайте «легко» и «просто». Вопрос масштабов.
Вообще как-то не в тему, я разве говорил писать кашей колбасу? Разве при помощи js нельзя все сделать красиво через классы, методы и тд… Тем более, внутри компонента
Фреймворки меняются так быстро, как мода
Вот с 2012-ого года я особо изменений кардинальных не заметил. Есть изменения в деталях реализации, суть и идеи остаются теми же. В целом же больше имеет место цикличность.
Тут проблема в другом. Много хайпа. И этот хайп забивает людям голову. И они серьезно думают что "есть разница" на чем писать. Мало анализа, много "веры".
а бизнесу надо CRM делать не за 2 месяца, а за 2 недели
angular + material и будет сделано. Хотя я понимаю о чем вы. У меня был опыт сотрудничества с разработчиками которые эти 2 недели только webpack настраивали. Сотрудничество завершилось печально. Так же есть интересные метрики когда два разработчика делали задачи схожие по 24 часа, и еще один разработчик ту же задачу делал на тех же инструментах за 4 часа.
То есть повторюсь, возможно проблема в головах?
вылизывать код под фреймворк
это называется "пилить интеграцию". Представьте на секундочку что у нас вообще нет фреймворка, или мы используем сферический в вакууме фреймворк. И для решения конкретной задачи мы нашли какую-то библиотечку на github. Выглядит она слегка заброшенной и написана криво, но задачу с большего решает. Что вы выберите:
- размазать библиотечку повсюду, и потом тратить безумное количество времени когда вам придется заменять ее на что-то более подходящее (возможно написанное вами же, потому что задача специализированная и библиотек полностью удовлетворяющих требованиям не было)
- применить инверсию зависимостей, задекларировать контракт на уровне какого-то компонента/модуля, изолировать в рамках этого модуля работу с библиотекой для того что бы иметь пространство для маневра в будущем.
Более того, бездумно смешивать подходы тоже как-то не красиво. Мы же хотим какого-то единообразия если не во всем комьюнити (это остановит развитие на самом деле) — а хотя бы в пределах нашего проекта.
Разве при помощи js нельзя все сделать красиво через классы, методы и тд…
в js нет классов. Но это все лирика. Я плохо понимаю вашу позицию. Вы предлагаете отказаться от фреймворков вообще? Предлагаете делать дикий микс из angular и jquery без явного разделения и изоляции?
Как по мне — разработчики нынче плохо понимают идеи разделения ответственности, декомпозиции, не знают принципов проектирования, ведутся на хайп и все такое. Буквально недавно смотрел код одной команды, которая пилит проект на react. С таким пафосом они накидывали на то что angular это что-то плохое, а react это просто чудо из чудес, а потом другие ребята после них убирали тонны дублирования логики и выносили бизнес логику из UI компонентов.
С таким пафосом они накидывали на то что angular это что-то плохое, а react это просто чудо из чудес, а потом другие ребята после них убирали тонны дублирования логики и выносили бизнес логику из UI компонентов.С таким же пафосом и с пеной у рта просто все наперебой поют баллады «ангуляр для энтерпрайза!», «ангуляр для больших проектов!», «разделение ответственности!», «реакт
На выходе тот же говнокод, только на ровном месте в 10 раз сложнее.
Вы абсолютно правы насчет голов, но не правы, что абсолютно все ведутся на хайп. Разные инструменты по-разному
На выходе тот же говнокод, только на ровном месте в 10 раз сложнее.
я не отрицаю. Трэшачка на ангулярах тоже более чем предостаточно. Тут как бы опять же не от фреймворка зависит.
что абсолютно все ведутся на хайп.
в каком конкретно месте у меня была фраза "абсолютно все"?
Разные инструменты по-разному неудачно подходят к разным задачам.
это любимая фраза всех, вот только складывается впечатление что полезность этой фразы утеряна. Потому что что именно подразумевается под разными задачами как-то видимо до людей не доходит.
Такое ощущение, что кроме Ангуляра и Реакта выбирать больше не из чего.
Реакт — это тот самый случай, когда в проекте используется одна библиотека с "охватом и поддержкой" и 100500 прикрученных сбоку "либ-выскочек для маргиналов".
Реакт — это тот самый случай, когда модульность. Прям как у вас в $mol. Только вендоры разные, что ничего не меняет, так как ядро все-равно с «охватом и поддержкой», чего не скажешь о зоопарке всякой лабуды, появляющейся тут и там каждый день.
Вот не надо, так можно про что угодно.
Про высокоуровневый фреймворк ($mol, ExtJS, SAPUI5 и тп) вы такого сказать не сможете, ибо он содержит всё необходимое для создания приложения, а не только базовый каркас. Ангуляр — низкоуровневый. Реакт — вообще шаблонизатор.
Только вендоры разные, что ничего не меняет, чего не скажешь о зоопарке всякой лабуды, появляющейся тут и там каждый день.
Большинство этих вендоров не могут похвастаться "охватом и поддержкой". Так что ничем принципиально эта лабуда завязанная на реакте, не отличается от любой другой лабуды.
Но безумно говорить что фотошоп(чудо фраймворки будущего) лучше ангуляра или реакта. Реакт, нормальный и ангуляр тоже годный.
слегкостью
А на мол или эксджеес я смогу написать онлайн фотошоп или текстовый квест или интерактивный сайт или может быть я смогу с легкостью написать конструктор?
Сможете, почему нет? Разве что для рисования надо бы батареек завести.
Фреймворк низкого уровня предоставляет архитектуру, но не готовые решения на этой архитектуре.
Фреймворк высокого уровня — это набор готовых решений поверх этой архитектуры. Если какого-то решения для вашей задачи нет, то вы опускаетесь на уровень ниже и создаёте его.
Например, Ionic — высокоуровневый фреймворк на базе низкоуровневого Angular.
Это я к тому, что если Вы и хотите вставить красное словцо, то хотя бы объясняйте что это значит, чтобы читающие Вас поняли. В js нет понятия батарейка.
И это я к чему… Если на gui я могу наложить некие правила, которые ограничат мою архитектурную фантазию, то это самое правило касается и батареек-логики? Просто я могу представить, что gui реально можно вогнать в некие рамки, но с архитектурой логики это просто не возможно. Единственно возможный вариант, это введение плагинов-фасадов, за которыми будет скрываться такая архитектура на которую способен программист.
Но разве это не будет низкоуровнево? разве такое направление не породит армию инвалидов, которым будет лень даже думать?
В js нет понятия батарейка.
подозреваю что имеется ввиду способность вашего приложения выжирать батарею клиента.
JS нет смысла ругать, ибо он — данность, не зависящая от нашего выбора. Разумеется, лучше TS использовать для исходников.
Вы попробуйте к $mol приспособиться, там инфраструктурного кода куда меньше, хоть и на TS :-)
Я вроде бы дал чёткие определения уровней. Зачем вы утрируете?
И я повторю, что уровень выше angular, это тот уровень, который принуждает писать только шаблоны и только запросы выполненные в декларативном стиле (например xml или json). Заметьте, нет никакого кода.
Но если код, хотя бы запросов, нужно писать руками, то это уже ровно тот же уровень, что и angular ибо в angular код, который нужно написать для динамического приложения, это запросы.
Batteries Included (slang), in a product usability (mostly in software) it states that the product comes together with all possible parts required for full usability.
Вот с 2012-ого года я особо изменений кардинальных не заметил. Есть изменения в деталях реализации, суть и идеи остаются теми же.
Инертность мышления. Люди очень не охотно меняют свои привычки, поэтому, чтобы пробилось что-то по настоящему новое, нужна смена поколений.
И классы в яваскрипте уже есть :-)
Люди очень не охотно меняют свои привычки
Так проблема даже не столько в этом, сколько откуда эти привычки берутся.
И классы в яваскрипте уже есть :-)
Ну вы же меня поняли надеюсь?)
И классы в яваскрипте уже есть :-)Не классы, а недо-классы, с кастрированной функциональностью. Надо было разработчикам вместо этого прототипы упростить, хоть и есть шаг в эту сторону.
О какой функциональности речь?
В js/ts/c#/и_ко конструкторы не возвращают значение. Так что возможности ваши при вызове кода до базового конструктора ограничены только статичными полями, и такие трюки возможны только до момента появления class property initializers, так как они происходят как раз в конструкторах. Такое происходит во всех языках, не только в JS.
Так что классы как классы.
В JS/TS конструктор-таки может возвращать объект, который и будет далее использоваться в качестве this. Именно поэтому нельзя обращаться к this до вызова super.
class MyError extends Error {
constructor() {
super()
}
}
console.log( new MyError() instanceof MyError ) // falseclass MyError extends Error {
constructor() {
super()
Object.setPrototypeOf( this , MyError.prototype )
}
}
console.log( new MyError() instanceof MyError ) // trueВы можете достичь ровно того же в js, введя дополнительный наследуемый метод initialize.initialize не будет вызываться автоматический и о нем никто не знает (в отличие от конструктора), совсем не ровно тоже, а остальные «оправдания» — просто нюансы реализации.
Как результат этого ограничения — гибкость снижается, да можно выкрутиться с initialize или другим десятком способов — но это все костыли.
Во всех остальных языках (конечно же вы меня можете поправить) другая модель, про которую я написал выше. Вы не можете работать с классом до инициализации всей цепочки его базовых конструкторов, и это логично и правильно. Не понимаю, с чего вы решили, что наследование должно обязательно работать априори как в питоне.
Вы не уловили суть.Вы заблуждаетесь, вы погружаетесь в технические нюансы. На уровне разработчика, это работает в python и ruby (возможно много где), и не работает в js/c# вот и все.
Если вам будет легче, можно перефразировать «в js нет автоматической инициализации классов».
А правильно/не правильно — это субъективно.
не обязательно же график весь переносить на ангуляр
А в этой статье что-то подобное предлагается? я подобного не заметил. Изолируйте старичка jquery в отдельном компоненте и просто предоставьте интеграцию с остальным приложением и ничего страшного.
Вы можете взять любую библиотеку для работы с попапами, но у вас всеравно будет проблема инстанцирования компонентов в рантайме которую всеравно придется решать. И статья как раз об этом.
Я хотел бы обсудить желание все делать нативно
наверное потому что сейчас необходимость тянуть jquery для задач вроде графичков (где jquery по сути будет вам помогать добраться до svg элемента, что вполне можно сделать нативно с теми же трудозатратами) не особо то и нужен.
все это рисовалось методами Ангуляра путем напонения массива и его циклом в шаблоне
потому что мы как разработчики хотим рулить стэйтом а не DOM-ом. Ну или хотя бы так, что бы рулить этим всем надо было по отдельности а не вместе.
еще и форсили рендеринг
не рендринг а запускали $digest цикл возможно?
считаю, что подобные вещи просто странные.
Люди очень любят впадать в крайности. А еще есть культ карго. Это не фреймворков вина.
«потому что мы как разработчики хотим рулить стэйтом а не DOM-ом. » Ну это ведь звучит смешно, вы как разработчики должны хотеть, чтобы интерфейс был плавным, а не валился на средне бюджетной сони Xperia )
К тому же это тоже лирика, и еще раз, я не говорю, что это все ерунда, я это использую и тоже рулю стейтом, но не всегда это удобно, иногда такая рулежка стейтом приносит вред, а не пользу, все это не всегда «бесплатно»
Вы ответили на интересующий меня вопрос, вы сказали, что не страшно изолировать старичка — я спокоен, меня волновало отношение к этому вопросу )
что все фрейворки временные
потому ваша бизнес логика не должна зависеть от фреймворка. А срок жизни UI-ки вашего приложения чаще даже меньше чем срок жизни фреймворка.
а реально и через 2 года Ангуляр уже будет шататься на своих позициях (он уже шатается).
То есть мы возвращаемся к теме хайпа вместо выбора инструментов? Ну ок. Да и любопытно почему же он шатается.
чтобы интерфейс был плавным, а не валился на средне бюджетной сони Xperia )
Так он и не валится.
но не всегда это удобно
ну когда речь о стэйте DOM-а проще сразу DOM-ом рулить, кто ж спорит.
иногда такая рулежка стейтом приносит вред
тут стоит конкретизировать что вы имеете ввиду под "такой рулежкой". Любую задачу можно решить как хорошо так и плохо. Фреймворки не особо регламентируют или форсируют определенные решения задач. Тут другой момент, и я помню на себе это прочувствовал лет 5 назад. Читаешь ты такой документацию, все красиво. И вот тебе пример кода где в маленький снипет всунули неплохой кусок логики для демонстрации возможностей. Вот только никто в этой самой доке не дописывал "не делайте так, это лишь для демонстрации, по хорошему вы должны бизнес логику вынести туда-то, взаимодействие с сетью — в отдельную штуку, а вот эта штука с формами — тут можно сделать так и так но это чуть больше кода и сильно усложнит пример".
А потом открываешь проекты через год и там все те же примеры из доки… размазанные повсюду. Потому что зачем разбираться?
p.s. я не сказать что фронтэндщик, просто приходится иногда писать фронтэнды для своих бэкэндов. И на бэкэнде примерно те же проблемы. Кучи фреймворков, холивары, хайп, кругом микросервисы, никто не пишет тесты, никто не хочет разбираться в принципах. Все ваяют контроллеры.
И еще меня мучает такой вопрос. Можно ли с сервера прислать html, в котором будут, например, ссылки с директивой routerLink, отобразить его и заставить работать директивы?
2) Думаю, что можно. Первое решение, которое пришло в голову: получаем с сервера html, подкидываем её в компонент, там прикрепляем её к темплейту и динамически создаем этот компонент. Думаю, должно сработать. Скорее всего есть более элегантное решение.
Динамический рендеринг компонентов в Angular 2