Ladění Vue.js:Jak opravit frontend vaší aplikace (s výukovým programem)

Významným milníkem produktivity v mé programátorské kariéře bylo naučit se správně ladit.

Ve škole ti říkají, že je to důležité. Ale stejně jako programování se nezlepšíte, pokud nevložíte hodiny.

Ladění probíhá ve všech fázích vývojového cyklu. Ať už se jedná o vývoj od začátku, údržbu nebo refaktorování kódu, budete muset ladit.

V tomto příspěvku budeme používat hlavně Vue.js, ale některé tipy jsou dostatečně široké, aby je bylo možné použít v jakémkoli kontextu vývoje, dokonce i v životě, pokud budete dostatečně mžourat.

Zde je to, co prozkoumáme:

1. Nástroje potřebné k ladění vašeho frontendu

2. Typy tříd chyb, se kterými se setkáte

3. Nejlepší strategie k použití

4. Praktický kurz ladění Vue.js

Otevřete tedy svůj prohlížeč spotřebovávající RAM a začněte s laděním!

S nástroji (nástroje pro ladění v prohlížeči Chrome) nejsou žádní hlupáci

První věc, kterou byste měli udělat při práci na jakémkoli projektu, je nastavení správných nástrojů. Nástroje jsou zjevně svázány s technologickým zásobníkem. U malého projektu se to může zdát triviální, ale sledování vašich závislostí je ve velkém měřítku zásadní.

Moje definice může být příliš široká, ale nástroje bych definoval jako cokoli, co nabízí další možnosti pro práci s danou technologií. Přidávání ligatur písem do kódu VS (banální, ale stojí to za to) nebo použití celého rámce pozorovatelnosti jsou různé druhy „nástrojových“ variant.

Jak již bylo zmíněno, nastavení nástrojů by mělo být provedeno před laděním. Není nic méně lákavého než po zjištění chyby oddálit a začít dolaďovat svůj opasek.

Pro naši ukázku budeme pracovat s IDE a prohlížečem. Jako své IDE používám VS Code, a tak jsem si na Chrome nainstaloval rozšíření Vetur, které mimo jiné formátuje komponenty jednoho souboru.

Můžete dále upravovat kód VS a ladit přímo v IDE, ale dávám přednost tomu v Chrome. Pokud je to cesta, kterou chcete prozkoumat, můžete si o ní přečíst více zde.

Pokud jde o prohlížeč, používám Chrome a budu používat devtools Vue.js. S tímto rozšířením budete moci přímo prohlížet komponenty Vue, nahlížet do routeru a cestovat v čase přes vaši historii stavu. To vám ušetří spoustu času, pokud hodně pracujete s aplikacemi Vue, věřte mi.

Pokud jste ve Vue noví, zvažte seznámení se základy zde:

• Úvod do Vue.js

• Co je Vue.js?

• Vue.js vysvětleno za 100 sekund (video)

Ladění typů chyb a triků

Většina chyb, na které narazíte, bude způsobena:

→ Objekty, ke kterým přistupujete, mají jiné typy, než jste si mysleli.

→ Některé hodnoty prostě chybí.

Jako když si myslíte, že pracujete v numbers, ale ve skutečnosti máte string "42". Mnohé z těchto chyb lze opravit rozšířením JavaScriptu o jazyky, jako je TypeScript, ale to si necháme na další konverzaci.

Další běžný problém:

→ Něco, co se nechová tak, jak jste si mysleli

Mohou to být jazyková primitiva nebo knihovny. Sakra, hodiny, které jsem ztratil pomocí funkcí pole špatným způsobem, jsou pravděpodobně dvouciferné. Je těžké to zjistit, pokud si očekávané chování výslovně neprozkoumáte. Proto je čtení dokumentů tak zásadní.

Pokud jste po prohlédnutí těchto dvou tříd problémů stále nenašli svou chybu, může být váš problém ve vaší obchodní logice. To znamená, že prostě neděláte to, co máte na mysli. Triviálním příkladem by bylo, že chcete sečíst dvě čísla, ale odečítáte je. Zde je to, co dělám, když vím, že budu pracovat na složitější obchodní logice:

