RSHB/DFiP_Budget_planing
9
0
Fork 0
Code Issues 22 Pull Requests 22 Actions Packages Projects Releases Wiki Activity

docs(openspec): aurora-1839 — выровнять D1 «Уточнение» с фактом table-core (I-3)

Browse Source 
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
This commit is contained in:
Andrey Epifancev 2026-10-28 22:00:28 +04:00
parent 472f2ea222
commit 28b238cea4
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
openspec/changes/aurora-1839-cell-memo/design.md
View File

@ -117,7 +117,7 @@ const tableColumns = useMemo(() => [...columns], [columns, cellMemoResetKey]);
Почему это работает: TanStack мемоизирует колонки по идентичности массива `options.columns` (Контекст, п. 3). Новый массив с теми же определениями даёт новые `Column`, а за ними и новые `cell`. Это фиксирует тест-допущение.
Уточнение (O-1, решение 18): закрепление или открепление колонки само пересоздаёт только ячейку этой колонки, а `left` у остальных закреплённых и сдвиг центральных мемоизированная ячейка не пересчитает. Поэтому ключ сброса по раскладке закреплённых нужен и на table-core 8.20.5. Поведение зафиксировано тестами `table-core:` в `cellMemoReset.test.js`, при обновлении table-core они покажут смену.
Уточнение (O-1, решение 18): закрепление, открепление и скрытие закреплённой колонки пересоздают ячейки закреплённой стороны (копии `{...cell, position}` в `getLeftVisibleCells`/`getRightVisibleCells`), центральные ячейки остаются теми же, а смена ширины не пересоздаёт ничего. Поэтому ключ сброса по раскладке закреплённых нужен и на table-core 8.20.5: он ловит смену ширины закреплённой колонки (`left` соседей справа) и служит страховкой от поведения MRT. Поведение зафиксировано тестами `table-core:` в `cellMemoReset.test.js`, при обновлении table-core они покажут смену.
Отвергнутые альтернативы:
- **Добавить ключ в зависимости `getTableColumns`.** Тогда `structuredClone` конфигурации листа (`tableColumns.jsx:126`) и `processColumns` выполнялись бы на каждое изменение поиска и на каждый символ в фильтре колонки. Работа лишняя: определения от этих состояний не зависят.