MarsiBarsi 26 окт 2020 в 12:54

Давайте сделаем переиспользуемый компонент tree view в Angular

6 мин

9.3K

Блог компании Т-БанкВеб-разработка*JavaScript*Angular*TypeScript*

Туториал

+22

Комментарии 10

essome 26 окт 2020 в 18:09

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

AnthonyKot 26 окт 2020 в 23:47

Спасибо за туториал!

yuriy-bezrukov 27 окт 2020 в 07:48

Немного стало больно когда увидел тип массива в котором могут быть объекты и массивы, привычнее структура классических массивов с однотипными данными

Например

interface Node {
  id: number,
  name: string, 
  children: Node[]
}

Спасибо за статью

MarsiBarsi 27 окт 2020 в 09:02

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

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

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

amakhrov 27 окт 2020 в 09:31

Node с children — это не про отсутствие дженериков. Никто не мешает сделать

interface Node<T> {
  value: T
  children: Node<T>[]
}

И даже, если упороться, передать в компонент функцию-маппер, извлекающую дочерние элементы из ноды

// html
<tree-view [roots]="roots" [getChildren]="getChildren">
// ts
public getChildren = (node: Node) => node.children;

Тут скорее про то, что в полиморфном массиве из статьи нет семантической связи между родительским и дочерними элементами.
Например, директория с тремя файлами представляется внезапно не 1 элементом и не 4, а двумя:

[
  {...dir element...},
  [ {...file 1...}, {...file 2...}, {...file 3...} ]
]

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

MarsiBarsi 27 окт 2020 в 10:09

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

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

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