konsoletyper / teavm-flavour

Framework for writing client-side applications using TeaVM
Apache License 2.0
110 stars 19 forks source link

App crashes when DOM is modified externally #28

Open vic-cw opened 5 years ago

vic-cw commented 5 years ago

Disclaimers:

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

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:

Steps to reproduce

ScraM-Team commented 5 years ago

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 commented 5 years ago

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

https://github.com/konsoletyper/teavm-site/pull/23

vic-cw commented 5 years ago

@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.