Could we supress the "property list length changed" message?
StephenWakely opened this issue · comments
Regarding this error that pops up :
VDom: Failed swapping properties because the property list length changed, use
noPropto swap properties instead, not by altering the list structure. This is a massive inefficiency until this issue is resolved.
Sometimes I know I am changing the property list length and I am happy to take the performance hit because it happens under rare circumstances.
Would it be possible to make it so I could suppress this warning when I know I really don't mind?
No, you can't, it will break things if you do that. You can use this function noProp if you don't want it. It is the same when it comes to styles because it is implemented with this function List.fold_left2
It is far FAR better to replace the property you are removing with noProp (that is it's purpose) as it keeps the diff aligned for faster patching of the DOM. Honestly I'd make it hard error (I did originally) when that happens but I keep it as a warning instead for compatibility with copied elm code. But yeah, it really really is a bug in the user code to change the length of the property list. For what reason would you not want to use noProp? If you have a good reason then I can make it configurable though but as it stands it is a performance bug in user code. :-)
Maybe I am misunderstanding the error.
I am not just changing the length of the property lists, I am changing everything. Essentially, I have a view mode, whereby the data is represented as a list of labels and spans, and I have an edit mode, where the data is represented as a list of labels and input fields. The spans and inputs naturally have different properties associated with them.
Hitting a save/edit button swaps between the two modes, and pops up the warning.
I suppose I could work around it by showing both view and edit modes at the same time and just swap a display:none/block property, but it just feels cleaner not doing it this way. But I do not understand how it is all working at a low enough level to know if this would be a more efficient way.. Maybe you could advise?
The spans and inputs naturally have different properties associated with them.
If they are truly different element types like span and input then that message will not happen, that code path will not even be followed as a full swap then happens. It has to be elsewhere. If you can show your view code in full then I could probably find it. :-)
Ok, I've worked it out. Even though View and Edit are different functions they do share some html structure. There were a different number of properties with some of these. Sticking a noProp in the right place fixes the problem.
Thanks for the help!
Ok, I've worked it out. Even though View and Edit are different functions they do share some html structure. There were a different number of properties with some of these. Sticking a noProp in the right place fixes the problem.
If they have a major change you can always 'unique' key them differently so swapping between each will blast the old one away. But yes, if you want absolute performance then sharing as much as possible and peppering in noProp's is the fastest code. :-)
Ah! Yes that is probably what I want to do. I can't work out how to key an element.. Any ideas?
Just call the node function straight while specifying a non-empty unique node element. :-)
https://github.com/OvermindDL1/bucklescript-tea/blob/master/src/tea_html.ml#L16
unique causes a full swap when it changes. key only updates down inside when the key changes (think Elm's lazy).
Yes that works well. I suppose the reason it is fairly hidden is because you want to discourage using it, which is fair enough!
Thanks for your help.
Yes that works well. I suppose the reason it is fairly hidden is because you want to discourage using it, which is fair enough!
Well not really discourage using it, rather it does not fit into the Elm API, but I really wanted it accessible 'somehow' because it is such a nice performance boost when used properly, so it was rather that my hands were tied so I could keep the Elm API intact. ^.^
It is actually fully encouraged to use it, if it is appropriate to use, and you don't mind breaking out of the Elm API just a bit. :-)