Да, я на самом деле не стараюсь донести мысль, что все опенсорсы радужные. Абсолютно все перечисленные причины собраны с конкретного большого проекта, в котором это сработало (да приправлены мыслями с десятка проектов поменьше). Это ретроспектива за прошедший год и она правда меня очень радует.
Применимо ли это к большинству проектов или случайная ошибка выжившего — решать уже вам :)
Согласен, в небольших компаниях может быть не так легко увидеть потенциальный опенсорс продукт, да и нужно несколько раз подумать, актуально ли будет такое решение через некоторое время.
А вот если в компании уже есть условные несколько отделов с разными доменными областям, да кто-то решил сделать общую штуку для всех, то тогда точно как минимум задуматься стоит :)
В директивы-контроллеры не выносится никакая реальная логика, они фактически лишь сокращают путь между местом, куда данные передают (верхнеуровневый компонент), и местом, где их получают (внутренний компонент Textfield), поэтому логика не может перемешаться — она одна и написана в текстфилде. Если мы сделаем еще один передатчик для той же самой логики, то не сможем пропустить это в самом текстфилде.
Про миграцию отличный вопрос, стоило включить это в статью.
Когда я переписывал Тайгу на контроллеры, то назвал инпуты в них аналогично тому, какими они были у самих компонентов. К модулям компонентов добавлялись контроллеры и экспортились из них, то есть изменения прошли только под капотом и полностью бесшовно для пользователей. Единственный потенциальный минус — так можно частично потерять один из плюсов подхода — уменьшение бандла. Если во всем приложении контроллер ни разу не использован, то он все еще заскочит в бандл, хоть и в единственном экземпляре вместо десятка.
Для совсем полной смены подхода можно написать миграцию для ng update, которая будет перепахивать кодовую базу проектов при бампе версии библиотеки и подменять импорты с одного модуля на модуль + набор отдельных модулей контроллеров. Тут могу порекомендовать наш инструмент ng-morph, который упрощает процесс написания + его легче использовать для обычного проекта (если у вас не библиотека и ng update)
А я наоборот люблю DI за то, что мы можем подкладывать и переопределять сущности на любом уровне. Даже если возникает ситуация, где нам хочется ограничить какой-то скоуп от нашей сущности, то всегда можно переопределить ее на null в обычных или viewProviders
Да, такой альтернативный подход тоже неплохая идея, но мы его не используем. В этом случае у нас создается новый JS объект контекста на каждую проверку изменений. В целом, ничего сильно страшного в этом нет, но такие пересборки объектов могут постепенно привести к проблемам с перфомансам в очень больших приложениях (например, мы везде пересоздания объектов выносим в Pure, чтобы все скейлилось как можно дольше). Чтобы в дальшейнем не выискивать довольно хитрое узкое горлышко, мы так не делаем с самого начала.
В целом, хорошая идея для небольшой статьи — замерить такие штуки и определить, на каком масштабе юзера начнут замечать разницу, посмотреть дефолтную стратегию и OnPush
Рассматривали с давних времен, следим за развитием, но к себе не берем.
Until-destroy завязывается на внутреннюю реализацию Ангуляра, использует приватное API и императивно патчит его сущности. Такие штуки могут ломаться от неожиданного апдейта ангуляра (там и сейчас разные реализации для Ivy и View Engine), могут взорваться при неожиданном желании собраться в SSR или Ionic. Мы к такому не готовы и стараемся выбрать Angular Way везде, где это возможно. Вот в этих двух файлах реализация until-destroy с множеством патчинга и вторжением в кухню ангуляра:
Кроме того, наш сервис можно использовать для различных фокусов с DI и отписываться в сервисах/DI-фабриках, если в этом есть нужда. У until-destroy такой возможности нет
Хорошая идея, спасибо! Когда буду писать продолжение, то постараюсь организовать демо-проект, в котором можно будет просто полазать или запустить со стекблитца
Понял, спасибо! Приходите с Issue, по-возможности со Stackblitz заготовкой, но можно и без, хотя бы с примерным происходящим
Проблем со стилями вроде не должно быть — еще два года назад нашу библиотеку в Angular Elements собирал и смотрел + знаю пару проектов, которые используют их. Так что приносите пример, поковыряемся :)
С календарями проблема может быть — не знаю, юзает ли кто-то еще ввод календарей в элементах. Если есть, то готовы такое править, конечно, — angular elements хотелось бы поддерживать, насколько это возможно. Тоже надо бы нам подебажить
По стилям вы себе сами ответили — если мы прячем компонент в ShadowDom, то он не увидит CSS-переменные снаружи.
Если я правильно уловил проблему по поводу контролов: выпадашка появляется не около компонента, а в портале. Если портала нет (компонент не обернут в tui-root), то и самой выпадашки не будет. Если tui-root есть, но ширина-высота Angular Element'а такие же, как и размер самого контрола, то выпасть ей будет некуда и она сразу закроется.
В других крупных либах такого не видел, но мы и не особо копались в них, точно не могу сказать. Контроллеры действительно не очень простые получились, но уж больно сильно они нам упростили кастомизацию таких настроек — во второй статье постараюсь раскрыт всю мощь :)
Согласен, по реакту сейчас очень много материалов, да и среди начинающих стажеров-джунов он гораздо популярнее по моим наблюдениям. Вот и возникает дилемма: с одной стороны, хочется писать статьи помудренее, потому что их сейчас совсем мало. С другой стороны, я уже думаю, не начать ли как раз выпускать статьи формата «Почему Ангуляр стоит попробовать и как это можно сделать», чтобы внести хотя бы маленький вклад в популяризацию фреймворка. Не хотелось бы со временем попасть в ситуацию, когда сложные статьи совсем некому читать :(
Спасибо! Если вопрос к компании, то так исторически сложилось, что сервисы для физических лиц стали делать на реакте, а сервисы для юр. лиц на ангуляре.
Если лично ко мне, то я входил во фронтенд в начале 2018 года: тогда мне очень понравился TypeScript и в связке с Angular всё это выглядело серьезными и интересными технологиями (в дальнейшем оправдалось). После открыл для себя множество возможностей в ангуляре, подробно его изучил и открыл много отличных практик, которыми обычно и делюсь в статьях. Ангуляр мне очень удобен и позволяет быстро собрать интерфейс любой сложности, поэтому персонально меня всё более чем устраивает :)
Но у нас в планах на этот квартал доработать аддон до полноценного инструмента для работы со сложными таблицами со всякими перетаскиваниями, фильтраиями и прочим
Нам подход с версионированием по компонентам показался тяжелее — с таким количеством компонентов можно будет сойти с ума, когда начнутся конфликты версий и зависимости одного компонента от другого.
С другой стороны имеем синхронные версии — пользователям библиотеки просто нужно бампнуть версию и можно быть уверенным, что проблемы не возникнут.
В целом, наши addon'ы можно вести отдельно, потому что мы их нечасто обновляем. Но вот связку cdk/core/kit лучше синхронизировать
А еще про root можно будет узнать подробнее буквально через одну-две недели. Саша выложит статью о принципах его работы и причинах появления (на английском уже, кстати, есть)
Не обязательно, root позволяет работать с порталами — выпадашками, диалогами, нотификациями и т.п. Компоненты вроде отдельной простой кнопки, полей ввода или календря будут работать и без него.
По поводу Ionic подсказать не могу — у нас совсем нет пользователей на нем и нам с Сашей никогда не приходилось его использовать. Хотя теоретически должно завестись. Если попробуете и получится, пожалуйста, дайте знать. Если сломается, то обязательно пишите — постараемся решить проблемы
Да, я на самом деле не стараюсь донести мысль, что все опенсорсы радужные. Абсолютно все перечисленные причины собраны с конкретного большого проекта, в котором это сработало (да приправлены мыслями с десятка проектов поменьше). Это ретроспектива за прошедший год и она правда меня очень радует.
Применимо ли это к большинству проектов или случайная ошибка выжившего — решать уже вам :)
Согласен, в небольших компаниях может быть не так легко увидеть потенциальный опенсорс продукт, да и нужно несколько раз подумать, актуально ли будет такое решение через некоторое время.
А вот если в компании уже есть условные несколько отделов с разными доменными областям, да кто-то решил сделать общую штуку для всех, то тогда точно как минимум задуматься стоит :)
В директивы-контроллеры не выносится никакая реальная логика, они фактически лишь сокращают путь между местом, куда данные передают (верхнеуровневый компонент), и местом, где их получают (внутренний компонент Textfield), поэтому логика не может перемешаться — она одна и написана в текстфилде. Если мы сделаем еще один передатчик для той же самой логики, то не сможем пропустить это в самом текстфилде.
Про миграцию отличный вопрос, стоило включить это в статью.
Когда я переписывал Тайгу на контроллеры, то назвал инпуты в них аналогично тому, какими они были у самих компонентов. К модулям компонентов добавлялись контроллеры и экспортились из них, то есть изменения прошли только под капотом и полностью бесшовно для пользователей. Единственный потенциальный минус — так можно частично потерять один из плюсов подхода — уменьшение бандла. Если во всем приложении контроллер ни разу не использован, то он все еще заскочит в бандл, хоть и в единственном экземпляре вместо десятка.
Для совсем полной смены подхода можно написать миграцию для
ng update, которая будет перепахивать кодовую базу проектов при бампе версии библиотеки и подменять импорты с одного модуля на модуль + набор отдельных модулей контроллеров. Тут могу порекомендовать наш инструмент ng-morph, который упрощает процесс написания + его легче использовать для обычного проекта (если у вас не библиотека и ng update)А я наоборот люблю DI за то, что мы можем подкладывать и переопределять сущности на любом уровне. Даже если возникает ситуация, где нам хочется ограничить какой-то скоуп от нашей сущности, то всегда можно переопределить ее на
nullв обычных илиviewProvidersПривет! Выложили:
https://www.figma.com/community/file/966347242613098831
На русском у нас нет документации, добавим ссылку на эту статью к нам на демо Тайги
В целом, хорошая идея для небольшой статьи — замерить такие штуки и определить, на каком масштабе юзера начнут замечать разницу, посмотреть дефолтную стратегию и OnPush
Рассматривали с давних времен, следим за развитием, но к себе не берем.
Until-destroy завязывается на внутреннюю реализацию Ангуляра, использует приватное API и императивно патчит его сущности. Такие штуки могут ломаться от неожиданного апдейта ангуляра (там и сейчас разные реализации для Ivy и View Engine), могут взорваться при неожиданном желании собраться в SSR или Ionic. Мы к такому не готовы и стараемся выбрать Angular Way везде, где это возможно. Вот в этих двух файлах реализация until-destroy с множеством патчинга и вторжением в кухню ангуляра:
https://github.com/ngneat/until-destroy/blob/master/src/lib/until-destroyed.ts
https://github.com/ngneat/until-destroy/blob/master/src/lib/until-destroy.ts
А вот так выглядит наш TuiDestroyService, использующий один лайфсайкл хук и возможности DI в Angular:
https://github.com/TinkoffCreditSystems/taiga-ui/blob/main/projects/cdk/services/destroy.service.ts
Кроме того, наш сервис можно использовать для различных фокусов с DI и отписываться в сервисах/DI-фабриках, если в этом есть нужда. У until-destroy такой возможности нет
Проблем со стилями вроде не должно быть — еще два года назад нашу библиотеку в Angular Elements собирал и смотрел + знаю пару проектов, которые используют их. Так что приносите пример, поковыряемся :)
С календарями проблема может быть — не знаю, юзает ли кто-то еще ввод календарей в элементах. Если есть, то готовы такое править, конечно, — angular elements хотелось бы поддерживать, насколько это возможно. Тоже надо бы нам подебажить
Если я правильно уловил проблему по поводу контролов: выпадашка появляется не около компонента, а в портале. Если портала нет (компонент не обернут в tui-root), то и самой выпадашки не будет. Если tui-root есть, но ширина-высота Angular Element'а такие же, как и размер самого контрола, то выпасть ей будет некуда и она сразу закроется.
Согласен, по реакту сейчас очень много материалов, да и среди начинающих стажеров-джунов он гораздо популярнее по моим наблюдениям. Вот и возникает дилемма: с одной стороны, хочется писать статьи помудренее, потому что их сейчас совсем мало. С другой стороны, я уже думаю, не начать ли как раз выпускать статьи формата «Почему Ангуляр стоит попробовать и как это можно сделать», чтобы внести хотя бы маленький вклад в популяризацию фреймворка. Не хотелось бы со временем попасть в ситуацию, когда сложные статьи совсем некому читать :(
Если лично ко мне, то я входил во фронтенд в начале 2018 года: тогда мне очень понравился TypeScript и в связке с Angular всё это выглядело серьезными и интересными технологиями (в дальнейшем оправдалось). После открыл для себя множество возможностей в ангуляре, подробно его изучил и открыл много отличных практик, которыми обычно и делюсь в статьях. Ангуляр мне очень удобен и позволяет быстро собрать интерфейс любой сложности, поэтому персонально меня всё более чем устраивает :)
taiga-ui.dev/tui-resizable-column
taiga-ui.dev/tui-table-pagination
Но у нас в планах на этот квартал доработать аддон до полноценного инструмента для работы со сложными таблицами со всякими перетаскиваниями, фильтраиями и прочим
С другой стороны имеем синхронные версии — пользователям библиотеки просто нужно бампнуть версию и можно быть уверенным, что проблемы не возникнут.
В целом, наши addon'ы можно вести отдельно, потому что мы их нечасто обновляем. Но вот связку cdk/core/kit лучше синхронизировать
По поводу Ionic подсказать не могу — у нас совсем нет пользователей на нем и нам с Сашей никогда не приходилось его использовать. Хотя теоретически должно завестись. Если попробуете и получится, пожалуйста, дайте знать. Если сломается, то обязательно пишите — постараемся решить проблемы