Hvordan jeg byggede vejrappen i freeCodeCamp ved hjælp af React og Typescript

Så jeg besluttede endelig at vende tilbage til freeCodeCamp og prøve at afslutte mit Front End Development Certificate. Jeg var allerede færdig med alle algoritmer og tutorials tidligere sidste år, og det eneste der manglede var projekterne.

Men nu hvor jeg har mere erfaring som Full Stack Developer, er de fleste projekter lidt lette for mit nuværende niveau. Så jeg havde to valg. Jeg kunne enten gå tilbage til det grundlæggende og afslutte dem alle på en dag, eller jeg kunne dræbe to fugle i én smag: have det sjovt og eksperimentere med teknologi, mens jeg arbejder på disse projekter. Jeg valgte det sidstnævnte.

Men lad os lave de tre fugle - fordi jeg har ønsket at skrive en tutorial / guide ting i et stykke tid. I dag skal vi tackle projektet Show The Local Weather. Men denne gang vil det kombinere React og Typescript! Du kan se på den færdige kode i denne GitHub repo samt en live demo her.

Baggrund

Så den første ting er først: hvorfor vil jeg gøre det? Nå her er sagen: Jeg har hoppet frem og tilbage med Angular 5 og React i et stykke tid nu. Og jeg kan godt lide Reager mere som en ramme. Det er lille og koncist, men har alle de funktioner, du har brug for for at oprette en fuldt funktionel applikation til en enkelt side. Med hensyn til Angular er det alt for stort til, at jeg kan nyde en så lille app som denne ... men den bruger Typescript!

TypeScript er et supersæt JavaScript, der tilføjer mange funktioner, der bare mangler JavaScript, selv med forbedringerne fra ES6 / 7. Det er mest kendt for sin statiske skrivning. Så jeg spekulerede på, om jeg kunne få det bedste fra begge verdener. Svaret var et rungende JA! ... Redux ikke inkluderet. (Jeg mener, du kan medtage Redux, men hidtil har det været en smerte at oprette, så jeg vil ikke gøre det til denne vejledning.)

Til dette projekt vil vi fokusere på det absolutte minimum af brugerhistorier, fordi mit fokus er teknologien snarere end nogen ekstra funktioner. Som sådan vil den API, vi bruger til denne app, være Wunderround. Det er perfekt til det, vi bygger, fordi de tilbyder temperaturer i både Fahrenheit og Celsius og giver også ikoner til de forskellige vejrforhold. Dette betyder mindre programmatisk arbejde i vores ende.

Trin 0: Opsætning

Jeg bruger create-react-apptil dette projekt med det brugerdefinerede React-script til Typescript, så vi kan holde nul konfiguration og brugervenlighed. En god artikel om oprettelse af en React-app med TypeScript blev skrevet af Trey Huffine og kan findes her.

Jeg foreslår bestemt at se på dette indlæg for mere detaljeret opsætning. Men uden yderligere ado vil vi køre følgende linje i terminalen.

create-react-app weather --scripts-version=react-scripts-tsnpm install --save core-decorators

Jeg kommer til dekoratørerne lidt senere. Bare ved, at det er en pæn lille funktion, som jeg var meget begejstret for at prøve. Men for at kunne bruge den, bliver vi nødt til at redigere vores tsconfig.jsonfil for at inkludere eksperimentelle dekoratører. For at gøre dette skal du blot tilføje den fede linje med kode.

