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

Когда мы начали ее проектировать, то закладывали две типовые группы - Data table и Index table.

Data - для мета-данных, на которые ты просто смотришь и восторгаешься циферками и буковками, и никак с ними не взаимодействуешь.

Index table - наоборот, сложная и нагруженная таблица, в реалиях наших продуктов, это могут быть и раскрывающиеся строки, инпуты в ячейках и прочее непотребство.

Многие команды делая свой UI-Kit или даже полноценную систему, либо таблицу и вовсе не закладывают, либо оставляют в качестве формального шаблона, который ты просто кидаешь в layout , разбираешь его и кастомишь, как того требует задача. Нас такой формат совсем не устраивал, мы не хотели терять консистентность и усложнять себе жизнь в перспективе, поэтому решили ее усложнить на старте.

Первое, обо что мы споткнулись - это базовый скелет, через что мы будем закладывать шаблон, мастер строки или мастер ячейки. Для большей гибкости - мы выбрали ячейки. Собрали все возможные варианты с наших продуктов и собрали variants накинув при этом токены (хэдер таблицы был сделан отдельным parts).

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