Začnu tím, že to napíšu izolovaně, to znamená mimo aplikaci, ve které bude žít. Skvělým nástrojem k tomu je Quokka.js. Umožňuje vám točit REPL jako běhové prostředí JS, díky kterému je prototypování okamžité. K hodnotám proměnných můžete přistupovat okamžitě a přímo v IDE.

Pokud jste mladší vývojář, jednou z nejčastějších chyb, které při ladění uděláte, je přesvědčení, že jde o chybu pokročilé obchodní logiky.

Příručka ladicího programu

Ladění je programování. A zlepšíte se jen tím, že to skutečně uděláte. Nejsou zde žádné zkratky. Jak již bylo řečeno, existují některé obecné strategie ladění, které byste měli znát, a zkušenosti vás naučí, kdy je používat.

Než se pustíme do strategií, měli byste vědět alespoň dvě užitečné věci:

1. Protokolování.

2. Připojování k procesu.

Pro tento příspěvek nás zajímá pouze ladění Vue.JS, které žije ve frontendu. V takovém případě se protokolování provádí pomocí objektu konzoly a připojení k procesu se provádí pomocí debugger prohlášení.

Budete používat konzoli console.log fungovat znovu a znovu. Skvělý trik, který jsem se naučil brzy, je, že můžete přihlásit více objektů jedním voláním. Nemusíte „stringovat“ a spojovat všechny své objekty. Můžete provést jeden hovor takto:

console.log("Here's some text and an object:", {'prop': {'nested': 'value'}}, ',and a second one:', [1,2,3,4])

Další věc, kterou potřebujete vědět, je navázat na běhové prostředí. To se provádí jednoduše pomocí debugger tvrzení. Poté můžete číst pokyny po pokynech.

Tyto dvě metody vám umožňují kontrolovat stav vašich objektů za běhu. Je to zásadní, protože budete dělejte chyby, pokud se to pokusíte spočítat kognitivně. Nyní, když jste ve své aplikaci vyzbrojeni obecnými typy chyb a metodami prohlížení, pojďme se podívat na některé obecné strategie, jak přesně určit, kde jsou vaše chyby.

Přírůstkové testování

Strategie závisí na vývoji kontextu chyby. Pokud něco vyvíjíte od začátku, chcete to postupně testovat. Pokud se zobrazí chyba, víte, že se to stalo mezi posledním pokusem a teď.

Technika inspirovaná binárním vyhledáváním

Pokud jste právě našli chybu ve stávajícím projektu a víte, že je relativně nedávná, můžete použít techniku ​​inspirovanou binárním vyhledáváním vrácením potvrzení. Řekněme, že víte, že projekt neměl za sebou chybu 40; můžete vrátit zpět 20 odevzdání a zkontrolovat, zda je chyba přítomna. Pokud ano, víte, že chyba byla přidána mezi 40. a 20. odevzdáním; jinak je to za posledních 20.

Toto opakujete, dokud nezískáte přesné potvrzení, kde byla chyba zavedena. Plusová hodnota toho dělat? Pokud najdete skutečný commit, kde je chyba, mělo by být poměrně snadné opravit, pokud jsou vaše commity dostatečně podrobné. Tento proces se může zdát obtížný, ale v praxi pravděpodobně budete mít intuici o tom, kde se chyba nachází, a možná nebudete muset slepě rozdělovat historii odevzdání na polovinu.

Tato technika může být znovu použita pro logiku. Je to jedna z nejznámějších technik v ladění nazývaná rozděl a panuj. Spustíte svůj kód až do zvoleného bodu přerušení. Zkontrolujete, zda funguje bez chyby. Pokud ano, chyba je v kódu dále než bod přerušení a naopak. Opakujete, dokud nezjistíte, kde je chyba.

Pouze s těmito dvěma obecnými strategiemi můžete jít dlouhou cestu. Pořád si budeš muset ušpinit ruce a rozhlédnout se. Zapamatujte si tři typy chyb a zahrňte několik příkazů protokolování a ladění.

Časem si vytvoříte dobré tušení.

