Роман Седов MarsiBarsi

Хорошая идея, спасибо! Когда буду писать продолжение, то постараюсь организовать демо-проект, в котором можно будет просто полазать или запустить со стекблитца

Понял, спасибо! Приходите с Issue, по-возможности со Stackblitz заготовкой, но можно и без, хотя бы с примерным происходящим

Проблем со стилями вроде не должно быть — еще два года назад нашу библиотеку в Angular Elements собирал и смотрел + знаю пару проектов, которые используют их. Так что приносите пример, поковыряемся :)

С календарями проблема может быть — не знаю, юзает ли кто-то еще ввод календарей в элементах. Если есть, то готовы такое править, конечно, — angular elements хотелось бы поддерживать, насколько это возможно. Тоже надо бы нам подебажить

По стилям вы себе сами ответили — если мы прячем компонент в ShadowDom, то он не увидит CSS-переменные снаружи.

Если я правильно уловил проблему по поводу контролов: выпадашка появляется не около компонента, а в портале. Если портала нет (компонент не обернут в tui-root), то и самой выпадашки не будет. Если tui-root есть, но ширина-высота Angular Element'а такие же, как и размер самого контрола, то выпасть ей будет некуда и она сразу закроется.

В других крупных либах такого не видел, но мы и не особо копались в них, точно не могу сказать. Контроллеры действительно не очень простые получились, но уж больно сильно они нам упростили кастомизацию таких настроек — во второй статье постараюсь раскрыт всю мощь :)

Большое спасибо за добрые слова!

Согласен, по реакту сейчас очень много материалов, да и среди начинающих стажеров-джунов он гораздо популярнее по моим наблюдениям. Вот и возникает дилемма: с одной стороны, хочется писать статьи помудренее, потому что их сейчас совсем мало. С другой стороны, я уже думаю, не начать ли как раз выпускать статьи формата «Почему Ангуляр стоит попробовать и как это можно сделать», чтобы внести хотя бы маленький вклад в популяризацию фреймворка. Не хотелось бы со временем попасть в ситуацию, когда сложные статьи совсем некому читать :(

Спасибо! Если вопрос к компании, то так исторически сложилось, что сервисы для физических лиц стали делать на реакте, а сервисы для юр. лиц на ангуляре.

Если лично ко мне, то я входил во фронтенд в начале 2018 года: тогда мне очень понравился TypeScript и в связке с Angular всё это выглядело серьезными и интересными технологиями (в дальнейшем оправдалось). После открыл для себя множество возможностей в ангуляре, подробно его изучил и открыл много отличных практик, которыми обычно и делюсь в статьях. Ангуляр мне очень удобен и позволяет быстро собрать интерфейс любой сложности, поэтому персонально меня всё более чем устраивает :)

Да, однажды дизайн основной темы Тайги выложим и в фигму

Привет! Хорошие новости, подняли Ionic с Тайгой. Полет нормальный: stackblitz.com/edit/taiga-ui-ionic

Привет! Пока там только два компонента:
taiga-ui.dev/tui-resizable-column
taiga-ui.dev/tui-table-pagination

Но у нас в планах на этот квартал доработать аддон до полноценного инструмента для работы со сложными таблицами со всякими перетаскиваниями, фильтраиями и прочим

Нам подход с версионированием по компонентам показался тяжелее — с таким количеством компонентов можно будет сойти с ума, когда начнутся конфликты версий и зависимости одного компонента от другого.

С другой стороны имеем синхронные версии — пользователям библиотеки просто нужно бампнуть версию и можно быть уверенным, что проблемы не возникнут.

В целом, наши addon'ы можно вести отдельно, потому что мы их нечасто обновляем. Но вот связку cdk/core/kit лучше синхронизировать

А еще про root можно будет узнать подробнее буквально через одну-две недели. Саша выложит статью о принципах его работы и причинах появления (на английском уже, кстати, есть)

Не обязательно, root позволяет работать с порталами — выпадашками, диалогами, нотификациями и т.п. Компоненты вроде отдельной простой кнопки, полей ввода или календря будут работать и без него.

По поводу Ionic подсказать не могу — у нас совсем нет пользователей на нем и нам с Сашей никогда не приходилось его использовать. Хотя теоретически должно завестись. Если попробуете и получится, пожалуйста, дайте знать. Если сломается, то обязательно пишите — постараемся решить проблемы

Спасибо за фидбек и важный вопрос!

