Ещё можно использовать flux-паттерн (к примеру, ngrx), хотя это kind of services
Так же можно что-то пробрасывать через @Attribute(), а не только Input()
Через FactoryResolver задать пропсы компонента напрямую.
Крайне экзотические [возможно, антипаттерны], которые видел на практике
У @ContentChild/@ContentChildren задать публичные свойства, тогда компонент-контейнер может смотреть в них. Использовалось внутри какой-то библиотечной пробрасываемой-директивы, чтобы избежать аналогичного биндинга для компонента
Ну, и как же без хранения в глобальной области видимости + declare, хотя такой подход возможен в рамках абсолютно любого фреймворка. Этот "шедевр" использовался вместе с ssr
Первым аргументом в trackBy идёт index, а вторым уже сам иттерируемый item (в stackblitz).
По делу вот 2 вопроса:
1. Почему не использовать virtualScroll? В примере высота элементов «статичная», cdk с этим рендерингом справится легко, не отрисовывая элементы заранее.
2. Если по какой-то причине virtualScroll всё же не подходит, то почему не использовать lazyScroll?
Обращаю внимание на эти вопросы, т.к. когда-то давно тоже хотел было реализовать аналогичную идею, но не смог на них ответить и отказался.
Если на выходе получается "FizzBuzz Enterprise" -- это означает, что у кандидата/разработчика нет понимание того, что и зачем он делает, какую проблему решает и т.д. и т.п
Само по себе знание паттернов тут не причём, имхо. Мне не кажется правильным обвинять микроскоп в том, что кто-то забивает им гвозди
Можно пример такой "небанальной" задачи, ради которой мне нужно лезть разбираться в кишках ангуляра? А то, вот буду сидеть теперь и думать о том, какой же я банальный разработчик, банально решающий банальные задачи)
Кроме шуток, не пойму о чем идет дискуссия - я изначально сказал, что cdr и zone - это сложность фреймворка, мол, даже с публичным интерфейсом из 5 методов, надо поразбираться по началу.
Думаю вам это очевидно просто в силу того, что у вас не было желания/необходимости копнуть чуть глубже
Так я ж про публичный интерфейс говорю, понятно, что внутри сложная инкрементальная проверка через всякие побитовые сравнения. Да, на практики у меня необходимости в этом знании не было.
"rx""изящно"
Выберите что-то одно.
Ну тут уж дело практики, кмк. Ну либо можно пример того кода с rx, который написан приемлимо, и при этом, если переписать его без использования этой либы, он будет гораздо лучше?
angular 2 никогда не был встраевымым, ничего не изменилось к текущему моменту, и, мне кажется, никогда не изменится - из пушки по воробьям не стреляют) В кейсах, когда нужно что-то среднего объема поднять сам я использую vue.
А про бэкграунд с .net -- это, разумеется, хорошо подмечено. Многие разработчики с базой в виде c# или java легко вкатываются в этот фреймворк.
Самая большая - сложность обучения, из-за которой многие негативно относятся к этой платформе:
Непрозрачность того, как работает cdr и zone [ну многие так говорят, хотя мне кажется, что это очевидные вещи какие-то]
Такие штуки, как DI и rx - это сложно, хотя я уже представить не могу, как без этих штуковин (паттернов) решать свои задачи настолько же изящно
Что еще за модули? Гарды и резолверы?! Пайпы?!!!! - я тута тока реакт-комопнент-писака, не понимац, надо тока компонент, остальное сложна (сорри, что упомянул реакт как будто в негативном ключе - это наоборот круто, что в реакте можно обходиться без лишних сущностей)
Наверно, что-то еще (и даже много), но я уже не могу сказать, что сложно, а что просто, надо спросить у тех, кто пробует войти в ангуляр
Как следствие популярность инструмента падает, сообщество растет медленно, меньше готовых решений. Кроме того сейчас многие перешли на "функциональную" парадигму, и вот есть такая либа как twilio -- в ООП она прям плохо вписывается, хотя это дико популярный инструмент для видео-аудио-звонков.
Остальное мелочи, к примеру:
Почему нет типов на ngOnChanges?
Почему нет типов на Provider?
Почему нет типов у FormControl?
Почему нельзя стилизовать диррективу?
Как мне пробросить аттрибуты на дочерний шаблон так же красиво, как во vue или react?
В качестве расширения комопнентов есть только наследование, а вот всякие крутые решения по типу composition api (vue) или hooks (react) -- отсуствуют;
В ssr нет возможности проставить custom-property (css);
А можно какую-то обоснованную критику ангулара-то? Пишу на нем уже года три, а тут оказывается его выбросить нужно. До этого писал на реакте и знаю его очень неплохо, а недавно делал тестовое на vue - и то, и другое тоже хорошо, но чтоб прям принципиально лучше ангуляра - даже близко не представляю о чем речь. Вернее, есть пару претензий к ангуляру, но, как правило, чтобы их назвать нужно очень глубоко знать фреймворк, и те, кто выдает такие комментарии, обычно ничего перечислить не могут
Что такое «сложное»-бизнес приложение? Каждый эту формулировку понимает по своему, и уже это подобный спор делает довольно бессмысленным.
Когда появился первый ангуляр, эта концепция не была популяризирована во фронтенде. Как же без неё обходились? Или сложные приложения не разрабатывались?
Если отбросить web и подойти с подобной темой к разработчикам других клиентов, у которых абсолютно другой бэкграунд, то станет очевидно, что это просто прием, к которому не нужно относиться с фанатизмом, к чему я всех и призываю :)
Вмешаюсь в спор, а то, судя по всему, тут начинается холливар.
После нескольких попыток построить сложные бизнес приложения понял, что RxJS и сервисов — мало… state management тоже обязателен
Выделенное звучит как-то безапелляционно.
Согласитесь, что flux-паттерн — это всего лишь «прием», как и любой другой паттерн.
Странно утверждать, к примеру, следующее: «без паттерна адаптер нельзя построить сложное приложение». Ведь можно?
С учётом вышесказанного, легко сделать вывод: в каких-то приложениях некий паттерн может не применяться. Тогда можем ли мы написать фронтенд-приложение без стейтменеджмента, что по сути является flux-паттерном? Можем.
Другое дело, что сейчас стейтменеджмент стал стандартом во фронтенде, и он действительно помогает решать задачи единообразно. Это круто по многим причинам, и должна быть довольно веская и, вероятно, специфичная причина, чтобы пренебрегать подобными тулзами.
Считаю, что упомянуть в статье концепцию стейтменеджмента стоило, добавив про ngrx/ngxs и прочее. Думаю, что инициатор ветки именно это и имел в виду, однако, в ответе ему справедливо добавили, что это всё же необязательное условие.
Признаться, я даже не тыкался в эту библиотеку, поэтому не могу сказать, как оно на «практике», но, уверен, что каждый, кто прочитал эту статью, легко разобрался, что делает конкретно эта строка.
Нет, почему же умер? Развивается и всё с ним хорошо, судя по публикациям.
Alpine.js — это альтернатива jQuery, используется как простая библиотека (с рекомендованным способом подключения через CDN !), в то время, как svelte требует компиляции и имеет гораздо более богатое API.
Не в противовес комментарию, но слегка смутило слово "драгоценные". Оставлю здесь цены на токены, чтобы порядок цен был понятен:
Input: $0.0015 / 1K tokens1 токен - это примерно 1 слово.
https://openai.com/pricing
Из разряда "поброса" данных в компоненты:
По делу вот 2 вопроса:
1. Почему не использовать virtualScroll? В примере высота элементов «статичная», cdk с этим рендерингом справится легко, не отрисовывая элементы заранее.
2. Если по какой-то причине virtualScroll всё же не подходит, то почему не использовать lazyScroll?
Обращаю внимание на эти вопросы, т.к. когда-то давно тоже хотел было реализовать аналогичную идею, но не смог на них ответить и отказался.
Хочу всё-таки немного поспорить с такой позицией.
Если на выходе получается "FizzBuzz Enterprise" -- это означает, что у кандидата/разработчика нет понимание того, что и зачем он делает, какую проблему решает и т.д. и т.п
Само по себе знание паттернов тут не причём, имхо. Мне не кажется правильным обвинять микроскоп в том, что кто-то забивает им гвозди
Можно пример такой "небанальной" задачи, ради которой мне нужно лезть разбираться в кишках ангуляра? А то, вот буду сидеть теперь и думать о том, какой же я банальный разработчик, банально решающий банальные задачи)
Кроме шуток, не пойму о чем идет дискуссия - я изначально сказал, что cdr и zone - это сложность фреймворка, мол, даже с публичным интерфейсом из 5 методов, надо поразбираться по началу.
Так я ж про публичный интерфейс говорю, понятно, что внутри сложная инкрементальная проверка через всякие побитовые сравнения. Да, на практики у меня необходимости в этом знании не было.
Ну тут уж дело практики, кмк. Ну либо можно пример того кода с rx, который написан приемлимо, и при этом, если переписать его без использования этой либы, он будет гораздо лучше?
angular 2 никогда не был встраевымым, ничего не изменилось к текущему моменту, и, мне кажется, никогда не изменится - из пушки по воробьям не стреляют) В кейсах, когда нужно что-то среднего объема поднять сам я использую vue.
А про бэкграунд с .net -- это, разумеется, хорошо подмечено. Многие разработчики с базой в виде c# или java легко вкатываются в этот фреймворк.
Самая большая - сложность обучения, из-за которой многие негативно относятся к этой платформе:
Непрозрачность того, как работает cdr и zone [ну многие так говорят, хотя мне кажется, что это очевидные вещи какие-то]
Такие штуки, как DI и rx - это сложно, хотя я уже представить не могу, как без этих штуковин (паттернов) решать свои задачи настолько же изящно
Что еще за модули? Гарды и резолверы?! Пайпы?!!!! - я тута тока реакт-комопнент-писака, не понимац, надо тока компонент, остальное сложна (сорри, что упомянул реакт как будто в негативном ключе - это наоборот круто, что в реакте можно обходиться без лишних сущностей)
Наверно, что-то еще (и даже много), но я уже не могу сказать, что сложно, а что просто, надо спросить у тех, кто пробует войти в ангуляр
Как следствие популярность инструмента падает, сообщество растет медленно, меньше готовых решений. Кроме того сейчас многие перешли на "функциональную" парадигму, и вот есть такая либа как twilio -- в ООП она прям плохо вписывается, хотя это дико популярный инструмент для видео-аудио-звонков.
Остальное мелочи, к примеру:
Почему нет типов на ngOnChanges?
Почему нет типов на Provider?
Почему нет типов у FormControl?
Почему нельзя стилизовать диррективу?
Как мне пробросить аттрибуты на дочерний шаблон так же красиво, как во vue или react?
В качестве расширения комопнентов есть только наследование, а вот всякие крутые решения по типу composition api (vue) или hooks (react) -- отсуствуют;
В ssr нет возможности проставить custom-property (css);
А можно какую-то обоснованную критику ангулара-то? Пишу на нем уже года три, а тут оказывается его выбросить нужно. До этого писал на реакте и знаю его очень неплохо, а недавно делал тестовое на vue - и то, и другое тоже хорошо, но чтоб прям принципиально лучше ангуляра - даже близко не представляю о чем речь. Вернее, есть пару претензий к ангуляру, но, как правило, чтобы их назвать нужно очень глубоко знать фреймворк, и те, кто выдает такие комментарии, обычно ничего перечислить не могут
Кстати, чисто из любопытства вопрос появился: чейнинг нарушает LoD?
Разницу понимаю.
Задал наводящие вопросы, чтоб и этот аспект осветили, а то как-то не понятно, что делать с этой информацией.
А можно ли из программиста перейти в инженеры? И что для этого нужно? Опыт или что-то другое?
Когда появился первый ангуляр, эта концепция не была популяризирована во фронтенде. Как же без неё обходились? Или сложные приложения не разрабатывались?
Если отбросить web и подойти с подобной темой к разработчикам других клиентов, у которых абсолютно другой бэкграунд, то станет очевидно, что это просто прием, к которому не нужно относиться с фанатизмом, к чему я всех и призываю :)
Выделенное звучит как-то безапелляционно.
Согласитесь, что flux-паттерн — это всего лишь «прием», как и любой другой паттерн.
Странно утверждать, к примеру, следующее: «без паттерна адаптер нельзя построить сложное приложение». Ведь можно?
С учётом вышесказанного, легко сделать вывод: в каких-то приложениях некий паттерн может не применяться. Тогда можем ли мы написать фронтенд-приложение без стейтменеджмента, что по сути является flux-паттерном? Можем.
Другое дело, что сейчас стейтменеджмент стал стандартом во фронтенде, и он действительно помогает решать задачи единообразно. Это круто по многим причинам, и должна быть довольно веская и, вероятно, специфичная причина, чтобы пренебрегать подобными тулзами.
Считаю, что упомянуть в статье концепцию стейтменеджмента стоило, добавив про ngrx/ngxs и прочее. Думаю, что инициатор ветки именно это и имел в виду, однако, в ответе ему справедливо добавили, что это всё же необязательное условие.
По большей части верное замечание, однако автор, вероятно, имел в виду следующие кейсы:
Признаться, я даже не тыкался в эту библиотеку, поэтому не могу сказать, как оно на «практике», но, уверен, что каждый, кто прочитал эту статью, легко разобрался, что делает конкретно эта строка.
Alpine.js — это альтернатива jQuery, используется как простая библиотека (с рекомендованным способом подключения через CDN !), в то время, как svelte требует компиляции и имеет гораздо более богатое API.