De beste manier om te leren coderen is om te coderen: leer app-architectuur door apps te bouwen

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

Leren coderen kan moeilijk zijn. Een van de grootste uitdagingen waarmee ik te maken kreeg toen ik aan het leren was, was hoe ik de sprong kon maken van leermiddelen en kleine oefenuitdagingen waarmee je de basisprincipes van codering leert kennen naar volledig ontwikkelde apps.

Er is geen andere manier omheen. De beste manier om te leren is erin te springen en te beginnen met bouwen, maar dat kan heel ontmoedigend zijn. Waar begin je

Gebruikers & authenticatie?

Je denkt misschien dat gebruikersbeheer en authenticatie een goede eerste stap is om te leren. Je zou het verkeerd hebben. Allereerst zijn wachtwoorden verouderd, dus al uw nieuwe apps moeten wachtwoordloze authenticatie gebruiken.

Ten tweede is gebruikersauthenticatie een enorm beveiligingsrisico en mag het in geen geval aan nieuwelingen worden overgelaten. Honderden miljoenen inloggegevens zijn gestolen van grote bedrijven met toegewijde beveiligingsexperts die 24 uur per dag werken aan het verbeteren van de beveiliging. De kans is zeer groot dat sommige van uw inloggegevens zijn gestolen.

Het is niet alleen gevaarlijk voor uw app als u de gebruikersauthenticatie verknalt, het is ook gevaarlijk voor uw gebruikers, omdat ze mogelijk dezelfde inloggegevens gebruiken voor andere apps, zoals hun e-mailprovider of hun bankrekening. Met andere woorden, als iemand wachtwoorden van uw app steelt, kan hij deze mogelijk gebruiken om echte schade aan te richten in gebieden die niets met uw app te maken hebben.

Vergeet niet dat gebruikersauthenticatie een enorm beveiligingsrisico is en onder geen enkele omstandigheid aan nieuwelingen mag worden overgelaten.

Ik raad aan dat de meeste apps authenticatietaken delegeren aan externe authenticatieproviders zoals Facebook, Twitter of iets dergelijks. Zelfs grote apps die worden ondersteund door grote bedrijven die legitieme redenen hebben en de middelen om hun eigen strategieën voor gebruikersauthenticatie te beheren, zouden populaire, in de strijd geteste bibliotheken moeten gebruiken in plaats van hun eigen authenticatie helemaal opnieuw te maken.

Maar er zijn veel kleine apps voor één gebruiker die je zou kunnen bouwen die helemaal geen gebruikersauthenticatie nodig hebben, en sommige apps die kunnen profiteren van gebruikersauthenticatie kunnen die functie later toevoegen.

Een goede manier om uw transitie naar echte apps te starten, is door browsergebaseerde apps te bouwen met behulp van `localStorage`, die slechts één gebruiker ondersteunt, en vervolgens opschalen vanaf die basis. U kunt later meerdere gebruikers en database-connectiviteit toevoegen, nadat u de basis van moderne app-architectuur aan de client-kant onder de knie hebt.

Inleiding tot client-side app-architectuur

Dus hoe ziet de moderne applicatie-architectuur van de client-side eruit? Slechts een paar jaar geleden werd het gedomineerd door MV * -architecturen zoals MVC, MVP, MVVM, enz ...

De meeste behandelen hoe te coördineren tussen modellen (gegevens) en de weergave (UI / presentatie). Een belangrijk concept in applicatiearchitectuur is scheiding van problemen.

Hier zijn enkele zorgen die we graag gescheiden houden:

  • Presentatie / weergave (lay-out, stijl, DOM-manipulatie)
  • Gebeurtenisafhandeling / acties (vastleggen en transformeren van input van gebruikers en externe berichten in acties in de app)
  • Routing / URL's (URL's vertalen naar acties)
  • Bedrijfslogica (regels voor hoe gegevens worden gemanipuleerd)
  • Clientstatusbeheer / model / winkel (in-memory client-side gegevensstructuren)
  • Gegevenspersistentie & server I / O (langdurige gegevensopslag, AJAX, SSE)

MVC-architectuur ziet er ongeveer zo uit:

MVC-diagram van