Демо сделано полностью с помощью пакета @taiga-ui/addon-doc. Это один из аддонов, в котором собран сет из компонентов и инструментов для сборки такой витрины. Документация пока не очень подробная по нему, но к нам всегда можно прийти с вопросом — подскажем и расширим ее. Еще ее можно полностью интернационализировать токенами на любой язык.

Спасибо! Изначально это закладывалось, чтобы можно было просто повесить нативный CSS'ный `direction: rtl;`, но в текущей версии там есть некоторые проблемы с отображением постфикса и плейсхолдера в таком режиме. На это уже заведен issue, надеюсь скоро получится доработать этот момент

Проекты используют эти же компоненты, но с другой дизайн темой — там корпоративные шрифты, цвета, скругления, тени и все такое. Если говорить о дизайне, то проекты его не кастомизируют — мы закладываем визуал в теме библиотеки, а проектные команды вставляют компоненты и завязывают на них свою бизнес логику. Это позволяет юзерам проще ориентироваться по приложению, потому что во всех его частях используются те же компоненты с одинаковым поведением :)

Цель и история о том, как мы пришли к библиотеке, хорошо описаны в статье, которую я приводил в начале, «Как организовать работу над библиотекой общих компонентов». Там же можно почитать о плюсах библиотеки с выделенной командой.

Если вкратце, то было много команд и различных проектов, которым были нужны одинаковые компоненты в собственной дизайн системе. Чтобы не верстать одни и те же элементы интерфейса десятки раз, они сложены в библиотеку компонентов, обновляются в ней отдельной командой и легко переиспользуются всеми проектам

Да, не спорю, такое решение есть и тоже хорошее. Про семантическую связь я размышлял, когда это делал, интерфейс тут определенно выиграет с точки зрения кейса директории с папками. Мое решение скорее от идеи «вложенность вашего массива — вложенность вашего дерева», на мой взгляд, так закладывается меньше контекста

Юз. кейсы могут быть самыми непредсказуемыми. Можно долго продумывать их, но рано или поздно кто-то придет с чем-то совсем необычным и тут самое обидное будет, если компонент не позволит развернуться, потому что заведемо был заточен под чуть более узкий кейс. Кстати, человек, который спросил меня об этом компоненте и благодаря которому эта статья и выросла, орудовал как раз массивом с массивами строк (я не к тому, что это правильно, но так люди тоже используют это дело :) )

Энивей, оба решения хороши и решают эту историю. Думаю, тут мы к серебрянной пуле не придем, но хорошо, что такое мнение появилось и дополнило статью, спасибо!

Да, тут как раз и интересный момент :)

Вариант с интерфейсом отличный, когда мы разрабатываем такое дерево в своем приложении — мы легко можем завязаться на любой принятый в приложении контракт. Но когда мы делаем переиспользуемый компонент, то у нас такой возможности нет.

Когда человек с продуктовой разработки приходит делать гибкую библиотеку, то желание делать интерфейсы для данных остается (я и сам переходил), но по нашему опыту для них в очень мало реальных кейсов — практически все заменяется дженериками и хендлерами, избавляя пользователей библиотеки от кучи маппингов и возни с данными, а разработчиков от ситуации еженедельных «ох, там хотят новую фичу, пойдем расширять интерфейс»

Ого, Дима, это ты, привет!

Спасибо вам, это очень полезный комментарий!
Из-за того, что мы нигде ничего не мутируем, в моей команде и не знали, что туплы по дефолту мутабельные и мы можем сделать на тупле в данном случае .pop() пару раз, нагло нарушив контракт переменной

Кстати, у вас есть идеи, для чего может существовать мутабельный «тупл»? (фактически, он и не тупл в таком случае) Сходу выглядит как беда TypeScript, на которую стоит завести issue

Спасибо за фидбек! Это из-за того, что я не указал среди хабов «Разработка веб-сайтов» — туда можно указать четыре тематических хаба и я как-то стал забывать про этот, указывая обычно Angular + TS + JS и еще что-нибудь. Похоже, стоит включать :)

