Hvordan vi har bygget en realtidssketch-to-code-motor (med live preview)

Hej Verden,

hurtige spørgsmål:

Er det ikke meningen, at (web / mobil) designere og udviklere skal tale det samme sprog?

Er vi ikke alle på udkig efter apps / websteder, der ser smukke ud og fungerer problemfrit?

Kan vi gøre hele mobil / web-bygningsprocessen lidt mere human?

Der er helt klart en kløft mellem designere og udviklere. Dette synes alt for velkendt, og til min overraskelse ser det ud til, at vi mest har forsøgt at navigere rundt i det i stedet for at vende mod det.

Kan vi rette dette forkert?

Omkring et år tilbage, da jeg arbejdede på en mobilapp, fik jeg mig selv fast i en uendelig ping-pong med min designer, hovedsagelig tilpasning af, hvordan appen ser ud og opfører sig. De fleste af disse ændringer handlede kun om positionering, farver, afstand osv. I stedet for at bruge min tid til at implementere appens virkelige værdi med at få tarm, blev ca. 60% brugt på at udføre ikke-erhvervslogisk relevant arbejde aka ”pixel pushing”. I det væsentlige var alle de "handlinger", som designeren udførte i Sketch, jeg var nødt til at gøre igen i kode. Det for mig så ud som en fuldstændig ineffektiv proces og den banede vej til frustration. Og en glemt frist. Eller to :)

Min første tanke var "Jeg bruger sandsynligvis ikke de rigtige værktøjer ... der skal være en måde ..."

Ikke selv at være designer og temmelig uvidende med Sketch, begyndte jeg at kigge rundt efter nogle løsninger, der kunne hjælpe, men alt hvad jeg kunne finde var plugins eller apps, der gjorde en del af jobbet. Så hvorfor gider det med at bruge noget, der kun vil tilføje mere kompleksitet til en allerede ineffektiv proces?

Hold fast, så… hvad leder vi faktisk efter?

Kort sagt, det er det, jeg gerne vil have:

  1. designeren skal være i stand til at “forhåndsvise” designene på sin enhed / browser i realtid. Men ikke simuleret. Han skulle se forhåndsvisningen som den rigtige aftale, som om en udvikler ville have implementeret den for ham.
  2. når designeren trækker en knap, skal udvikleren få et "knap" -kodestykket klar til brug i appen / webstedet
  3. Udvikleren skal vælge kodens sprog og dialekt eller kodningstil.

Det ser ud til, at der er nogle fremragende værktøjer til at dække dele af kravene, og de falder inden for to kategorier: prototype-værktøjer og målspecifikke “hjælpere”.

Mens værktøjer som InVision og for nylig Sketches eget indbyggede prototype-system gør et godt stykke arbejde til prototype, går de kun så langt som "prototype". Det drejer sig mest om tilnærmelser eller simuleringer af slutresultatet, og de holder op med at være nyttige lige der. Der er ikke meget mere, du kan gøre med dine prototyper, når du først har bygget dem (bortset fra at overveje deres skønhed). De kan ikke genbruges eller videreudvikles mod et ”rigtigt” produktionsklart resultat. Derfor har du nu brug for en udvikler til at kode UI'en, så tilbage til firkantet.

På den anden side gør målspecifikke værktøjer, såsom Zeplin, meget ved at hjælpe udvikleren med at "vælge" stylingoplysninger, men de giver sjældent den fulde kontekst, plus de er nøjagtigt, hvad de kaldes "målspecifik", med næppe eventuelle konfigurationer mulige.

En anden værd at nævne tilgang er blevet foreslået af fyrene fra Anima gennem deres Launchpad plugin til Sketch, der eksporterer almindelig HTML / CSS.

Selvom der er masser af værktøjer, der får dig et godt stykke foran målet, har designeren stadig brug for en udvikler for at kunne opleve sine design i den "oprindelige verden", plus der er behov for en masse manuel finjustering bagefter.

Derefter tanken:

Hvad skal det til for at fange designerens "input" og oversætte det til kode i realtid?

Og dette var frøtanken, der bragte en flok teknologier sammen, som jeg mødte på JSHeroes-konferencen 2017 i Cluj, Rumænien.

Den korteste måde, vi kunne forestille os, hvordan vi tackle denne udfordring, var at prøve at definere layoutrepræsentationen i et kode-agnostisk format, hvorfra vi gennem en parser af en eller anden art genererer koden.

I betragtning af at vi beskriver et web / mobildokuments struktur, ville en VDOM-lignende model have været det første valg, men på en eller anden måde kombineret med nogle koncepter, der findes i AST. Endelig har vi valgt en tilpasset afdækket struktur inspireret af dem. JSON-repræsentationen syntes at være det valgte format for opgaven på det tidspunkt, i betragtning af at:

  • det er menneskeligt læsbart
  • det understøttes bredt af stort set ethvert kodesprog
  • det er let at lagre og overføre

