Хорошая идея, спасибо! Когда буду писать продолжение, то постараюсь организовать демо-проект, в котором можно будет просто полазать или запустить со стекблитца
Понял, спасибо! Приходите с Issue, по-возможности со Stackblitz заготовкой, но можно и без, хотя бы с примерным происходящим
Проблем со стилями вроде не должно быть — еще два года назад нашу библиотеку в Angular Elements собирал и смотрел + знаю пару проектов, которые используют их. Так что приносите пример, поковыряемся :)
С календарями проблема может быть — не знаю, юзает ли кто-то еще ввод календарей в элементах. Если есть, то готовы такое править, конечно, — angular elements хотелось бы поддерживать, насколько это возможно. Тоже надо бы нам подебажить
По стилям вы себе сами ответили — если мы прячем компонент в ShadowDom, то он не увидит CSS-переменные снаружи.
Если я правильно уловил проблему по поводу контролов: выпадашка появляется не около компонента, а в портале. Если портала нет (компонент не обернут в tui-root), то и самой выпадашки не будет. Если tui-root есть, но ширина-высота Angular Element'а такие же, как и размер самого контрола, то выпасть ей будет некуда и она сразу закроется.
В других крупных либах такого не видел, но мы и не особо копались в них, точно не могу сказать. Контроллеры действительно не очень простые получились, но уж больно сильно они нам упростили кастомизацию таких настроек — во второй статье постараюсь раскрыт всю мощь :)
Согласен, по реакту сейчас очень много материалов, да и среди начинающих стажеров-джунов он гораздо популярнее по моим наблюдениям. Вот и возникает дилемма: с одной стороны, хочется писать статьи помудренее, потому что их сейчас совсем мало. С другой стороны, я уже думаю, не начать ли как раз выпускать статьи формата «Почему Ангуляр стоит попробовать и как это можно сделать», чтобы внести хотя бы маленький вклад в популяризацию фреймворка. Не хотелось бы со временем попасть в ситуацию, когда сложные статьи совсем некому читать :(
Спасибо! Если вопрос к компании, то так исторически сложилось, что сервисы для физических лиц стали делать на реакте, а сервисы для юр. лиц на ангуляре.
Если лично ко мне, то я входил во фронтенд в начале 2018 года: тогда мне очень понравился TypeScript и в связке с Angular всё это выглядело серьезными и интересными технологиями (в дальнейшем оправдалось). После открыл для себя множество возможностей в ангуляре, подробно его изучил и открыл много отличных практик, которыми обычно и делюсь в статьях. Ангуляр мне очень удобен и позволяет быстро собрать интерфейс любой сложности, поэтому персонально меня всё более чем устраивает :)
Но у нас в планах на этот квартал доработать аддон до полноценного инструмента для работы со сложными таблицами со всякими перетаскиваниями, фильтраиями и прочим
Нам подход с версионированием по компонентам показался тяжелее — с таким количеством компонентов можно будет сойти с ума, когда начнутся конфликты версий и зависимости одного компонента от другого.
С другой стороны имеем синхронные версии — пользователям библиотеки просто нужно бампнуть версию и можно быть уверенным, что проблемы не возникнут.
В целом, наши addon'ы можно вести отдельно, потому что мы их нечасто обновляем. Но вот связку cdk/core/kit лучше синхронизировать
А еще про root можно будет узнать подробнее буквально через одну-две недели. Саша выложит статью о принципах его работы и причинах появления (на английском уже, кстати, есть)
Не обязательно, root позволяет работать с порталами — выпадашками, диалогами, нотификациями и т.п. Компоненты вроде отдельной простой кнопки, полей ввода или календря будут работать и без него.
По поводу Ionic подсказать не могу — у нас совсем нет пользователей на нем и нам с Сашей никогда не приходилось его использовать. Хотя теоретически должно завестись. Если попробуете и получится, пожалуйста, дайте знать. Если сломается, то обязательно пишите — постараемся решить проблемы
Демо сделано полностью с помощью пакета @taiga-ui/addon-doc. Это один из аддонов, в котором собран сет из компонентов и инструментов для сборки такой витрины. Документация пока не очень подробная по нему, но к нам всегда можно прийти с вопросом — подскажем и расширим ее. Еще ее можно полностью интернационализировать токенами на любой язык.
Спасибо! Изначально это закладывалось, чтобы можно было просто повесить нативный CSS'ный `direction: rtl;`, но в текущей версии там есть некоторые проблемы с отображением постфикса и плейсхолдера в таком режиме. На это уже заведен issue, надеюсь скоро получится доработать этот момент
Проекты используют эти же компоненты, но с другой дизайн темой — там корпоративные шрифты, цвета, скругления, тени и все такое. Если говорить о дизайне, то проекты его не кастомизируют — мы закладываем визуал в теме библиотеки, а проектные команды вставляют компоненты и завязывают на них свою бизнес логику. Это позволяет юзерам проще ориентироваться по приложению, потому что во всех его частях используются те же компоненты с одинаковым поведением :)
Если вкратце, то было много команд и различных проектов, которым были нужны одинаковые компоненты в собственной дизайн системе. Чтобы не верстать одни и те же элементы интерфейса десятки раз, они сложены в библиотеку компонентов, обновляются в ней отдельной командой и легко переиспользуются всеми проектам
Да, не спорю, такое решение есть и тоже хорошее. Про семантическую связь я размышлял, когда это делал, интерфейс тут определенно выиграет с точки зрения кейса директории с папками. Мое решение скорее от идеи «вложенность вашего массива — вложенность вашего дерева», на мой взгляд, так закладывается меньше контекста
Юз. кейсы могут быть самыми непредсказуемыми. Можно долго продумывать их, но рано или поздно кто-то придет с чем-то совсем необычным и тут самое обидное будет, если компонент не позволит развернуться, потому что заведемо был заточен под чуть более узкий кейс. Кстати, человек, который спросил меня об этом компоненте и благодаря которому эта статья и выросла, орудовал как раз массивом с массивами строк (я не к тому, что это правильно, но так люди тоже используют это дело :) )
Энивей, оба решения хороши и решают эту историю. Думаю, тут мы к серебрянной пуле не придем, но хорошо, что такое мнение появилось и дополнило статью, спасибо!
Вариант с интерфейсом отличный, когда мы разрабатываем такое дерево в своем приложении — мы легко можем завязаться на любой принятый в приложении контракт. Но когда мы делаем переиспользуемый компонент, то у нас такой возможности нет.
Когда человек с продуктовой разработки приходит делать гибкую библиотеку, то желание делать интерфейсы для данных остается (я и сам переходил), но по нашему опыту для них в очень мало реальных кейсов — практически все заменяется дженериками и хендлерами, избавляя пользователей библиотеки от кучи маппингов и возни с данными, а разработчиков от ситуации еженедельных «ох, там хотят новую фичу, пойдем расширять интерфейс»
Спасибо вам, это очень полезный комментарий!
Из-за того, что мы нигде ничего не мутируем, в моей команде и не знали, что туплы по дефолту мутабельные и мы можем сделать на тупле в данном случае .pop() пару раз, нагло нарушив контракт переменной
Кстати, у вас есть идеи, для чего может существовать мутабельный «тупл»? (фактически, он и не тупл в таком случае) Сходу выглядит как беда TypeScript, на которую стоит завести issue
Спасибо за фидбек! Это из-за того, что я не указал среди хабов «Разработка веб-сайтов» — туда можно указать четыре тематических хаба и я как-то стал забывать про этот, указывая обычно Angular + TS + JS и еще что-нибудь. Похоже, стоит включать :)
да, разумеется, под масштабированием имел в виду только увеличение размеров проекта. Я использую слово «масштабировать» довольно часто для всего, что может расти, поэтому для меня оно хорошо воспринимается и вне контекста бэкенда или разговоров о базах данных. Тем не менее, извиняюсь, если кого-то запутал этим :(
Привет! От увеличения размера проектов, работать над ними не становится существенно сложнее: подобная строгая типизация позволяет орудовать сущностями, не ожидая от них подставы и не держа весь код проекта и его взаимосвязи в голове
Нет, я не считаю, что зависимость от расположения обязательно повод для создания DI. Тот псевокласс показывал, какие есть зависимости и что нам не всегда их легко подметить. Он ни к чему не призывал, так что извиняюсь, что смутил этим :)
У нас как раз наоборот получилось — раньше опирались на глобальные объекты, использовали isBrowser (например, в библиотеке шаренных компонентов, которые могут быть использованы в любом контекте). Потом перешли на токены — тестировать полностью независимые сущности всегда проще, не надо думать о контексте исполнения
Обычно нужны не сами window и document, а их преобразования в различные location / performance / userAgent, их уже мокаем в тестах или стабаем в SSR. Даже вот опенсорсную либу накрутили, чтобы в SSR можно было подставлять объекты вроде UserAgent github.com/ng-web-apis/universal
Привет! Можно участвовать в жизни клуба или помогать ему
Но лидом может стать только студент не выпускного курса. На следующий год лидом становится другой студент, а прежний будет ему помогает. Это сделано, чтобы предотвратить ситуацию, когда лид четверокурсник уходит из ВУЗа и клуб разваливается
Привет! Спасибо за добрые слова :)
Обертка для destroy у нас своя собственная есть, вот тут Саша Инкин про нее постил
Да, у нас очень много ангуляр разработчиков и проектов на ангуляр, пингани меня, пожалуйста, в удобном тебе мессенджере / соц. сети, расскажу подробнее
Мы копались внутри Angular, providers там «съедает, что дадут»: можно один отдельный провайдер, можно массив провайдеров, можно массив с массивом с массивом с провайдером — тоже сработает
Спасибо за такой развернутый комментарий :)
Попробую ответить на все вопросы одним сообщением, а то у меня один ответ залезает на другой:
Мы недавно с коллегой делали сайд проект, который полностью построили на концепции частных провайдерах. Если здесь в примерах мы код просто выносили в соседний файл «для удобства», то там как раз мы специально заделали папочку «providers» в основе проекта и добавляли туда различные провайдеры, которые позже сплетались в цепочки друг из друга. Над проектом работаем по 10-20 часов в неделю в течение нескольких месяцев, пока полет отличный — все сущности ничего не знают о существовании друг друга, весь полет данных идет через различные преобразования в провайдерах.
По поводу типизации: да, ошибки теоретически могут быть и TS никак не спасет, так уж устроен DI
Обычно формы живут в рамках одного компонента, поэтому с ними таких вопросов не возникает.
Бывают случаи сложнее, когда форма большая и хочется ее разнести. Помню был случай, когда сложный компонент вроде выпадающего календаря нуждался в данных контрола, но с дефолтным значением. Тоже решали частными провайдерами и вот такой штукой в useFactory: https://twitter.com/marsibarsi/status/1269201441756979200
Если хотим сделать компонент для редактирования организации, то я бы сделал взаимодействие с сервисом в компоненте. Тогда компонент зависит не от данных организации, а именно от сервиса — ему нужно уметь получить данные, ему нужно уметь обновить их, удалить и т.п.
У нас провайдеры хорошо упрощают код в кейсах, когда компонент зависит именно от данных. Для других случаев мы используем как обычные сервисы, так и разные вроде Observabled-based или Subject-based варианты, как в статье, ссылка на которой в комментарии ниже
да, все верно :)
Приведенный в статье кейс очень простой, но это плата за лаконичность статьи. Сложный кейс мог бы дать один конкретный хороший пример, но замылыть суть самой идеи. Я выбрал первый вариант
С человеком, статью которого вы привели в пример, мы как раз работаем в одной команде и активно используем оба подхода: для некоторых кейсов лучше ложиться одно решение, для некоторых — другое.
Возможно, не до конца вышло донести мысль, что это лишь один из альтернативных подходов и точно не заменяющий все остальные :(
Мне нравится, что мы можем положить в npm не только необходимые файлы, но и оставить в этих файлах только самое необходимое. `files` в `package.json` будет достаточно для обычной JS библиотеки. Если взять, например, Angular Workspace с библиотекой, то там создание отдельной папки для публикации просто необходимо, потому что мы передаем в npm иной `package.json` — очищенный от зависимостей и информации, которые не относятся к финальной либе
Да, вызов release остался открытым. Если проект будет развиваться, то стоит настроить авторелиз release-веток
C tslint согласен. Хотя typescript'еры не очень охотно переводят на него свои проекты, рано или поздно придется. Кстати, вот здесь roadmap tslint на закрытие пакета в несколько стадий
В пункте про `standard-version` я хочу показать возможность решить вопросы о наименовании коммитов, ведении changelog-файла и версионировании разом. npm version в данном случае решает только третью задачу
К сожалению, да. Но пока работает без проблем. Также знаю ребят, которые готовят достойную альтернативу. Как только выпустят — обязательно отпишу здесь