Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
So you know, that's also been my experience and is the level of ability I've come to expect out of Vue projects.
Isn't async different in JS though? Everything is synchronous technically because it just gets SMOOSHED into the event loop when it's ready?
So really that should be fine, no? Usually this is bad thanks to thread safety and all that, but there are no such worries in JS.
ltlian2046237d@AlgoRythm The problem is that it's now uncertain what Vue thinks of the component state when it creates it. It has no way of reading the dom, so when you modify it in this way you end up with all kinds of deep voodoo. The async is just icing on the cake.
It's often the very first warning you run into when diving into getting started guides. Bold. With a red background.
And this is a 4 year old project with page after page after hundreds (after thousands?) of lines with this stuff.
On top of Vue specific issues, InnerHTML usage should be avoided in most cases. Even though It's not as bad as it used to be (won't execute scripts anymore), it's behavior is still obliterative.
Innerhtml always causes a full dump and reevaluation of whatever text was placed into it. The correct way to go about it is usually to work directly with the DOM Element API so you impact the smallest change possible.
ltlian2046237dObliterative is a good word.
For consistency, I tend to follow the discrete practice and create a new instance of the root element and then add it to the contextual parent using replaceChild.
Frameworks that handle the rendering tend to use this approach as well; compose the whole modified graph and apply once. This can be further optimized using requestIdleCallback if your SLA allows for it.