JSON Intermediary Representation (JSON IR)

Den foreslåede JSON IR består af en trælignende struktur af noder, som vi kalder elementer. Hvert element har mindst en typeattribut og flere andre valgfri attributter såsom stil, børn og navn.

Uden at gå for mange detaljer, som de skal dækkes i en fremtidig artikel, et par bemærkninger om hver af ovennævnte attributter:

  • type: en streng, der definerer elementets art. Uanset om vi taler om web- eller mobildesign og -udvikling, er byggestenene stort set de samme: visninger, tekster, billeder, input og knapper, der til sidst samles i mere komplekse elementer. Vi vil gå så langt som at sige, at disse byggeklodser er her for at blive, selvom vi går ind i AR / MR-verdenen, så man kan aftale en generisk beskrivende navnekonvention, der kan oversættes via en kortlægning til ethvert mål.
  • stilarter: et JSS-objekt. JSS er valgt, da det dækker alle webstylingegenskaber og kan oversættes til andre formater, såsom CSS, React styling-objekter, React Native StyleSheet-objekter osv.…
  • børn: en række elementer eller en streng (for eksempel en simpel etiket)

Lad os tage et eksempel for at gøre alt dette mere visuelt. Følgende billede viser et grundlæggende brugergrænseflade, der er lavet af en boks, der indeholder en etiket og et billede:

Eksempel på en kasse, en etiket og et billede

Det er tilsvarende JSON IR ville se sådan ud:

Når vores repræsentationslag er defineret, kan vi nu fokusere på faktisk at indsamle den visuelle information fra designerens miljø.

Sketch-plugin (eller designkilden)

Sketchs åbne filformat giver os mulighed for at læse dets indhold, men det opfylder ikke vores krav i realtid. Dog giver Sketch et plugin mulighed for at abonnere på begivenheder, der finder sted inden for dets arbejdsområde, og at læse egenskaberne for Sketch-objekterne, som vi konverterer til vores JSON IR.

Indtil videre har vi en designkilde (Sketch) og en realtid mellemledsrepræsentation (vores JSON IR). Derefter har vi implementeret en lokal server, der fungerer som et lager- og relæsystem for JSON IR genereret af Sketch-plugin.

Kodegenerering og Live Previewer

Når vores JSON IR var vedvarende, kunne vi overføre den til et kodegenereringsbibliotek eller en live previewer. Vi har målrettet React and React Native på dette trin, da de bruger en komponentbasearkitektur, og de dækker to vigtige "mål": web og mobil, så vi har bygget et par af begge til begge mål.

Nedenfor kan du se et meget grundlæggende flowdiagram, der beskriver JSON IR-strømmen mod en kodegenerator og en live previewer med deres respektive output:

Vi offentliggør snart flere oplysninger om, hvordan de fungerer, men lad os nu se på, hvordan en reageret genereret kode ville se ud for vores JSON IR:

Alternativt ser React-Native-koden sådan ud:

BEMÆRK: i dette eksempel er positioneringen bevidst indstillet til absolut af hensyn til enkelheden. Vi vil dække dette emne i en fremtidig artikel i betragtning af emnets kompleksitet. I mellemtiden kan du se på Karls artikel om Figma til React-kodegenerering.

Smugkig

Her er en lille demonstration af, hvordan alt dette fungerer. I videoen kan du se vores tidlige fase Sketch-plugin i aktion, og hvordan designkilden> intermediær repræsentation> kodegenerering> live preview-flow føles.

Videoen er en simulering af en designeroplevelse med at opbygge JSHeroes webstedets menu.

På skærmen:

  • venstre side: vores dashboard viser JSON IR og genereret React-kode, side om side
  • øverste højre hjørne: en web-live previewer
  • nederst til højre: Skitse med Teleport-pluginet indlæst.

Pak ind

Indtil videre bekræftede vi, at der er en bæredygtig teknologisk vej til opbygning af real-time design-til-kode-oplevelser, gennem hvilke designkilden og målkoden kan afkobles fuldstændigt.

Indtil videre er vi i stand til at generere React, React Native, Vue, HTML / CSS og AngularJS-kode.

Sikkert, den hellige gral ville være en tovejs tilgang, hvor JSON IR kunne genereres ved at fortolke kildekoden, og derfor elsker vi Jon Gulds tilgang i React Sketch App. Vi vil meget anbefale at tjekke projektet.

Vi sigter også mod at åbne kildekode disse værktøjer ASAP via Github på https://github.com/teleporthq, så hold øje med.

Vi ser frem til dine tanker og feedback, så kom i kontakt med os via Twitter. :)

Skål!

P.S .: Hvis du er interesseret i at lære mere om vores rejse, kan du tilmelde dig vores nyhedsbrev her.