Den beste måten å lære seg å kode er å kode: Lær app-arkitektur ved å bygge apper

Practice Makes Perfect av Benjamin Stäudinger (CC BY-NC-ND 2.0)

Det kan være tøft å lære å kode. En av de største utfordringene jeg møtte da jeg lærte, var hvordan jeg hoppet fra læringsressursene og lite praksisutfordringer som lærer deg koding av grunnleggende til fullverdige apper.

Det er ingen annen vei rundt det. Den beste måten å lære er å hoppe inn og begynne å bygge, men det kan være veldig skremmende. Hvor begynner du?

Brukere og autentisering?

Du kan tro at brukerstyring og autentisering er et godt første skritt å lære. Du tar feil. Først av alt, passord er foreldet, så alle de nye appene dine bør bruke passordløs godkjenning.

For det andre er brukerautentisering en enorm sikkerhetsrisiko, og skal ikke under noen omstendigheter overlates til nybegynnere. Hundrevis av millioner innloggingsopplysninger er blitt stjålet fra store selskaper med dedikerte sikkerhetseksperter som ikke gjør annet enn å jobbe døgnet rundt for å forbedre sikkerheten. Sjansen er veldig god for at noen av påloggingsinformasjonene dine er stjålet.

Det er ikke bare farlig for appen din hvis du skruer opp brukergodkjenning, den er farlig for brukerne dine, fordi de kan bruke de samme påloggingsinformasjon for andre apper, for eksempel e-postleverandøren eller bankkontoen deres. Med andre ord, hvis noen stjeler passord fra appen din, kan de kanskje bruke dem til å gjøre reell skade i områder som ikke har noe med appen din å gjøre.

Husk at brukerautentisering er en enorm sikkerhetsrisiko, og bør ikke overlates til nybegynnere under noen omstendigheter.

Jeg anbefaler at de fleste apper delegerer godkjenningsoppgaver til eksterne godkjenningsleverandører som Facebook, Twitter eller lignende. Selv store apper støttet av store bedrifter som har legitime grunner og ressursene for å administrere sine egne brukerautentiseringsstrategier, bør bruke populære, kamptestede biblioteker i stedet for å rulle sin egen autentisering fra bunnen av.

Men det er mange bittesmå apper for én bruker som du kan bygge som ikke trenger brukerautentisering i det hele tatt, og noen apper som kan dra nytte av brukerautentisering, kan legge til den funksjonen senere.

En god måte å starte overgangen til virkelige apper på er å bygge nettleserbaserte apper ved hjelp av `localStorage`, kun støtte for en enkelt bruker, og deretter skalere opp fra det grunnlaget. Du kan legge til flere brukere og databasetilkobling senere, etter at du har mestret det grunnleggende i moderne app-arkitektur på klientsiden.

Introduksjon til Client Side App Architecture

Så hvordan ser moderne applikasjonsarkitektur på klientsiden ut? For bare noen få år siden ble det dominert av MV * -arkitekturer som MVC, MVP, MVVM, osv ...

De fleste av dem tar for seg hvordan man skal koordinere mellom modeller (data) og utsikten (UI / Presentasjon). Et viktig konsept i applikasjonsarkitektur er separasjon av bekymringer.

Her er noen av bekymringene vi liker å holde atskilt:

  • Presentasjon / visning (layout, stil, DOM-manipulasjon)
  • Hendelseshåndtering / handlinger (fange opp og transformere innspill fra brukere og eksterne meldinger til handlinger i appen)
  • Ruting / nettadresser (oversettelse av nettadresser til handlinger)
  • Forretningslogikk (regler for hvordan data manipuleres)
  • Klientstatestyring / modell / butikk (datastrukturer på klientsiden)
  • Datapersistens og server I / O (langsiktig datalagring, AJAX, SSE)

MVC-arkitektur ser noe slik ut:

MVC-diagram fra

