How "written in stone" is the rule about not changing state in $derived?

[webJose]

Describe the problem

My component @wjfe/dataview uses a $derived to calculate the necessary information to lay out the component's data columns. This is great. Actually, the entire component is driven by just this one computation.

However, at work there is this need: In data drilling scenarios where "row expansion" shows another table that describes in more detail the expanded row's data (see this page for a live data-drilling example), users want that certain columns of the "child" table be visually synchronized in position and width with the equivalent parent table's column.

To achieve this, I have been thinking about this long and hard and I finally came up with a very effective way of achieving this cross-table column synchronization feature. It is actually functional in this REPL.

The problem: The calculation of the filler columns require setting state! Setting state while calculating a derived is currently forbidden. This forced the REPL to redefine colDefs as $state which is updated in an $effect. The terrible part of this is: My component would no longer be able to nicely server-render because effects don't run in SSR.

Describe the proposed solution

Somehow allow state mutation from a $derived?? I have no other idea except allowing it. If anyone has a better solution, I'll welcome it.

Importance

would make my life easier

[Ocean-OS]

Couldn't you use an $effect? I know it's not recommended for everything, but it seems necessary for this case.

[webJose]

It is using $effect.pre. This is exactly the problem: Effects don't run in SSR, so the columns cannot be rendered in SSR.

[Ocean-OS]

Ah, I see, then #14784 would probably be the best solution, if it's merged.

[webJose]

Interesting. So the new unsafe() API function would allow me to mutate column.sync.expectedLeft inside a $derived, as I understood the PR. Yes, it is what I need!

[dummdidumm]

It's "written in stone" insofar that the current behavior is there to ensure consistency of the reactive graph. Else mutations could produce subtle and indirect bugs which you would spend hours debugging. #14784 would certainly help with this, therefore closing.

[webJose]

Yes, thank you for the explanation. I'm impatiently waiting for that PR to go live. 😄