App crashes when DOM is modified externally

[vic-cw]

Disclaimers:

• I am not 100% sure this is the cause of the problem that I am seeing
• I am using Flavour 0.1.0, so this might have already been fixed since
• This is somewhat linked to another issue already open, but the specific case I am mentioning here can probably easily be handled

Summary

When modifying DOM externally, for example by inspecting Elements in Devtools, and then doing something that causes a parent AbstractComponent to be destroyed, app crashes with this stack trace :

Uncaught TypeError: Failed to execute 'removeChild' on 'Node': parameter 1 is not of type 'Node'.
at Gec (Space.java:48)
at Gx.main [as VR] (TArrays.java:1516)
at AVb (AbstractComponent.java:27)
at Zv.main [as x] (TArrays.java:1516)
at C3c (DomComponentTemplate.java:46)
at RJ.main [as x] (TArrays.java:1516)
at Ymb (AbstractWidget.java:42)
at Ju.main [as x] (TArrays.java:1516)
at C3c (DomComponentTemplate.java:46)
at RJ.main [as x] (TArrays.java:1516)

My theory of what is happening

• when modifying the DOM manually, a new Node is created, the old node becomes null or considered irrelevant
• when destroy() is called, it calls domNode.removeChild(...), which throws this error

To fix it or not to fix it

This is linked to this issue.

It seems that React also has this problem: https://stackoverflow.com/a/49618472/2873507

I understand that fundamentally, DOM manipulation and using a framework such as React or Flavour are mutually exclusive.

However, it seems to me that this specific problem could be easily avoided, by checking whether element is null before calling removeChild.

The benefits of this would be:

• This might prevent Flavour from being incompatible with (at least) some extensions such as Google Translate
• This will save some time to developers who are looking at their DOM in DevTools, not modifying it but just copying some data, then seeing app crash, wondering why and going on a debug mission, losing a lot of time.

Steps to reproduce

• Load page
• Open Devtools
• Go to Elements tab
• Double click on some inner text, not modifying it, but so that it be selected
• Click outside of the "edited" HTML
• Trigger an action on the page that will destroy a parent component of that text
  • it should not be a call to setView
  • the component should be destroyed, not just hidden. For example it should be something inside an if

[ScraM-Team]

First off, thanks for posting about Flavour! It is an incredible framework and I'm glad to hear about other people using it.

Like you said, changing the DOM without Flavour's knowledge will cause it to get confused, like any framework that keeps its own model and updates the DOM from its internal model. That seems reasonable.

I also agree that it would be helpful to have more documentation about what is OK (reading from the DOM is harmless) and what is problematic (removing DOM nodes is particularly problematic).

After a lot of Flavour usage, I have come to get a feel for how to do things "the Flavour way", using binding and Flavour elements instead of heavy DOM manipulation. Please let us know what you have been doing where you feel DOM manipulation is necessary. I'd like to see if the same requirements can be met via Flavour features.

Looking forward to hearing more...

[ScraM-Team]

One other note, I proposed a small note in the Flavour documentation about this here:

konsoletyper/teavm-site#23

[vic-cw]

@ScraM-Team thanks a lot for your answer!

The precise example of what happened to me, which caused the DOM to be modified, and that cannot be reproduced using "Flavour mechanisms" is pretty simple : I just inspected the DOM manually in DevTools, and copied some innertext that I wanted to save.

The problem with it, is not that it would be bad end-user experience, since end-users are not supposed to go into DevTools.

The problem is that other developers like me, using Flavour, might copy something from the DOM using DevTools, see the page crash, not think that it was due to them copying something from DevTools, and spending a lot of time trying to reproduce the bug, mistakenly thinking that they have done something wrong.

So in my precise case, the goal is to avoid time lost of Flavour users.

But in general, I think it would help to avoid a crash when possible. This might save things such as Chrome extensions, for example page translations.