Комментарии 10
К сожалению, автор сам не до конца понимает solid и подмешивает одно к другому.
При этом игнорирует или не понимает принцип черного ящика, инкапсуляции и тд.
А так же не до конца понимает, что шаблоны созданы, чтобы иметь возможность динамически подмешивать часть (или даже объёмную часть) в шаблон, которая или что-то отрисует в ожидаемом месте или даже чтото сделает в не рамках логики исходного компонента.
При том упоминается бизнес логика, которой на самом деле нет..
Контекст понятен. Мнения конечно могут и будут разделяться, ведь нет предела в совершенстве, а увидеть подходы и точки зрения интересно. Буду ждать следующего поста от вас.
Подобных статей писать не надо. Однозначно минус. Название не соответствует содержанию.
Из примера так и не понял почему одно лучше другого. Для меня выглядят как инструменты для решения немного разных задач. По крайней мере, я обычно разделяю задачи построения лейаута и передачи данных. Иногда эти задачи, конечно, тесно сплетаются, взять например реактивные формы, или таблицы из cdk и прочее. Но такой декларативный подход далеко не всегда уместен, и зачастую сложнее в реализации и поддержке (тут можно обратиться к исходникам тех же форм и таблиц).
upd: заглянул в документацию primeng, там для кнопки можно передать и различные виды темплейтов: https://primeng.org/button#template , https://primeng.org/button#api.button.templates , то есть поле label не обязательное.
Ну, я написал, что технически все варианты имеют место для жизни. Просто много проработал с Primeng и когда встает вопрос кастомизации (а мы все знаем, как заказчик может сказать, что он хочет), то вот тут вот с возникают проблемы. Да, в кнопку можно передать свой темплейт, но сделано это немного криво. Там инкапсуляцию тогда надо отключать. Может уже поправили, но раньше так было.
Ну и опять же. Я не претендую на истину в последней инстанции. ))
До сих пор понять не могу прикол Ангуляра в данном случае. Ну не нужен тебе children, так будь добр - выкинь завершающий тег. Столько бойлерплейта....
Добрый день.
Подскажите, пожалуйста, почему всё время в Хабр с важным видом обсуждают темы лекций 2-3 курса обычных технических ВУЗ-ов?
Это люди не учились и так по кусочкам хотят наесться? Так известно, что так не получится. Академичесность образования основывается на двух простых, важных и неотъемлемых принципах. Тут оба нарушены вдребезги с ноги.
А ещё засилие англицизмов делает текст иногда непонятным, а иногда многозначным в понимании
Сначала хотел позубоскалить над качеством статьи, но потом понял, что у автора хотя бы есть смелость и стремление что-то публиковать.
Поэтому сразу перейду к конструктиву:
1) Эта "возможность" Angular называется проекция контента. Хотя бы в тэги это следовало добавить.
2) Слишком много слов. Всю статью можно сократить до одного предложения: "Не добавляйте инпут в компонент, если можно обойтись проекцией контента".
3) Мало ценности для целой статьи.
Лучше собрать топ 10 или даже 5 таких тем из собственного опыта, когда разработчики, по вашему мнению, не используют все возможности Angular или используют их неправильно, и провести рассуждения на эту тему.
Интересный взгляд на ng-content. Но в реальной жизни не уверен, что кто-то будет этим заморчиваться. Выхлопа немного будет, на мой взгляд, а читаемость кода усложняется с кучей ng-content в разы, ИМХО. Даже в простеньком примере, который здесь приведен, черт ногу сломит. Что уж говорить про что-то более реальное.
Но, повторюсь, взгляд интересный. И за это спасибо!
Публикации
Использование возможностей Angular. Часть 1