Jedna věc, kterou si musíte vždy pamatovat, je nesabotovat se. Po chvíli ladění stejného problému se tak trochu dostanete do zóny. Ne ten dobrý, zóna proti proudění. Tento stav vás nutí halucinovat blízkost chyby; myslíte si, že chyba musí být tak blízko, protože jste pracovali tak dlouho.

Namísto toho, abyste pracovali podle prvních principů, zkoušíte cestu ven brutálním násilím. Pokud vidíte, že v tomto vzoru kloužete, dejte si pauzu. Promluvte si s někým, může to být gumová kachnička, a poté se k problému vraťte. Ani vám nedokážu říct, kolik času ušetříte.

Výukový program:jak ladit Vue.js?

Aby byly věci trochu konkrétnější, postavíme malý projekt hraček pomocí Vue CLI a nástrojů, o kterých jsme hovořili dříve.

Chcete-li tak učinit, spusťte následující příkazy:

npm install -g @vue/cli
vue create hello-world

Vyberte ruční konfiguraci a vyberte následující možnosti:

Pro ostatní výzvy si můžete ponechat výchozí možnosti. Nyní pokračujte a spusťte svůj projekt pomocí:

cd hello-world
yarn serve

Zásobník, který jsme vytvořili, bude s největší pravděpodobností ten, který se používá pro jakékoli střední/velké projekty Vue. Vuex je tu pro vaši správu stavu a vue-router pro směrování.

Do Vuexu přidáme stav a některé akce, abychom si trochu pohráli s našimi nástroji.

Začněme změnou obchodu Vuex s tímto:

export default new Vuex.Store({
  state: {
    todos: ['The default task']
  },
  mutations: {
    addTodo(state, todo){
      state.todos = state.todos.concat(todo)
    },
    removeTodo(state, idx){
      state.todos.splice(idx, 1);
    }
  },
  actions: {
  },
  modules: {
  }
})

A zaměňme komponentu Home.vue za toto:

<template>
  <div class="home">
    <img alt="Vue logo" src="../assets/logo.png">

    <div>
      <input v-model='newTodo'>
      <button @click='addTodo'>Add todo</button>
    </div>

    <div v-for="(todo, idx) in todos" :key=idx>
      <span>{{todo}}</span>
      <button @click='removeTodo(idx)'>X</button>
    </div>
  </div>
</template>

<script>

export default {
  name: 'Home',
  data(){
    return {
      newTodo: ''
    }
  },
  methods: {
    addTodo() {
      this.$store.commit('addTodo', this.newTodo)
      this.newTodo = ''
    },
    removeTodo(idx){
      this.$store.commit('removeTodo', idx)
    }
  },
  computed: {
    todos(){
      return this.$store.state.todos;
    }
  }
}
</script>

Nyní máte jednoduchou aplikaci pro úkoly, která vám umožňuje přidávat a odebírat úkoly v rozhraní frontend. Pojďme přidat a odebrat několik úkolů a podívat se na naše rozšíření Vue.

Začneme panelem Vuex. Odtud uvidíte všechny akce/mutace, ke kterým v našem obchodě došlo. Máme přístup ke stavu v daném okamžiku byla spáchána daná akce/mutace. Dává vám možnost cestovat v čase a vidět svůj stav v jakémkoli daném bodě. Tímto způsobem nemusíte ručně reprodukovat stejné pořadí událostí, abyste dosáhli chyby. Přesně to můžete udělat v rámci nástrojů, což vám ušetří určitý kognitivní prostor.

Můžete také znovu zavázat akce do obchodu a "rebase" do předchozího stavu. Tímto způsobem můžete zjistit, kde se stát stává závadným, a pustit se do poslední akce, která to způsobila.

Trochu pokročilejší technikou je import/export historie státu. Mohlo by být výhodné, kdybyste na dálku ladili problém někoho jiného, ​​protože by vás mohla požádat podpora. Můžete importovat jejich historii stavu, podívat se na minulé stavy a izolovat ten, kde se to pokazilo.