I MVC avgir modellen endringshendelser, og visningen svarer ved å spørre gjeldende status og oppdatere. Kontrolleren lytter til å se hendelser og svarer ved å oppdatere tilstanden, og potensielt manipulere visningen også, eller velge en ny visning som svar på rutingendringer.

Med 2-veis databindring gjenspeiles endringer i visningen direkte i modellen uten å gå gjennom kontrolleren. Se for deg at i stedet for bare å spørre om staten, kan visningen også oppdatere staten direkte. Det er 2-veis bindende i et nøtteskall.

En brukerinngang kan utløse en tilstandsoppdatering, som kan utløse en DOM-endring, som kan utløse en annen tilstandsoppdatering, som kan utløse flere DOM-endringer, og så videre. Det blir raskt vanskelig å forstå hvordan endringer kan kaskade og påvirke tilstanden til appen din, og det blir lett å tilfeldigvis introdusere uendelige løkker.

Et eksempel på dette er Angular 1. Angular 1 forsøkte å håndtere denne kompleksiteten ved å ta kontroll over UI-statusoppdateringssløyfen (kalt fordøyelsessløyfen). For å unngå uendelig rekursjon av meldinger, hadde fordøyelsessløyfen en fast kablet grense på 10 sykluser, men som fortsatt la mye plass til en enkelt hendelse til å sende en kaskade som ville føre til mange endringer i DOM, noe som kan utløse mer sykluser. I tillegg til å være sammensatt og vanskelig å forstå, var det også en vanlig årsak til ytelsesproblemer i Angular, fordi en enkelt endring kan utløse en stor kaskade med oppdateringer.

I 2013 kunngjorde Facebook React: et nytt open-source rammeverk for å bygge brukergrensesnittkomponenter. React bryr seg ikke hvordan du håndterer dataoppdateringer, men den støtter ikke 2-veis datainnbinding. I stedet oppfordres du til å bruke ensrettet dataflyt, ved å koble sammen React til noe som Flux-arkitekturen.

React & Flux har endret radikalt hvordan vi bygger apper for nettplattformer, og ideen om ensrettet dataflyt har også spredd seg til appene Angular og Ember.

Flux-arkitekturen ser slik ut:

Flux Arkitektur

I stedet for å formidle endringer gjennom et stort antall hendelseslyttere, blir tilbakeringingsfunksjoner ført inn i visningen, som blir koblet til DOM-hendelseslytterens tilbakeringinger. Tilbakekalling produserer et handlingsobjekt som blir sendt til butikken der statusendringene blir administrert.

Når du legger til server I / O til miksen, kan det se slik ut:

Flux med server I / O

I tillegg til å se tilbakeringinger, vil mange apper også ha hendelseslyttere koblet opp for å kommunisere med serveren. Brukergrensesnitt-handlinger kan også sende serverens spørsmål og videresende oppdateringer til serveren. Så kan en tilbakeringing fra visningen utløse en serverforespørsel eller oppdatering, og en lytter for sendte hendelser kan utløse ytterligere handlinger, som kan sendes til butikken, og så videre.

Du har kanskje hørt om Redux, som for tiden er det mest populære Flux-alternativet. Det legger til konseptet med rene funksjoner for manipulering av butikker, kalt reduksjonsmaskiner. Reduksjonene forenkler hvordan man kan resonnere om butikken ved å sikre at hver type tilstandsoppdatering kan styres og testes uavhengig, og at reduksjonsmaskiner ikke har noen bivirkninger, noe som betyr at det er enkelt å forstå effekten av en bestemt handling. For en flott oversikt over Redux-arkitektur, sjekk ut dette lysbildet.

For de første appene dine trenger du sannsynligvis ikke å takle all denne arkitekturen. Vi kom til disse arkitekturoppdateringene ved å bygge store applikasjoner, der ubegrenset delt tilgang til applikasjonsstatus kan bli forvirrende og rotete. Disse abstraksjonene gir oss en klar krets for alle tilstandsendringer i applikasjonen, men de er sannsynligvis overkill for trivielle applikasjoner.

