čtvrtek 13. července 2017

Next.js, SSR a Typescript

Existuje jeden hlavní důvod, proč většina lidí s javascriptem skončí dříve, než vůbec začne. Tím důvodem je: "Kde mám sakra začít?".

Gulp, Grunt, Webpack, NPM, Yarn, ES5, ES6, ES2015, Babel, Typescript, Flow, React, Angular, Node.js, Next.js, Redux, Express, Koa, Hapi, .... uff. Nemá cenu si nic nalhávat, svět kolem javascriptu je rozsáhlý a plný slepých uliček. Viz Angular.

V dnešním článku bych se chtěl podívat na knihovnu Next.js, která je úzce spjata s Reactem. A je právě určena k tomu, aby vás odstínila od velkého množství konfigurace, kterou byste sami museli jinak udělat.

Co je Next.js?

Jednou větou: "Next.js je knihovna pro React, která za vás řeší server side rendering a konfiguraci." Server side rendering nebo-li SSR je věc, kterou byste měli sami chtít. Pojďme si nejdříve popsat několik důvodů, proč bychom SSR měli použít.

SEO

Pokud používáte javascriptové knihovny jako je React či Angular a stavíte veřejný web, tak narazíte na to, že Vám ho vyhledávače nebudou chtít správně indexovat. Je velká pravděpodobnost, že zůstanete pro zbytek světa neviditelní. A to přeci nechcete. Zde přichází na řadu SSR, které spočívá v tom, že Vám dopředu vygeneruje "kostru" webové stránky a až poté řeší samotný javascript.
Díky tomu vyhledávač vidí html stránku, ze které si je schopen přečíst informace, které potřebuje pro indexaci.

Velikost stažené aplikace

Ač žijeme v době, která jednou bude popisována jako "začátek digitálního věku", tak je třeba mít na paměti, že i když máme výkonné počítače, tak nás to nespasí v tom, abychom přestali ladit dostupnost a výkon.
Příkladem budiž mobilní zařízení, které předběhly počítače v prohlížení webových stránek. To je skvělá zpráva, nicméně... Nastává totiž problém s rychlostí připojení, které ještě nemáme na takové úrovni jako v případě přímého připojení v domácnostech. Mobilní operátoři nabízí jen velice omezené zdroje a to jak na úrovni rychlosti, tak i v množství stažených dat.
Zde nastupuje druhý argument, proč byste měli SSR chtít. Tím argumentem je fakt, že pokud je Vaše webová aplikace rozsáhlejší, tak klientovi můžete aplikaci posílat po částech. Tedy těch částech, které zrovna vaše aplikace sama potřebuje.

Bílá stránka při prvním načtení

Tento důvod úzce souvisí s předchozím bodem. Jedná se o to, že pokud aplikaci otevíráte poprvé a nepoužíváte SSR, tak vlastně vidíte pouze bílou stránku a to do té doby, než se stáhnou všechny potřebné soubory, což je běžně celá aplikace. V případě pomalejšího připojení je toto velký problém.
Uživatel nechce čekat. Často si bude myslet, že je někde chyba a bude stále dokola zkoušet tlačítko "refresh". A to do té doby, než z vaší stránky odejde úplně.

Proč tedy Next.js a ne vlastní řešení?

Každý, kdo se s Reactem kdy setkal, tak ví, že vytvořit aplikaci, která by se renderovala ze serveru je vcelku jednoduchá záležitost. Problém ovšem nastává ve chvíli, kdy budete tímto směrem nastavovat i další věci. Myslím tím například CSS, Redux či třeba routování. Všechny tyto věci má Next.js již vyřešen a vy pouze využíváte hotové řešení.
Další výhodu, kterou získáte je funkční nastavení webacku či jednoduché spouštěcí skripty. Next.js za vás vše připraví a díky tomu máte stack, který podporuje jak práci v development řežimu, tak i produkční běh.
Next.js toho umí samozřejmě mnohem mnohem více, každopádně k tomuto účelu doporučuji si projít popis na github.com.

Pojďme se nyní podívat na to, jak je na tom Next.js s podporou Typescriptu...

Next.js a Typescript

