Vue: DOM errors during component patching shouldn't break the app
What problem does this feature solve?
Loading a vue component with a syntax error breaks the the entire application. More robust handling of the error in the stack.
See fiddle:https://jsfiddle.net/mgoetzke/f0cd61a3/
When pressing 'Show 3' first a new item appears. When pressing 'Show 2' first it will break the app and 'Show 3' won't work anymore.
[Vue warn]: Error in nextTick: "InvalidCharacterError: Failed to execute 'setAttribute' on 'Element': 'style ' is not a valid attribute name."
warn @ [email protected]:485
handleError @ [email protected]:568
(anonymous) @ [email protected]:709
nextTickHandler @ [email protected]:654
Promise resolved (async)
timerFunc @ [email protected]:669
queueNextTick @ [email protected]:717
queueWatcher @ [email protected]:2815
update @ [email protected]:2950
notify @ [email protected]:784
reactiveSetter @ [email protected]:1006
proxySetter @ [email protected]:3075
click @ VM632:2
invoker @ [email protected]:1820
[email protected]:572 DOMException: Failed to execute 'setAttribute' on 'Element': 'style ' is not a valid attribute name.
at setAttr (https://unpkg.com/[email protected]:5816:10)
at Array.updateAttrs (https://unpkg.com/[email protected]:5776:7)
...
What does the proposed API look like?
There would not be a new api, just don't render anything and log the error but don't break the rest of the application similar to html parse errors.
matthiasg
All 2 comments
An app containing a component with template syntax error is a broken app by definition. This is not a runtime exception; it's something the developer has responsibility of fixing before deploying the app.
yyx990803
on 14 Sep 2017
@yyx990803 while I am also all for closing issues quickly, I think this was premature.
Of course such an app is broken, but the entire app does not work once such a broken template comes into play. These can make such issues way harder to debug than necessary during development and prototyping. Especially since this error only applies to the compiler case anyway (html template -> code).
In our case we allow developers and designer to fully live edit templates with live preview against live data. The fact that a specific template doesn't yet render and emits an error is fine. But that the entire application becomes useless is annoying. We will now have to instantiate a second Vue instance to 'test' the compiler pipeline before using it.
That works of course, but one reason HTML applications are so successful is their resilience to many error scenarios. The alternative is a WPF/XAML like experience where the slightest compilation or runtime mistake renders nothing at all. The long term goal of any rendering layer should try to be at least somewhat resilient to errors as Vue already is.
In the aforementioned case rendering
is renderable html and should not break everything. Especially when it might be easy to fix.I would hope you might be at least open for us to propose a pull request if we find time to investigate where in the pipeline to best make a fix that does not affect performance or maintainability.
regards
PS: In our case after the prototyping phase all components are turned into server side rendered components automatically and of course only once valid.
matthiasg
on 16 Sep 2017
Related issues
ecmel
路
52Comments
karevn
路
36Comments
asiFarran
路
34Comments
RashadSaleh
路
51Comments
rpkilby
路
50Comments
Most helpful comment
@yyx990803 while I am also all for closing issues quickly, I think this was premature.
Of course such an app is broken, but the entire app does not work once such a broken template comes into play. These can make such issues way harder to debug than necessary during development and prototyping. Especially since this error only applies to the compiler case anyway (html template -> code).
In our case we allow developers and designer to fully live edit templates with live preview against live data. The fact that a specific template doesn't yet render and emits an error is fine. But that the entire application becomes useless is annoying. We will now have to instantiate a second Vue instance to 'test' the compiler pipeline before using it.
That works of course, but one reason HTML applications are so successful is their resilience to many error scenarios. The alternative is a WPF/XAML like experience where the slightest compilation or runtime mistake renders nothing at all. The long term goal of any rendering layer should try to be at least somewhat resilient to errors as Vue already is.
In the aforementioned case rendering
is renderable html and should not break everything. Especially when it might be easy to fix.I would hope you might be at least open for us to propose a pull request if we find time to investigate where in the pipeline to best make a fix that does not affect performance or maintainability.
regards
PS: In our case after the prototyping phase all components are turned into server side rendered components automatically and of course only once valid.