In MVC verzendt het model wijzigingsgebeurtenissen en reageert de weergave door de huidige status op te vragen en bij te werken. De controller luistert naar gebeurtenissen en reageert door de status bij te werken en de weergave mogelijk ook te manipuleren of een nieuwe weergave te selecteren in reactie op routewijzigingen.

Met tweerichtingsgegevensbinding worden wijzigingen in de weergave direct in het model doorgevoerd zonder door de controller te gaan. Stel u voor dat de weergave in plaats van alleen de status te doorzoeken, de status ook rechtstreeks kan bijwerken. Dat is tweerichtingsbinding in een notendop.

Een gebruikersinvoer kan een statusupdate activeren, wat een DOM-wijziging kan activeren, waardoor een andere statusupdate kan worden geactiveerd, waardoor mogelijk meer DOM-wijzigingen worden geactiveerd, enzovoort. Het wordt snel moeilijk om te begrijpen hoe veranderingen in cascade kunnen optreden en de status van uw app kunnen beïnvloeden, en het wordt gemakkelijk om per ongeluk oneindige lussen te introduceren.

Een voorbeeld hiervan is Angular 1. Angular 1 probeerde deze complexiteit te beheren door de controle over de updatelus van de UI-status over te nemen (de digest-lus genoemd). Om oneindige berichtenrecursie te voorkomen, had de digest-lus een hard-wired limiet van 10 cycli, maar dat liet nog steeds veel ruimte over voor een enkele gebeurtenis om een ​​cascade uit te zenden die veel DOM-veranderingen zou veroorzaken, wat meer zou kunnen activeren cycli. Naast dat het complex en moeilijk te begrijpen was, was het ook een veel voorkomende oorzaak van prestatieproblemen in Angular, omdat een enkele wijziging een grote cascade van updates kan veroorzaken.

In 2013 kondigde Facebook React aan: een nieuw open-source framework voor het bouwen van componenten van gebruikersinterfaces. React maakt het niet uit hoe u met gegevensupdates omgaat, maar biedt geen ondersteuning voor tweerichtingsgegevensbinding. In plaats daarvan wordt u aangemoedigd om unidirectionele gegevensstroom te gebruiken, waarbij React wordt gekoppeld aan iets als de Flux-architectuur.

React & Flux hebben de manier waarop we webplatform-apps bouwen radicaal veranderd en het idee van een unidirectionele gegevensstroom is ook verspreid naar de Angular- en Ember-apps.

De Flux-architectuur ziet er ongeveer zo uit:

Flux-architectuur

In plaats van veranderingen door te voeren via een groot aantal gebeurtenislisteners, worden callback-functies doorgegeven aan de weergave, die gekoppeld worden aan de callbacks van de DOM-gebeurtenislistener. De callback produceert een actieobject dat wordt verzonden naar de winkel waar de statuswijzigingen worden beheerd.

Wanneer u server-I / O aan de mix toevoegt, kan het er als volgt uitzien:

Flux met server-I / O

Naast callbacks hebben veel apps ook event-listeners die zijn aangesloten om met de server te communiceren. UI-acties kunnen ook serverquery's verzenden en updates doorsturen naar de server. Een actie-callback vanuit de weergave kan dus een serverquery of update activeren, en een luisteraar voor door de server verzonden gebeurtenissen kan verdere acties activeren, die naar de winkel kunnen worden verzonden, enzovoort.

Je hebt misschien gehoord van Redux, dat momenteel het populairste Flux-alternatief is. Het voegt het concept van pure functies voor winkelmanipulatie toe, reducers genoemd. De reductiemiddelen vereenvoudigen het redeneren over de winkel door ervoor te zorgen dat elk soort statusupdate onafhankelijk kan worden beheerd en getest, en dat reductiemiddelen geen bijwerkingen hebben, wat betekent dat het eenvoudig is om de impact van een bepaalde actie te begrijpen. Bekijk dit dia-deck voor een goed overzicht van de Redux-architectuur.

Voor uw eerste apps hoeft u waarschijnlijk niet met al deze architectuur om te gaan. We zijn tot deze architectuurupdates gekomen door grote applicaties te bouwen, waar onbeperkte gedeelde toegang tot de applicatiestatus verwarrend en rommelig kan worden. Deze abstracties geven ons een duidelijk circuit voor alle statusveranderingen in de applicatie, maar ze zijn waarschijnlijk overdreven voor triviale applicaties.

