An­drea Gi­ammarchi shows us how to use his hyperHTML func­tion as a fast and light vir­tual DOM al­ter­na­tive

net magazine - - CONTENTS - An­drea Gi­ammarchi

An­drea Gi­ammarchi walks you through his bril­liant vir­tual DO M al­ter­na­tive

Be­fore de­scrib­ing what’s new, in­cred­i­bly sim­ple and ex­cit­ing on the hori­zon, let’s re­mem­ber the main rea­son vir­tual DOM was cre­ated in the first place: Man­ual DOM ma­nip­u­la­tion is messy and keep­ing track of the pre­vi­ous DOM state is hard. A so­lu­tion to this prob­lem is to write your code as if you were recre­at­ing the en­tire DOM when­ever state changes. Of course, if you ac­tu­ally recre­ated the en­tire DOM ev­ery time your ap­pli­ca­tion state changed, your app would be very slow and your in­put fields would lose fo­cus. Taken di­rectly from the orig­i­nal vir­tu­al­dom li­braries ( github.com/Matt-Esch/vir­tu­al­dom#mo­ti­va­tion), I be­lieve we can all agree that man­u­ally tar­get­ing text nodes, at­tributes, in­line styles or lis­ten­ers isn’t ex­actly the coolest part of web devel­op­ment, is it? There are so many things that could go wrong and so much to take care of.

Some His­toric Back­ground First

If we think about the most abused, yet sim­ple to ex­plain and use, DOM El­e­ment prop­erty, in­nerHTML, there are at least two points proven to be valid and agreed by all de­vel­op­ers: It’s deadly sim­ple to trash and sneak any string in, hence its pop­u­lar­ity. It’s a mess due to lost han­dlers, lost ref­er­enced nodes, and a Garbage Col­lec­tor night­mare. Per­for­mance speak­ing, in­nerHTML has his­tor­i­cally been ad­vo­cated as the fastest way to cre­ate HTML lay­outs, a fact in­evitably de­feated by its im­plicit abil­ity to de­stroy all JavaScript logic pre­vi­ously set around the ex­ist­ing lay­out; logic that has to be re-set ev­ery sin­gle up­date, which is un­bear­able for both mo­bile and even mod­ern desk­top browsers. In sum­mary, ev­ery web de­vel­oper learned that trash­ing doc­u­ments and nodes on ev­ery up­date via in­nerHTML as­sign­ments isn’t re­ally the way to go. Ev­ery­body learned that in­nerHTML was an evil path to avoid at all costs, like eval could be on the JavaScript side.

Vir­tual DOM Ba­sics

Since the DOM API is huge, and for many de­vel­op­ers sim­ply too com­plex, deal­ing with mod­els, data or states, and be­ing able to re­fresh au­to­mat­i­cally any view once up­dated, sim­ply won the au­di­ence.

In short, you up­date your ap­pli­ca­tion state and the rest ren­ders au­to­mat­i­cally, re­cy­cling be­hind the scenes ev­ery­thing that can be re­cy­cled on the DOM world. De­vel­op­ers don’t need to di­rectly deal with the view any­more, they just de­fine such a view once and deal with the data that gen­er­ated it – noth­ing else. Most im­por­tantly, even if most Vir­tual DOM li­braries ad­vo­cate the glory of im­mutabil­ity, the DOM han­dled by these li­braries is never re­gen­er­ated or copied/du­pli­cated from zero. The DOM han­dled by Vir­tual DOM li­braries that ad­vo­cate im­mutabil­ity is mu­tated ev­ery time it’s needed, be­cause that’s the cheap­est and fastest way.

Vir­tual DOM Logic

While the pur­pose is to fo­cus on states and data from a de­vel­oper point of view, the goal is to re­flect these changes with the least amount of na­tive DOM op­er­a­tions on the browser. This means that a list of users, shown in­side a reg­u­lar <li> el­e­ment, shouldn’t be re-ren­dered if just one user on that list changes the ad­dress. ‘Diff­ing’ be­comes the word that mean­ing­fully de­scribes what the Vir­tual DOM is about: track­ing two dif­fer­ent states and re­flect­ing dif­fer­ences on the view.

In sum­mary, Vir­tual DOM is, to sim­plify, an Ar­ray and Ob­ject travers­ing and com­par­ing pro­ce­dure, the aim of which is to find out which re­lated node at­tribute, text con­tent or sub­tree should be up­dated on the next ren­der call.

Newspapers in English

Newspapers from Australia

© PressReader. All rights reserved.