Til å begynne med kan du koble sammen arrangementlyttere og direkte manipulere søknadsstatusen din som svar, og det er OK. Lær å gå før du løper. Når du er klar til å gå videre til mer kompliserte apper, kan du ta en titt på Dan Abramovs utmerkede kurs, "Komme i gang med Redux" og "Building React Applications with Idiomatic Redux".

Øv apper

Hver utvikler trenger en kodeportefølje. Øvelsesapper er en flott måte å bygge en på.

Når du utforsker de ovennevnte kursene, vil du bli utsatt for den veldig ofte brukte oppgavelisten-eksempelappen. Jeg anbefaler at du følger med tutorials og setter en sammen.

Men hvilke andre interessante apper kan du bygge? Noe av det vanskeligste med å lære seg å kode er å komme med gode ideer for apper å bygge.

Det er nettsteder som samler og rangerer appideer etter stemmer. Definitivt se på de hvis du leter etter ideer.

Studenter av "Lær JavaScript med Eric Elliott" vil finne en ny liste over studentprosjekter, kuratert med korte funksjonslister. Både appene og funksjonene har vanskelighetsgrader, “grunnleggende”, “mellomliggende” og “avanserte” for å hjelpe elevene å matche utfordringer til deres nåværende læringsnivå.

Eksempel Prosjekt: Avvisning

Et studentprosjekt for Lær JavaScript med Eric Elliott.

Vil du jobbe som et team? Finn en kodende kompis i studentpraten.

Du må tape for å vinne.

Tren deg til:

  • Få lønnspålegg
  • Selg mer
  • Utvikle mer virksomhet
  • Forhandle bedre tilbud

Spillet har en regel:

Du må avvises av et menneske minst en gang per dag.

Be om ting utenfor komfortsonen din, så finner du ut at du vinner mye mer.

Vinn = 1 poeng. Avvisning = 10 poeng.

Hvor lenge kan du få avvisningsstreken til å vare?

Grunnleggende nivå

Bygg et brukergrensesnitt som lar deg følge med på poengsummen din. Ta med en tekstinntasting for spørsmålet, hvem du spurte, og to knapper: "Godkjent" eller "Avvist". For asynkrone forespørsler som e-post eller meldinger, må du registrere poengsummen på det tidspunktet du får svaret, ikke på det tidspunktet du ber.

Bruk HTML + CSS og lagre en registrering av dataene i lokal lagring.

Hold fortløpende oversikt over brukerens nåværende poengsum. Husk at dagens subtotal må omberegnes hver gang et spørsmål blir akseptert eller avvist, så det vil være nyttig å holde listen i en matrise som du kan redusere med hvert nytt svar.

Midtnivå

  • Legg til et API for å lagre data ved hjelp av en webtjeneste og database.
  • Legg til autentisering og spore flere brukere. Hint: Redis, Mongo eller RethinkDB ville være gode databasekandidater.
  • Sosial pålogging som Facebook eller Twitter ville være gode autentiseringsalternativer (enklere og sikrere enn brukernavn / passordpålogginger).

Avansert nivå

  • Del poengsummen din og konkurrer med vennene dine på Facebook.
  • For hver bruker, hold en toppliste fra vennekretsen sin.

Ekstra kreditt

  • Legg til mobilapper

Å implementere:

  1. Fork repoen
  2. Implementer løsningen din.
  3. Åpne et problem med en lenke til gaffelen.

For å få kreditt, må du åpne et problem med en lenke til gaffelen.

Se prosjektet på GitHub.

Lær JavaScript med Eric Elliott

Eric Elliott er forfatteren av “Programmering JavaScript Applications” (O’Reilly), og “Lær JavaScript med Eric Elliott”. Han har bidratt til programvareopplevelser for Adobe Systems, Zumba Fitness, The Wall Street Journal, ESPN, BBC og toppopptakere, inkludert Usher, Frank Ocean, Metallica og mange flere.

Han tilbringer mesteparten av tiden sin i San Francisco Bay Area med den vakreste kvinnen i verden.