Pokud otevřete naši malou aplikaci a přidáte nějaké úkoly a pokusíte se jeden odebrat, naše tlačítko pro odebrání nefunguje. Jaká úhledná malá chyba testovat naše nově nabyté znalosti. Pokud otevřeme naši konzoli a zkontrolujeme náš nový panel ladění Vue, uvidíte něco takového:

Můžete vidět, že jsme přidali dva úkoly tím, že jsme do našeho obchodu provedli dvě události „addTodo“. Poté jsme provedli „removeTodo“. Ačkoli, jak můžete vidět přepínáním mezi posledními událostmi „addTodo“ a „removeTodo“, stav zůstal na pozdější události.

Nyní bychom chybu zachytili, protože uživatelské rozhraní by se neaktualizovalo, ale některé chyby jsou mnohem jemnější. Může být docela těžké je sledovat, když například tiše selžou. V takovém případě by integrační testy mohly být tím správným způsobem, jak je zachytit.

Ale co se tady přesně děje?

Chyby nejsou vyvolány v konzoli, takže nemáme přístup k neexistujícím atributům. Příklad je trochu vymyšlený, ale pojďme kopat, jak bychom to udělali jinak. Díky našim nástrojům víme, že „removeTodo“ nefunguje tak, jak jsme zamýšleli. Pojďme přidat nějaké protokolování, abychom viděli skutečné chování naší funkce. Přepněte náš handler "removeTodo" na:

removeTodo(state, idx){
  console.log(state.todos, idx)
  state.todos.slice(idx, 1)
  console.log(state.todos)
}

A výstup:

Nyní vidíme, že oba naše parametry, state, a idx , mají správné hodnoty, ale stát se nikdy nezmutuje. Nyní byste se měli sami sebe zeptat:„Mám mutovat pole nebo vrátit nový stav?“

Malý ponor ve Vuexu a potvrdíte, že byste zde měli mutovat. Teď je jen jedno místo, kam se podívat! Mutuje slice pole!?

Pohled na Array.prototype.slice() potvrdí, že tomu tak není.

"[…] vrací mělkou kopii části pole do nového objektu pole vybraného z start na end (end není zahrnuto), kde start a end představují index položek v tomto poli. Původní pole nebude upraveno."1 Když se podíváte dále, zjistíte, že funkce, kterou jste měli na mysli, byla .splice() . Pojďme to opravit a dát našemu demu další šanci.

Stejného výsledku bychom mohli dosáhnout použitím příkazu debuggeru namísto protokolů. Tento příklad je poměrně jednoduchý, takže v něm není velký rozdíl. I když jsem zjistil, že místo toho používám protokoly pro chyby s časem, nejsem si úplně jistý, kam se mám podívat; i když dávám přednost debuggerům pro chyby, znám jejich přibližnou polohu.

Zde je nyní funkční příklad historie stavu po přidání dvou úkolů po sobě a odstranění jednoho po něm. Můžete vidět užitečné zatížení potvrzené akce a stav po jejím zpracování.

Další důležitou součástí rozšíření jsou komponenty. Umožňuje vám podívat se na strom komponent a odhalit místní stav každé komponenty. Zahrnuje vše, co byste měli ve značce skriptu vaší komponenty jednoho souboru, například data , computed , props , atd. Zjistil jsem, že tuto kartu používám hlavně k ověření, že rekvizity mají správné hodnoty a ručně mutuji místní stavy, abych se ujistil, že okrajové případy a spouštím ad hoc testy.

Úvahy na závěr

Při ladění se vlastně spousta práce udělá předem zdravým sledováním vaší technologické sady, což vám umožní používat dokonalé nástroje.

Pak při aktivním ladění nikdy nezapomínejte na tango mezi špiněním rukou protokoly konzole a používáním mozku k přemýšlení o tom, jaké typy chyb by mohly vysvětlit vaše pozorování.

Jako u všeho, čím více toho budete dělat, tím lepším se stanete.

Hodně štěstí při kódování!

Pokud se vám tento příspěvek líbil, věnujte prosím chvilku sdílejte to na Twitteru . Máte připomínky, dotazy? Klikněte na sekci níže!