да, разумеется, под масштабированием имел в виду только увеличение размеров проекта. Я использую слово «масштабировать» довольно часто для всего, что может расти, поэтому для меня оно хорошо воспринимается и вне контекста бэкенда или разговоров о базах данных. Тем не менее, извиняюсь, если кого-то запутал этим :(

Привет! От увеличения размера проектов, работать над ними не становится существенно сложнее: подобная строгая типизация позволяет орудовать сущностями, не ожидая от них подставы и не держа весь код проекта и его взаимосвязи в голове

Добрый день!

Нет, я не считаю, что зависимость от расположения обязательно повод для создания DI. Тот псевокласс показывал, какие есть зависимости и что нам не всегда их легко подметить. Он ни к чему не призывал, так что извиняюсь, что смутил этим :)

Перепроверил примеры — все на местах, странно. Похоже, что эксперимент со Stackblitz'ами на Хабре вышел неудачный :(

У меня основной блог на медиуме на английском, там такие штуки на радость заходят и хорошо работают, вот и здесь пробую

Привет!

У нас как раз наоборот получилось — раньше опирались на глобальные объекты, использовали isBrowser (например, в библиотеке шаренных компонентов, которые могут быть использованы в любом контекте). Потом перешли на токены — тестировать полностью независимые сущности всегда проще, не надо думать о контексте исполнения

Обычно нужны не сами window и document, а их преобразования в различные location / performance / userAgent, их уже мокаем в тестах или стабаем в SSR. Даже вот опенсорсную либу накрутили, чтобы в SSR можно было подставлять объекты вроде UserAgent github.com/ng-web-apis/universal

Привет! Можно участвовать в жизни клуба или помогать ему

Но лидом может стать только студент не выпускного курса. На следующий год лидом становится другой студент, а прежний будет ему помогает. Это сделано, чтобы предотвратить ситуацию, когда лид четверокурсник уходит из ВУЗа и клуб разваливается

Привет! Спасибо за добрые слова :)
Обертка для destroy у нас своя собственная есть, вот тут Саша Инкин про нее постил

Да, у нас очень много ангуляр разработчиков и проектов на ангуляр, пингани меня, пожалуйста, в удобном тебе мессенджере / соц. сети, расскажу подробнее

Нет, телеграм не веду. Но знаю, что у товарища лиса (thekiba / twitter.com/thekiba_io) есть классный канал по Angular:
t.me/angular_fox

Поправил, спасибо большое за внимательность!

хм, не попадался в такой кейс c override, спасибо

Мы копались внутри Angular, providers там «съедает, что дадут»: можно один отдельный провайдер, можно массив провайдеров, можно массив с массивом с массивом с провайдером — тоже сработает

Спасибо за такой развернутый комментарий :)
Попробую ответить на все вопросы одним сообщением, а то у меня один ответ залезает на другой:
Мы недавно с коллегой делали сайд проект, который полностью построили на концепции частных провайдерах. Если здесь в примерах мы код просто выносили в соседний файл «для удобства», то там как раз мы специально заделали папочку «providers» в основе проекта и добавляли туда различные провайдеры, которые позже сплетались в цепочки друг из друга. Над проектом работаем по 10-20 часов в неделю в течение нескольких месяцев, пока полет отличный — все сущности ничего не знают о существовании друг друга, весь полет данных идет через различные преобразования в провайдерах.

По поводу типизации: да, ошибки теоретически могут быть и TS никак не спасет, так уж устроен DI

Ага, у меня было так, что DI шел тяжеловато, но когда разобрался, то полюбил :)

Могу порекомендовать тут скринкаст Степана Суворова на ютюбе, там базовые штуки: www.youtube.com/watch?v=bJvBRJUytgg&list=PLDyvV36pndZF-vwsVB48ivZyNJ4ETBKNY&index=14

Более фундаментально про саму концепцию IoC и конкретно DI есть интересная серия видео у Ильи Климова:
www.youtube.com/watch?v=ETyltCwtQHs&list=PLvTBThJr861xKTf1x6P49MwN6yoN4v69k

На почитать могу собственный материал порекомендовать: первая глава в angular.institute. Только там на английском, надеюсь не будет проблемой

Обычно формы живут в рамках одного компонента, поэтому с ними таких вопросов не возникает.

Бывают случаи сложнее, когда форма большая и хочется ее разнести. Помню был случай, когда сложный компонент вроде выпадающего календаря нуждался в данных контрола, но с дефолтным значением. Тоже решали частными провайдерами и вот такой штукой в 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 в данном случае решает только третью задачу

К сожалению, да. Но пока работает без проблем. Также знаю ребят, которые готовят достойную альтернативу. Как только выпустят — обязательно отпишу здесь