В настоящее время я реализую элемент таблицы данных, используя пользовательские элементы (веб-компоненты). Таблица может иметь различные типы ячеек (текст, число, дата и т. Д.), Которые используются для визуализации каждой строки.

Например

<my-table>
    <my-table-cell-text column="name"></my-table-cell-text>
    <my-table-cell-date column="dob" format="YYYY-MM-DD"></my-table-cell-date>
    <my-table-cell-number column="salary" decimals="2"></my-table-cell-number >
</my-table>

у меня тоже естьMyTableCell класс, который расширяет все элементы ячейки. Это прекрасно работает для совместного использования общих функций, однако стилизация может быть проблемой, потому что каждый тип ячейки имеет свой собственный HTML-тег. В настоящее время я добавляю класс CSS при расширенииMyTableCellНо, ради аргумента, допустим, я не хочу этого делать.

Идеальным решением было бы иметь возможность расширить пользовательский элемент, используяis ключевое слово, например<my-table-cell is="my-table-cell-text">, но это разрешено только для встроенных HTML-элементов.

Я могу придумать 3 подхода к решению этой проблемы:

Синтаксис похож на<input type="">, но это намного больше работы, так как вы больше не расширяете базовый класс, а скорее создаете варианты одного и того же элемента, а это означает, что вам нужен собственный способ регистрации различных вариантов, что-то вроде статическогоMyTableCell.registerType

Композиционный подход, где я обертываю элемент визуализации,<my-table-renderer-text>внутри общего<my-table-cell>, Это позволяет избежать использования специального метода регистров, но его сложнее написать и приводит к большему количеству элементов и большему количеству шаблонного кода, что, в свою очередь, означает снижение производительности.

Сочетание обоих, где пользователь пишет<my-table-cell type="text"> и клетка использует что-то вродеdocument.createElement('my-table-rendener-'+ type) внутренне. Это сохраняет более простой синтаксис варианта 1, но при этом избегает использования метода специального регистра, но имеет те же последствия для производительности, что и вариант 2.

Можете ли вы предложить какие-либо лучшие альтернативы? Я что-то упустил?