Comments 13
Спасибо за инфу.
А почему у них в демке чекбоксы не отмечаются у детей при отметке родителей?
Это же косяк, в моем понимании, причем серьезный.
А почему у них в демке чекбоксы не отмечаются у детей при отметке родителей?
Это же косяк, в моем понимании, причем серьезный.
0
Это там и в других примерах так…
Могу ошибаться (не использовал отметки) но, по-моему, у них дерево — это нахлобучка сверху на обычный grid. Соответственно, для выборки детей логику нужно самому дописывать, что для примеров посчитали лишним.
Могу ошибаться (не использовал отметки) но, по-моему, у них дерево — это нахлобучка сверху на обычный grid. Соответственно, для выборки детей логику нужно самому дописывать, что для примеров посчитали лишним.
0
Спасибо за фидбек по поводу рекурсивного селекшена. Планировали добавить.
0
Первый пример на сайте показывает как работать с иерархичными данными: devexpress.github.io/devextreme-reactive/react/grid/docs/guides/tree-data
+2
Там именно вложенные друг в друга объекты с массивами на вход подаются? К сожалению в примере не посмотреть, что за тестовые данные используются.
0
Да. Массивы вложенных элементов хранятся в items
поле элемента.
0
А ключ обязательно должен называться одинаково на всех уровнях? Если поменять, скажем, на втором уровне 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 клиентом данные перед их передачей компоненту — очень кривой подход, хочется без этого обойтись.
0
Если я все правильно понял, вы всегда можете усложнить функцию getChildRows. Например так: (row, rootRows) => (row && (row.items || row.nestedItems)) || rootRows
+2
(row ? (row.questions || row.answers) : rootRows)
помогло, спасибо. В итоге, значит я всё-таки изобрёл велосипед.
-1
Вдогонку ещё один вопрос возник. Показывается-то всё отлично, но теперь при удалении (изменении) значения неясно, как внутри функции, вызываемой в EditingState onCommitChanges={commitChanges} понять, что именно мы удаляем (т.е. для какого объекта нужно выполнять, скажем, mutation delete).
В commitChanges передаётся только индекс (например, 68). Для плоского массива этого достаточно, но здесь-то уже не плоский массив…
В commitChanges передаётся только индекс (например, 68). Для плоского массива этого достаточно, но здесь-то уже не плоский массив…
0
Предполагается что вы объявляете getRowId метод в Grid при использовании редактирования. Тем самым вы будете получать не индекс, а id вашего изменяемого объекта.
0
Кстати, а почему бы не передавать в commitChanges текущий редактируемый объект? Допустим, у меня дерево как описано выше в посте (тесты, вопросы, ответы к ним). И я хочу отредактировать вопрос. Чтобы после редактирования обновить информацию в базе соответствующим mutation'ом, мне надо знать, что отредактирован был именно вопрос (а не тест и не ответ). Сейчас я могу получить в commitChanges лишь id. Чтобы узнать тип (свойство __typename), мне придётся ещё искать этот объект в дереве по его id.
0
Sign up to leave a comment.
Конвертация данных GraphQL для компонента CustomTreeData из DevExtreme-Reactive