Демо сделано полностью с помощью пакета @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
Демо сделано полностью с помощью пакета @taiga-ui/addon-doc. Это один из аддонов, в котором собран сет из компонентов и инструментов для сборки такой витрины. Документация пока не очень подробная по нему, но к нам всегда можно прийти с вопросом — подскажем и расширим ее. Еще ее можно полностью интернационализировать токенами на любой язык.
Если вкратце, то было много команд и различных проектов, которым были нужны одинаковые компоненты в собственной дизайн системе. Чтобы не верстать одни и те же элементы интерфейса десятки раз, они сложены в библиотеку компонентов, обновляются в ней отдельной командой и легко переиспользуются всеми проектам
Юз. кейсы могут быть самыми непредсказуемыми. Можно долго продумывать их, но рано или поздно кто-то придет с чем-то совсем необычным и тут самое обидное будет, если компонент не позволит развернуться, потому что заведемо был заточен под чуть более узкий кейс. Кстати, человек, который спросил меня об этом компоненте и благодаря которому эта статья и выросла, орудовал как раз массивом с массивами строк (я не к тому, что это правильно, но так люди тоже используют это дело :) )
Энивей, оба решения хороши и решают эту историю. Думаю, тут мы к серебрянной пуле не придем, но хорошо, что такое мнение появилось и дополнило статью, спасибо!
Вариант с интерфейсом отличный, когда мы разрабатываем такое дерево в своем приложении — мы легко можем завязаться на любой принятый в приложении контракт. Но когда мы делаем переиспользуемый компонент, то у нас такой возможности нет.
Когда человек с продуктовой разработки приходит делать гибкую библиотеку, то желание делать интерфейсы для данных остается (я и сам переходил), но по нашему опыту для них в очень мало реальных кейсов — практически все заменяется дженериками и хендлерами, избавляя пользователей библиотеки от кучи маппингов и возни с данными, а разработчиков от ситуации еженедельных «ох, там хотят новую фичу, пойдем расширять интерфейс»
Из-за того, что мы нигде ничего не мутируем, в моей команде и не знали, что туплы по дефолту мутабельные и мы можем сделать на тупле в данном случае .pop() пару раз, нагло нарушив контракт переменной
Кстати, у вас есть идеи, для чего может существовать мутабельный «тупл»? (фактически, он и не тупл в таком случае) Сходу выглядит как беда TypeScript, на которую стоит завести issue
Нет, я не считаю, что зависимость от расположения обязательно повод для создания DI. Тот псевокласс показывал, какие есть зависимости и что нам не всегда их легко подметить. Он ни к чему не призывал, так что извиняюсь, что смутил этим :)
У меня основной блог на медиуме на английском, там такие штуки на радость заходят и хорошо работают, вот и здесь пробую
У нас как раз наоборот получилось — раньше опирались на глобальные объекты, использовали isBrowser (например, в библиотеке шаренных компонентов, которые могут быть использованы в любом контекте). Потом перешли на токены — тестировать полностью независимые сущности всегда проще, не надо думать о контексте исполнения
Обычно нужны не сами window и document, а их преобразования в различные location / performance / userAgent, их уже мокаем в тестах или стабаем в SSR. Даже вот опенсорсную либу накрутили, чтобы в SSR можно было подставлять объекты вроде UserAgent github.com/ng-web-apis/universal
Но лидом может стать только студент не выпускного курса. На следующий год лидом становится другой студент, а прежний будет ему помогает. Это сделано, чтобы предотвратить ситуацию, когда лид четверокурсник уходит из ВУЗа и клуб разваливается
Обертка для destroy у нас своя собственная есть, вот тут Саша Инкин про нее постил
Да, у нас очень много ангуляр разработчиков и проектов на ангуляр, пингани меня, пожалуйста, в удобном тебе мессенджере / соц. сети, расскажу подробнее
t.me/angular_fox
Мы копались внутри Angular, providers там «съедает, что дадут»: можно один отдельный провайдер, можно массив провайдеров, можно массив с массивом с массивом с провайдером — тоже сработает
Попробую ответить на все вопросы одним сообщением, а то у меня один ответ залезает на другой:
Мы недавно с коллегой делали сайд проект, который полностью построили на концепции частных провайдерах. Если здесь в примерах мы код просто выносили в соседний файл «для удобства», то там как раз мы специально заделали папочку «providers» в основе проекта и добавляли туда различные провайдеры, которые позже сплетались в цепочки друг из друга. Над проектом работаем по 10-20 часов в неделю в течение нескольких месяцев, пока полет отличный — все сущности ничего не знают о существовании друг друга, весь полет данных идет через различные преобразования в провайдерах.
По поводу типизации: да, ошибки теоретически могут быть и TS никак не спасет, так уж устроен DI