You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@scofalik & @Reinmar - I need to double check this as this changes how table is converted.
After numerous bugs with changing headings + removing rows we concluded that enough is enough. The table models sucks. Downcasting headingRows change requires moving <tr> in the view from <thead> to <tbody> or vice-versa. It can fail in multiple scenarios (#6502, #6437, #6544, #6502, #6391, #6406 + #7454) and would potentially never be OK.
Here (#7454) there was a problem with table layout post-fixer which was called after each enqueueChange() - and thus we hit limit of what API is allowing us to do. The solution is to wait with conversion and post-fixing after all table model changes are done and that table attribute converter would know that also table children are changing.
Possible considered solutions were:
A "hack": set heading rows to 0, remove/add rows, set heading rows to proper value - but it lacks an API for not converting stuff at once.
Some API to mark that some changes need to be either converted at once or should not trigger model post-fixers.
Mark table to be re-rendered at once.
We choose option 3 using differ.refreshItem() - which is called on every headingRows attribute operation as It requires to also take external operations into account when dealing with this bug. Also the API for many TableUtils get simplified but not passing a batch instance (:tada:).
In other words the solution is to re-render whole table in the view if headingRows attribute was changed by any means.
What is needed - some kind of 👍 / 👎 - it might impact collaboration features in some way. Do we need better API for requiring re-converting whole chunk of content?
ps.: @Reinmar this is also some sort of ADR proposal (without sections - but have intro, considered steps and proposed solution).
@scofalik & @Reinmar - I need to double check this as this changes how table is converted.
After numerous bugs with changing headings + removing rows we concluded that enough is enough. The table models sucks. Downcasting
headingRows
change requires moving<tr>
in the view from<thead>
to<tbody>
or vice-versa. It can fail in multiple scenarios (#6502, #6437, #6544, #6502, #6391, #6406 + #7454) and would potentially never be OK.Here (#7454) there was a problem with table layout post-fixer which was called after each
enqueueChange()
- and thus we hit limit of what API is allowing us to do. The solution is to wait with conversion and post-fixing after all table model changes are done and thattable
attribute converter would know that alsotable
children are changing.Possible considered solutions were:
table
to be re-rendered at once.We choose option
3
usingdiffer.refreshItem()
- which is called on everyheadingRows
attribute operation as It requires to also take external operations into account when dealing with this bug. Also the API for manyTableUtils
get simplified but not passing abatch
instance (:tada:).In other words the solution is to re-render whole table in the view if
headingRows
attribute was changed by any means.What is needed - some kind of 👍 / 👎 - it might impact collaboration features in some way. Do we need better API for requiring re-converting whole chunk of content?
ps.: @Reinmar this is also some sort of ADR proposal (without sections - but have intro, considered steps and proposed solution).
Originally posted by @jodator in #7572
The text was updated successfully, but these errors were encountered: