Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 13
Спасибо за инфу.
А почему у них в демке чекбоксы не отмечаются у детей при отметке родителей?
Это же косяк, в моем понимании, причем серьезный.
А почему у них в демке чекбоксы не отмечаются у детей при отметке родителей?
Это же косяк, в моем понимании, причем серьезный.
Это там и в других примерах так…
Могу ошибаться (не использовал отметки) но, по-моему, у них дерево — это нахлобучка сверху на обычный grid. Соответственно, для выборки детей логику нужно самому дописывать, что для примеров посчитали лишним.
Могу ошибаться (не использовал отметки) но, по-моему, у них дерево — это нахлобучка сверху на обычный grid. Соответственно, для выборки детей логику нужно самому дописывать, что для примеров посчитали лишним.
Спасибо за фидбек по поводу рекурсивного селекшена. Планировали добавить.
Первый пример на сайте показывает как работать с иерархичными данными: devexpress.github.io/devextreme-reactive/react/grid/docs/guides/tree-data
Там именно вложенные друг в друга объекты с массивами на вход подаются? К сожалению в примере не посмотреть, что за тестовые данные используются.
Да. Массивы вложенных элементов хранятся в items поле элемента.
А ключ обязательно должен называться одинаково на всех уровнях? Если поменять, скажем, на втором уровне item на item2, то уровень перестаёт отображаться.
В документации упоминается некий
getRowLevelKey — A function used to get a group row level key.
Но как его использовать — неясно.
Проблема в том, что как-либо модифицировать полученные GraphQL клиентом данные перед их передачей компоненту — очень кривой подход, хочется без этого обойтись.
В документации упоминается некий
getRowLevelKey — A function used to get a group row level key.
Но как его использовать — неясно.
Проблема в том, что как-либо модифицировать полученные GraphQL клиентом данные перед их передачей компоненту — очень кривой подход, хочется без этого обойтись.
Если я все правильно понял, вы всегда можете усложнить функцию getChildRows. Например так: (row, rootRows) => (row && (row.items || row.nestedItems)) || rootRows
(row ? (row.questions || row.answers) : rootRows)помогло, спасибо. В итоге, значит я всё-таки изобрёл велосипед.
Вдогонку ещё один вопрос возник. Показывается-то всё отлично, но теперь при удалении (изменении) значения неясно, как внутри функции, вызываемой в EditingState onCommitChanges={commitChanges} понять, что именно мы удаляем (т.е. для какого объекта нужно выполнять, скажем, mutation delete).
В commitChanges передаётся только индекс (например, 68). Для плоского массива этого достаточно, но здесь-то уже не плоский массив…
В commitChanges передаётся только индекс (например, 68). Для плоского массива этого достаточно, но здесь-то уже не плоский массив…
Предполагается что вы объявляете getRowId метод в Grid при использовании редактирования. Тем самым вы будете получать не индекс, а id вашего изменяемого объекта.
Кстати, а почему бы не передавать в commitChanges текущий редактируемый объект? Допустим, у меня дерево как описано выше в посте (тесты, вопросы, ответы к ним). И я хочу отредактировать вопрос. Чтобы после редактирования обновить информацию в базе соответствующим mutation'ом, мне надо знать, что отредактирован был именно вопрос (а не тест и не ответ). Сейчас я могу получить в commitChanges лишь id. Чтобы узнать тип (свойство __typename), мне придётся ещё искать этот объект в дереве по его id.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Конвертация данных GraphQL для компонента CustomTreeData из DevExtreme-Reactive