{ "compilerOptions": {// ...code hidden... "noUnusedLocals": true, "experimentalDecorators": true } // ...more code hidden...}

Og da jeg har Prettier installeret på mit udviklingsmiljø, måtte jeg ændre min tslint.jsonfil, fordi fnuget var i konflikt med formateringen. Hvis du har oprettet en lignende udvikling, foreslår jeg bare at slette alle tslint-reglerne, så du ikke behøver at blive kørt fast i konfigurationen. Filen skal se sådan ud, når du er færdig.

Mappestrukturen, som jeg vil bruge, ser ud som følger. Du kan oprette, slette og flytte filer i overensstemmelse hermed.

weather-app/├─ .gitignore├─ node_modules/├─ public/├─ src/ └─ assets/ | - - loader.svg | - - logo.svg └─ components/ | - - Weather.tsx | - - WeatherDisplay.tsx └─ styles/ | - - App.css | - - WeatherDisplay.css | — — index.tsx | — — registerServiceWorker.ts | — — App.tsx | — — index.css | - - config.ts | - - types.ts├─ package.json├─ tsconfig.json├─ tsconfig.test.json└─ tslint.json

Okay, det værste er forbi! Vi har endelig oprettet vores app. Lad os dykke ned i koden.

Trin 1: Styling

Jeg vil først have stylingen af ​​vejen. Jeg er ikke meget af en designer, så alt hvad jeg virkelig gjorde, var at create-react-appgenudskinde standardstilarterne for at have freeCodeCamp-grønt tema. Derudover gjorde jeg knappen mere knaplignende og selvfølgelig mere grøn. Du er fri til at gå vild med dette, hvis du tilfældigvis er en CSS-mester. Du kan også downloade billedfiler her og placere dem i din assets/mappe.

Trin 2: Okay, jeg løj ... Mere opsat

Men rolig, det er faktisk kode denne gang. Lad os først starte med den nemme del: tilføje dine API- og API-nøgler. Intet nyt her - det ser hidtil ud som normal JavaScript.

Nu for den TypeScript-specifikke ting skal vi specificere typer. Det behøver vi ikke, men det burde vi bestemt. Årsagen til statisk typning er, at det giver os sikkerhed. I modsætning til normalt JavaScript kører vores kode ikke, hvis tingene er af den forkerte type. I det væsentlige betyder det, at compileren, der bare er flad, ikke lader os skrive dårlig kode.

Som du kan se, er det ikke for skræmmende. Bare tilføj typen efter et kolon. De primitive typer (streng, nummer, boolsk) understøttes ud af porten. Med objekter er det en god ide at oprette en ny type, der er specifik for det bestemte objekt set i WeatherDatamed DisplayLocation.

Nu var jeg lidt doven, fordi formen på de data, der kommer fra vores API, er meget større, og jeg kunne have oprettet hele objektet. Men jeg valgte bare at tage det, jeg havde brug for, og kassere resten, hvorfor denne types.tsfil er så lille som den er.

Trin 3: Reager - Den sjove del

Jeg har tænkt mig at springe over index.tsx, og App.tsxfiler, fordi der er virkelig ikke noget virkelig nyt der. Bare ved, at importen er forskellig på grund af hvor streng TypeScript handler om moduler. I stedet for skal vi først gennemgå præsentationskomponenten.

Jeg foretrækker stadig at ødelægge Componentog Fragmentreagere i stedet for at ringe React.Component, da det reducerer redundans. Og for fragmenter, hvis du aldrig har spillet med dem før, er det dybest set en div, der ikke vises i HTML-markeringen.

Du vil også bemærke, at jeg har tilføjet grænseflader øverst. En grænseflade specificerer, hvordan vores rekvisitter og tilstand skal se ud. Og hvis du ikke har bemærket det, tilføjer TypeScript's gimmick typer til alt, så det er det, der sker ovenfor inden for vinkelparenteserne te>. If you are familiar with prop types, it does the same thing, but I feel like this is much cleaner.

The next thing is the weird @ symbol. Well, that’s a decorator! I originally wanted to hook up Redux and connect so that I can show a much more complicated version, but the autobind will do for now.

A decorator is basically a function that wraps around the class and applies necessary attributes. It also allows us to use export default at the top, which is just a personal preference of mine.

@decorateexport default Class {}
// is the same as
export default decorate(Class)

In this case autobind will, as the name entails, automatically bind this to everything so we don’t have to worry about binding issues. And coming from a more Object Oriented language, these class methods will look a lot cleaner than the JavaScript work-around with the arrow functions.

classMethod = () => { console.log('when you use arrows, you don't have to worry about the keyword "this"');}
classMethod () { console.log('because of javascript, you have to worry about the keyword "this" here');}

And now finally we move to the bulk of our logic, which is going to be living in the Weather.tsx component.

The first thing you’ll notice is the ? in the interface. I mentioned that we definitely should define types for our props, but what happens when you know for certain it won’t be defined until after the API call? Well we can define optional types with a question mark.

What is happening in the background is that the variable weatherData is only allowed to be a WeatherData type or undefined. Also, remember that our WeatherData type is only a subsection of what wunderground offers. Earlier I mentioned that we are only going to take the data that we needed from the API — well, that’s what that huge destructuring on line 55 is doing.

Did I mention you can specify expected return types of functions? That’s what is happening here with getCurrentPosition , because I wanted to make sure that it returns a promise.

The reasoning here is that I didn’t want to call getCurrentWeather until after we had the correct geolocation, which means we’re dealing with asynchronous events. Async always means Promises, so that’s what’s going to happen.

A word of warning: the native geolocation API does take a long time to get a result without passing in any options. I opted to not add options to it as it was giving me errors at the time.

And I believe that is all the new things happening in this app because of TypeScript. Everything else should be familiar if you know React. But hopefully you can see the benefits of this superset, as it adds both security to our code as well as some nice super powers.

Step 4: Complete!

You did it! You finished an app that shows the weather at your current position. And in doing so, you’ve covered a good chunk of TypeScript as well as incorporating it into React.

Of course, there can definitely be improvements on this, like an option to search and show other locations. And the UI can definitely be worked on. But if you haven’t already finished the weather app on freeCodeCamp, you have already gone above and beyond on this assignment.