Что выбрать: удобство в организации кода или его отладке?
На проекте есть инструмент таблица. В таблице может быть до 70 колонок и 50 строк. Каждая ячейка в таблице может быть отредактирована в зависимости от типа колонки.
Я увидел 3 способа реализации.
1) Выделил каждый тип ячейки в отдельный компонент, чтобы задать способ отображения и редактирования от входных пропсов, а далее через общий namespace и динамически отображаю каждую.
2) Сделал компонент Row и уже в нем определил все ячейки через v-if v-else if (без создания компонента ячеек просто вынес логику в composable)
3) Сделал компонент Column. Но тут не очень понравилось реализация редактирования и доп фич.
Если не брать 3 вариант, то столкнулся с такой проблемой. В первом варианте выглядит все красиво, но из-за огромного количества компонентов (3500 компонентов ячеек, если не считать ui kits внутри них), dev build грузит одну страницу по 8+ секунд, а иногда тупо крашит devtools, хотя на продакшн все летает. А во втором раздувается template и конструкция v-if v-else выглядит не очень красиво, но зато можно посмотреть в любой момент времени посмотреть dev tool'зы. Над третьим вариантом еще думаю, но при выборе других 2ух склоняюсь ко второму.
А как считаете вы?
В первую очередь должна реализация конечной задачи, затем удобство поддержки, и уже после - удобство отладки, организация кода, и прочее.
Множество v-if v-else - это запашок.
То что оно крашит devtools - это тоже признак, что что-то не так.
Раз уж это таблица, то я бы пошёл по пути, как это в html выглядит:
Компоненты для строк и компоненты для ячеек в строке.
Можно для ячейки один компонент сделать и передавать туда какой-нибудь атрибут type, к примеру.
Василий Банников, отображаются - все. Редактируется - только один.
Таблицу можно отображать голым текстом с примитивным шаблоном, но по клику заменять одну из ячеек полем редактирования. Имея информацию, в каких строке и столбце это происходит.
Я понимаю, что эта логика поперек того, как это обычно делается в реактивных фреймворках, но когда простота означает заведомый оверхед - стоит подумать и об усложнении. Я так думаю.
К сожалению слишком мало информации. Отдельно стоит исследовать почему крашится дветулз, но в целом это не проблема, если не крашится при разработке на меньше количестве ячеек. Потом првоерку не большем количестве проводить уже в (авто)тестах перед релизом в продакшн.
Отдельно отмечу что согласен с Adamos про упрощенный вывод, но снова таки видимо у вас задача слишком там специфичная и большая, сложно конкретно ответить.
Adamos, Все верно тысячи контролов в моменте и не рендерятся. Проблема в количестве отслеживаемых элементов для devtoolsa. Контролы рендерятся только в boolean типе т.к. это чекбокс. А в сам компонент ячейки передаются: тич ячейки, валидаторы, значение ячейки, функция формата ячейки. На рендер одной ячейки уходит 1 -5 мс. При этом нет смысла ячейку описывать одним компонентом лучше разбить на типы ячеек, а потом импортировать это общим namespace'ом (на скорость это не влияет). Проблема именно в количестве отслеживаемых devtools'ом элементов. Можете например попробовать сделать, что-то подобное с quasar таблицей, чтобы с нуля не писать логика.
Сделайте компонент Cell: вывод данных, отображение инпута для редактирования по клику на ячейку, скрытие по blur или нажатию enter. Затем вставьте его в в body slot.
В первом случае отображаю нужный тип ячейки через <component is="getCellComponent"/>, где getCellComponent computed функция достающая из DynamicCell namespace'а нужный компонент ячейки. Забыл об этом дописать, но это не суть.
Средний