Pokud chcete v Next.js 2.0 použít Typescript, tak zde narazíte na jeden zásadní problém. Tím problémem je, že podle jejich ukázky na githubu vychází z toho, že zkompilovaný javascript máte ve stejném adresáři jako zdrojové soubory. Faktem je, že tenhle způsob mi nepřijde zrovna vhodný.
V nové připravované verzi máte možnost spustit next.js s parametrem, kde se daný zdroj nachází. K tomuto stačí jednoduchá úprava.

Pojďmě se nejdříve podívat na definici skriptů v package.json:

"scripts": {
    "prebuild": "tsc && cp -R static dist/",
    "build": "next build dist",
    "predev": "tsc && cp -R static dist/",
    "dev": "concurrently \"tsc --watch\" \"next dist\"",
    "start": "next start dist"
  },

Zde můžete vidět, že před spuštěním next.js jen provedet kompilaci pomocí tsc, který podle tsconfig.json kompiluje do adresáře dist.

Konfigurace tsconfig.json vypádá následovně:

{
  "compilerOptions": {
    "module": "commonjs",
    "target": "es6",
    "jsx": "react",
    "strict": true,
    "moduleResolution": "node",
    "rootDir": "src",
    "outDir": "dist",
    "baseUrl": ".",
    "paths": {
      "*": [
        "node_modules/*",
        "types/*"
      ]
    }
  },
  "include": [
    "src/**/*"
  ]
}

Podle tohoto nastavení jsou zdrojové soubory v adresáři src a výsledek kompilace ve zmíněném adresáři dist.

Závěr

Osobně vnímám Next.js jako posun k dospělosti. Pokud vývojářům něco chybělo, tak je to dev stack, který by za ně řešil spoustu nudné konfigurace, ale přesto by zůstal dostatečně flexibilní. Tím Next.js přesně je. Chcete doplnit pluginy do webpacku? Žádný problém. Chcete změnit Express na straně Node.js serveru? Také můžete a nebude vás to stát ani příliš úsilí.
Pomocné knihovny, jako třeba Create React App splnily svou historickou povinnost, kdy se čekalo na to, až přijde skupina lidí, kteří tuto věc udělají robusněji.
Nakonec bych si dovolil jedno přirovnání ze světa Javy. To co je Spring Boot pro Spring, to je Next.js pro React. Dělejme opravdu jen to, co musíme.

5 komentářů:

  1. Ahoj, díky za zajímavý článek, díky kterému Next prozkoumám. Chtěl jsem se však zeptat, zda-li znáš český stack "este" a zda-li by jsi mohl tyto dva stacky porovnat.

    OdpovědětVymazat
    Odpovědi
    1. Ahoj,
      ESTE samozřejmě znám. Nicméně, mám pocit, že sám autor Daniel Steigerwald říkal, že s ESTE končí, protože právě Next.js řeší přesně to, co se snažil vytvořit.
      Když se podíváš na jeho poslední branch, která nese název "next", tak tam i můžeš vidět, že se sám na Next.js adaptoval. Co nabídne navíc, to nevím.

      Vymazat
  2. "V případě pomalejšího připojení je toto velký problém."

    V pripade pomalejsiho pripojeni pri SSR uvidim bilou stranku, ktera se bude velmi pomalu postupne renderovat. V pripade SPA se mi relativne rychle nacte prazdna kostra a roztoci se mi spinner. Ja to tak jednoznacne pro SSR nevidim.

    OdpovědětVymazat
    Odpovědi
    1. V případě SSR uvidíš HTML stránku včetně dat (není moc velká a vyrenderuje se rychle) a než se rozkoukáš, načte se JavaScript a chytne se na tu HTML kostru.

      Mnohé vyhledávače neumí spustit ani JavaScript, takže v případě SSR zaindexují HTML včetně dat, zatímco v SPA ti to nezaindexuje ani ten spinner. Rozdíl je jasný jak pro člověka, tak pro indexační engine.

      Vymazat
  3. Máte tip kde web napsaný v Next.js rozjet? Jestli tomu dobře rozumím tak díky server renderingu musíte mít na stroji nodejs a tam spustit webserver ne? Máte tip na nějaké lehké řešení či hosting v ČR jak takovou nextjs app (web) rozjet? Díky

    OdpovědětVymazat

Když programátor založí a řídí firmu

Jako malý jsem chtěl být popelářem. Ani ne tak proto, že bych měl nějaký zvláštní vztah k odpadkům, ale hrozně se mi líbilo, jak...