In eerste instantie kunt u event-luisteraars aansluiten en direct uw applicatiestatus manipuleren als reactie, en dat is OK. Leer lopen voordat je rent. Wanneer je klaar bent om door te gaan naar meer gecompliceerde apps, bekijk dan de uitstekende cursussen van Dan Abramov, "Aan de slag met Redux" en "React-applicaties bouwen met Idiomatic Redux".

Oefen apps

Elke ontwikkelaar heeft een codeportfolio nodig. Oefen-apps zijn een geweldige manier om er een te bouwen.

Terwijl u de bovengenoemde cursussen verkent, wordt u blootgesteld aan de veel gebruikte Takenlijst-voorbeeldapp. Ik raad je aan om de tutorials te volgen en er zelf een samen te stellen.

Maar welke andere interessante apps zou je kunnen bouwen? Een van de moeilijkste dingen om te leren coderen is het bedenken van goede ideeën voor apps om te bouwen.

Er zijn sites die app-ideeën verzamelen en rangschikken op basis van stemmen. Bekijk deze zeker als je op zoek bent naar ideeën.

Studenten van 'Leer JavaScript met Eric Elliott' vinden een nieuwe lijst met studentenprojecten, samengesteld met korte functielijsten. Zowel de apps als de functies hebben moeilijkheidsgraden, "basis", "gemiddeld" en "geavanceerd" om studenten te helpen uitdagingen aan te passen aan hun huidige leerniveau.

Voorbeeldproject: afwijzing

Een studentenproject voor Learn JavaScript met Eric Elliott.

Wil je als een team werken? Zoek een coderende buddy in de studentenchat.

Je moet verliezen om te winnen.

Train jezelf om:

  • Opslag krijgen
  • Verkoop meer
  • Meer zaken ontwikkelen
  • Onderhandel betere deals

Het spel heeft één regel:

Je moet minstens eenmaal per dag door een mens worden afgewezen.

Vraag om dingen buiten je comfortzone, en je zult merken dat je veel meer wint.

Win = 1 punt. Afwijzing = 10 punten.

Hoe lang kun je je afwijzing laten duren?

Basis niveau

Bouw een gebruikersinterface waarmee u uw score kunt bijhouden. Neem een ​​tekstinvoer op voor de vraag, wie je hebt gevraagd, en twee knoppen: "Geaccepteerd" of "Afgewezen". Voor asynchrone verzoeken zoals e-mails of berichten, noteer de score op het moment dat u het antwoord krijgt, niet op het moment dat u erom vraagt.

Gebruik HTML + CSS en sla een record van de gegevens op in lokale opslag.

Houd de huidige score van de gebruiker bij. Vergeet niet dat het subtotaal van de dag opnieuw moet worden berekend telkens wanneer een vraag wordt geaccepteerd of afgewezen, dus het is handig om de lijst in een array te houden die u bij elk nieuw antwoord kunt verkleinen.

Middelmatig

  • Voeg een API toe om gegevens op te slaan met behulp van een webservice en database.
  • Voeg authenticatie toe en volg meerdere gebruikers. Hint: Redis, Mongo of RethinkDB zouden goede database-kandidaten zijn.
  • Sociale inloggegevens zoals Facebook of Twitter zouden goede authenticatie-opties zijn (eenvoudiger en veiliger dan log-in met gebruikersnaam / wachtwoord).

Gevorderd niveau

  • Deel je score en speel met je vrienden op Facebook.
  • Houd voor elke gebruiker een scorebord uit zijn vriendenkring.

Extra krediet

  • Voeg mobiele apps toe

Implementeren:

  1. Vork de repo
  2. Implementeer uw oplossing.
  3. Open een probleem met een link naar je vork.

Om krediet te krijgen, moet je een probleem openen met een link naar je vork.

Bekijk het project op GitHub.

Leer JavaScript met Eric Elliott

Eric Elliott is de auteur van 'Programming JavaScript Applications' (O'Reilly) en 'Learn JavaScript with Eric Elliott'. Hij heeft bijgedragen aan software-ervaringen voor Adobe Systems, Zumba Fitness, The Wall Street Journal, ESPN, BBC en topartiesten zoals Usher, Frank Ocean, Metallica en nog veel meer.

Het grootste deel van zijn tijd brengt hij door in de San Francisco Bay Area met de mooiste vrouw ter wereld.