Vizualizace dat uložených v Cloudu na webu

Vizualizace dat uložených v Cloudu na webu

Bakalářská práce

Studijní program: B2646 – Informační technologie Studijní obor: 1802R007 – Informační technologie

Autor práce: Tomáš Klikorka Vedoucí práce: Ing. Martin Kysela

Liberec 2018

Anotace

Práce se zabývá vizualizací dat regulátoru tepelného čerpadla, prostřednic- tvím webové aplikace. Úvodní část práce se zabývá problematikou vizuali- zace dat a rešerší v oblasti vývoje webových aplikací. V této části jsou analyzovány a porovnávány způsoby, které mohly být použity pro dosažení cílů této práce. Zároveň je zde obsaženo stručné seznámení s použitými technologiemi. Důraz je kladen zejména na technologie, které se dají pova- žovat za klíčové při vývoji front endu aplikace. V následující částí je popsá- no samotné řešení při tvorbě webové aplikace, popis jednotlivých

komponent a úkoly s prací spojené, jako například testování spolehlivosti serveru nebo zabezpečení aplikace.

Klíčová slova

Vizualizace dat * Tepelné čerpadlo * Webová aplikace *JavaScript * React

9

Obsah

Seznam zkratek a termínů ... 12

Úvod ... 13

1 Rešerše ... 14

1.1 Vizualizace dat ... 14

1.2 Dostupné technologie ... 16

1.3 Databáze ... 17

1.3.1 Relační databáze ... 17

1.3.2 Nerelační databáze ... 19

1.3.3 MongoDB ... 21

1.4 HTML... 22

1.5 Kaskádové styly ... 23

1.5.1 Inline styly ... 24

1.5.2 Vložené styly ... 24

1.5.3 Externí styly ... 24

1.6 CSS Pre-processory ... 25

1.6.1 Proměnné ... 25

1.6.2 Vnořování ... 26

1.6.3 Mixins ... 26

1.6.4 Extends ... 26

1.7 JavaScript ... 26

1.7.1 JSX ... 27

1.8 AJAX ... 29

1.8.1 XMLHttpRequest ... 29

1.9 React.js ... 29

1.9.1 Virtual DOM ... 30

1.9.2 Vykreslování Elementu do DOMu ... 31

1.9.3 Komponenty a Props ... 32

1.9.4 Vykreslování komponent ... 33

1.9.5 State a Lifecycle ... 34

1.9.6 Lifecycle metody ... 34

10

1.10 Webpack ... 36

1.11 Angular ... 36

2 Návrh řešení ... 38

2.1 Příprava ... 38

2.2 Front End ... 39

2.3 Vývojové prostředí ... 39

2.4 CRUD operace ... 39

2.4.1 Promises ... 40

2.4.2 Fetch API ... 40

2.4.3 Axios ... 41

2.5 Uživatelská registrace a přihlašování ... 41

2.6 Interaktivní mapa ... 42

2.6.1 Google map ... 42

2.6.2 Mapbox ... 42

3 Řešení ... 44

3.1 Vývoj aplikace ... 44

3.1.1 Směrování (Routing) ... 44

3.1.2 Registrace ... 44

3.1.3 Přihlášení uživatele ... 45

3.1.4 Zobrazení dat regulátoru teplného čerpadla ... 47

3.1.5 Mapa ... 47

3.1.6 Graf ... 49

3.2 Testování spolehlivosti ... 51

3.3 Bezpečnost aplikace ... 51

3.3.1 SQL (NoSQL) Injection ... 52

3.3.2 Cross Site Scripting (XSS) ... 52

3.3.3 Cross Site Request Forgery ... 52

4 Diskuze ... 53

5 Závěr ... 55

Použitá literatura ... 57

Přílohy ... 58

11

Seznam obrázků

Obrázek 1: Registrační formulář ... 45

Obrázek 2: Přihlašovací formulář ... 46

Obrázek 3: Hláška oznamující neúspěšné přihlášení ... 46

Obrázek 4: Mapová komponenta ... 48

Obrázek 5: Informace zobrazené po rozkliknutí značky v mapové komponentě ... 48

Obrázek 6: Ukázka grafu ... 51

12

Seznam zkratek a termínů

JSX – JavaScript Syntax Extension. Jedná se o rozšíření syntaxe JavaScrip- tu, která se používá především při práci s Reactem.

ES6 – ECMAScript6. Jedná se o specifikaci JavaScriptu standardizovanou Ecma International.

HTML – HyperText Markup Language. Jedná se o standardní značkovací jazyk, který se užívá k vytváření webových stránek.

CSS – Cascading Style Sheets. Jedná se o stylovací jazyk, který se používá k úpravě vzhledu webových stránek.

HTTP – HyperText Transfer Protocol. Jedná se o sadu standardizovaných příkazů, které slouží ke komunikaci mezi klientem a serverem v internetu.

WebSocket – Komunikační protokol, který poskytuje plně duplexní komu- nikaci přes TCP spojení.

SQL – Structured Query Language. Jazyk určený pro práci se sytémem re- lačních databází.

NoSQL – Výraz užívaný pro označení nerelačního typu databází.

JSON – JavaScript Object Notation. Jedná se o standardizovaný datový formát, který slouží k přenášení datových objektů.

BCRYPT – Hashovací funkce, která se používá především pro hashování hesel.

AJAX – Asynchronous JavaScript And XML. Sada technik umožňující vy- tváření asynchronních webových aplikací.

DOM – Document Object Model. API, které zachází s HTML stránkou, jako se stromovou strukturou, v níž je každý uzel reprezentován částí do- kumentu.

XML – Extensible Markup Language. Značkovací jazyk, který definuje pravidla pro zakódování dokumentů ve specifickém formátu, kterému ro- zumí stroj i člověk.

13

Úvod

Hlavním úkolem bylo seznámit se s aktuálním způsobem vizualizace dat regulátoru tepelného čerpadla a v rámci rešerše zjistit dostupné techniky vizualizace dat prostřednictvím HTML stránky a JavaScriptu.

Dále potom navrhnout techniku a nejvhodnější formát zobrazení dat ulože- ných v Cloudu a porovnat možná řešení. Naprogramovat webové stránky, které budou zobrazovat tato data, včetně grafů, map, animací a uživatel- ských oprávnění. Řešení potom otestovat z hlediska spolehlivosti a zabez- pečení na reálném systému.

Za hlavní výzvu se dá považovat seznámení se s různými způsoby vytváření webových aplikací, najít ten nejvhodnější a naučit se s ním pracovat tak, aby bylo dosaženo cílů práce. V tomto směru musí být důraz kladen na to, které technologie vytváření webových aplikací jeví největší potenciál v této oblas- ti. Je zapotřebí se dívat na možnosti těchto technologií, jejich bezpečnost, obtížnost a dostupnost.

Po vhodném výběru technologií bylo nutné důkladné seznámení s daty, kte- ré mají být vizualizována. Vzhledem k tomu, že mezi způsoby vizualizace patřily kromě standardního způsobu také graf nebo mapa, musel být prove- den průzkum o tom, zda v rámci daných vybraných technologií bude možné takové způsoby vizualizace správně realizovat.

Součástí práce bylo vytvoření vývojového a testovacího prostředí, které by bylo vhodné pro reálný systém. Do tohoto oddílu spadá lokální server a da- tabáze, na kterých má vývoj probíhat. Bylo proto zapotřebí zjistit v rámci rešerše, které dostupné prostředky se pro tento úkol nejvíce hodí a následně jich využít. Patří sem výběr vhodného typu databáze, kde se v potaz bere typ dat, se kterými se pracuje u regulátoru tepelného čerpadla.

Konečnou součástí práce bylo otestování spolehlivosti serveru při zvýšené zátěži či simultánně posílaných dotazů a otestování aplikace z hlediska bez- pečnosti, kdy byly prozkoumána rizika spojená s útoky přes web.

14

1 Rešerše

1.1 Vizualizace dat

Vizualizace dat je prezentování dat v obrázkovém či grafickém formátu.

Umožňuje lidem, kteří se na základě stavu těchto dat mají nějakým způso- bem rozhodovat, lépe uchopit jejich koncept a charakter.

S pomocí interaktivní webové aplikace má člověk možnost zobrazit data, která jsou jinak například uložena v surové podobě v databázi kdesi na Cloudovém serveru. Tato data může přes tuto aplikaci interaktivně filtrovat tak, aby viděl opravdu pouze ta data, která ho zajímají, například v podobě grafu.

Koncept vizualizace dat je velice důležitý, protože umožňuje lidskému mozku zpracovat informace pomocí diagramů či grafů, což je především při velkém množství komplexních dat mnohem jednodušší a přehlednější než kvanta tabulek.

Takový graf dokáže člověku pomoci snadněji identifikovat oblast, která si zaslouží větší pozornost. Díky tomu lze pak najít hlavní faktory, které mo- hou ovlivňovat stav daných dat. Zároveň je v některých případech možné na základě viditelného průběhu funkce v grafu předpovídat i jeho budoucí prů- běh, což se v mnoha oblastech dá využít.

Datová vizualizace mění způsob, jak analytici s daty pracují. Očekává se, že budou schopni reagovat na problém rychleji. Jsou schopni se dívat na data jinak, s větší představivostí a dokážou odhalit mnohem více, než kdyby se dívali pouze do rozsáhlých tabulek s číselnými informacemi.

Před implementací nové technologie pro vizualizaci dat, je důležité vzít v potaz několik kroků. Nejen, že je nutné přesně rozumět datům, která se mají prezentovat, ale také je potřeba znát cíle a potřeby konečných uživatelů těchto dat. Proto je potřeba, jak bylo řečeno [1], v přípravě zohlednit násle- dující:

 Porozumět datům, která se snažím vizualizovat, včetně jejich veli- kosti a kardinality (unikátnost hodnot ve sloupci)

15

 Určit, co se snažím zobrazit a jaké informace chci předávat

 Znát konečného uživatele a vědět jak bude zpracovávat zobrazené informace

 Použít takové zobrazení, které bude předávat informace co nejlepším a zároveň nejjednodušším způsobem

Jakmile jsou tyto kroky týkající se typu dat a konečných uživatelů splněny, je třeba se připravit na velikost dat, se kterými se má pracovat. Velká data s sebou přináší nové výzvy, protože velké objemy a různorodost je nutné vzít v potaz.

Jednou z největších výzev je rozhodování, která vizualizace je pro konkrétní případ nejvhodnější.

Všechny webové stránky jsou ve své podstatě interaktivní. Uživatelé se v nich navigují pomocí klikání myší a scrollováním, aby našli informace, stahovali dokumenty nebo třeba vyplňovali formuláře. V tomto kontextu však interaktivita znamená specifickou věc, kdy vlastnost webové aplikace jako je mapa, diagram nebo animace může být manipulována uživatelem bez potřeby znovu načítat webovou stránku.

Těmto typům vlastností se říká data-driven graphics. Hlavním účelem data- driven graphics je zobrazení komplexních informací tak, aby byly srozumi- telné a snadno analyzovatelné. Tento typ vizualizací je vhodný, když je za- potřebí prezentace komplexních dat, které uživatel potřebuje analyzovat.

Běžnými nevýhodami data-driven graphics můžou být následující:

 Mohou být drahé na vytvoření

 Nemusí být dostatečně flexibilní, pokud se změní datový model

 Těžko editovatelné

 Těžko optimalizovatelné pro mobilní zařízení

 Mohou se snadno „rozbít“, pokud do nich vstupují nesprávná data Uživatel se k jejich použivání musí naučit jejich práci s jejich rozhraním

16 1.2 Dostupné technologie

S tím jak jde doba, uživatelé očekávají od webových aplikací, že budou schopny pracovat téměř na stejné úrovni co se výkonu a interaktivity týče, jako desktopové nebo mobilní aplikace. Samozřejmě se také od vývojářů očekává, že budou schopni takovou aplikaci rychle a efektivně rozšiřovat a především udržovat. Je proto zapotřebí vybrat si vhodnou technologii při jejím vytváření, která by měla zaručit, že s časem nebude příliš klesat její podpora a popularita. Často je takových technologií více, kde každá plní určitou část práce, pro kterou byla vytvořena a poté spolu spolupracují a tvoří takzvaný technologický stack.

Pro tuto práci byl vybrán MERN stack, což je zkratkou pro technologie MongoDB, Express, React a Node.js. To co mají tyto technologie společné je JavaScript a jeho následníky jako ES6, Typescript nebo JSX. Dříve bylo využití JavaScriptu značně limitující, když víceméně pouze přidával vizuál- ní efekty na webové stránce. V dnešní době je však JavaScript již tak rozší- řený, že jej vývojáři používají také pro tvorbu aplikační logiky a pro práci s databází.

Hlavním důvodem pro volbu MERN stacku byl fakt, že obsahuje právě Re- act, což je hlavní frontendový prvek. React je knihovna vytvořená Faceboo- kem umožňující vývoj interaktivních a reaktivních uživatelských rozhraní ve webové aplikaci. Rozděluje front end aplikace na jednotlivé komponenty, z nichž každá může udržovat svůj vlastní stav.

Komponenty jsou v Reactu implementovány pomocí JSX, což je syntaktic- ké rozšíření pro JavaScript. React využívá faktu, že logika vykreslování je úzce spjata ostatní logikou uživatelského rozhraní: jak se zpracovávají udá- losti, jak se v čase mění stav a jak se data připravují k vykreslení. Na místo toho, aby se uměle oddělovaly technologie tak, aby logika webu a značko- vací jazyk byly v rozdílných souborech, React je volně spojuje do kompo- nent, které obsahují obojí.

Obrovskou výhodou při vytváření rozhraní v Reactu je široká škála kniho- ven obsahující komponenty, které byly již vytvořeny jinými vývojáři. Je to jeden z důvodů proč je vhodné zvolit populární technologii jako je React,

17

protože mnohokrát není zapotřebí znovu vymýšlet kolo, neboť konkrétní problém byl již nejspíše vyřešen dříve někým jiným, kdo dal svůj kód k dispozici pro veřejnost.

1.3 Databáze

Data se shromažďují v databázích. Na základě toho, s jakými daty se pře- vážně pracuji, je potřeba zvolit také vhodný typ databáze, která bude s těmito daty schopna efektivně nakládat.

1.3.1 Relační databáze

Jedním velkým typem databáze jsou takzvané relační databáze, kterým se také říká SQL databáze. Mezi nejznámějšími zástupci tohoto typu jsou:

 Microsoft SQL Server

 Oracle Database

 MySQL

 PostgreSQL

V relačních databázích jsou data reprezentována pomocí tabulek a řádků.

Jsou založeny na základě odvětví algebry známém jako relační algebra.

Jak zmiňuje Keith D. Foote [6], relační databáze používají SQL(Structured Query Language), což z nich dělá správnou volbu pro aplikace, ve kterých je obsaženo řízení několika transakcí. Struktura relační databáze umožňuje propojení informací z různých tabulek použitím cizích klíčů či indexů, které slouží i unikátní identifikaci jednotlivých dat v rámci tabulky. Další tabulky se mohou na takový cizí klíč odkazovat, čímž vznikne chtěné propojení dat mezi tabulkami. Takové vlastnosti jsou velmi užitečné v aplikacích, které se silně soustředí na analýzu dat.

Jsou-li vysoké nároky na databázi v podobě složitých dotazů, transakcí a častých analýz, potom je relační databáze vhodnou volbou. V případě vel- kého množství transakcí je důležité, aby tyto transakce proběhly spolehlivě.

Zde přichází v potaz sada vlastností, které tuto spolehlivost u relačních da- tabází zajišťují, známá jako ACID.

 Atomicita

18

 Konzistence

 Izolovanost

 Trvalost

Tyto vlastnosti zaručují, že databázové transakce proběhnou v pořádku a nepoškodí data v případě chyb, výpadku elektřiny apod.

Atomicita znamená, že transakce je jako operace nedělitelná. Provede se buď celá, nebo vůbec.

Konzistence zajišťuje, že kterákoli transakce převede databázi z validního stavu do jiného, opět validního stavu. To znamená, že data, která budou psána do databáze, musí splňovat veškerá pravidla včetně integritních ome- zení, kaskád, triggerů a jejich kombinací.

Izolovanost znamená, že operace uvnitř transakce jsou skryty před vnějšími operacemi. Je-li vrácením transakce (ROLLBACK) zasažena jiná transakce, musí se i tato transakce vrátit. Tím může vzniknout tzv. kaskádový rollback.

Trvalost zaručuje, že změny provedené transakcemi se skutečně uloží do databáze a nemohou být ztraceny.

Silné stránky relačních databází:

 Práce se strukturovanými daty

 Podpora transakční konzistence (ACID) a podpora spojení (JOIN)

 Vztahy v tomto systému mají omezení

 Indexování nemá limit. Silné SQL.

Slabé stránky relačních databází:

 Špatná horizontální škálovatelnost (pokud se nepoužije „sharding“)

 Data jsou normalizována, nutnost velkého množství spojení (JOI- Nů), což má silný vliv na rychlost

 Problémy, nejsou-li data správně strukturována

19

1.3.2 Nerelační databáze

Jacqueline Homan [3] píše o tom, jak během posledních deseti let se výraz- ně změnil způsob, jakým webové aplikace nakládají s daty. Stále větší množství dat je shromažďováno a stále více uživatelů k těmto datům přistu- puje zároveň. To znamená, že škálovatelnost a výkon jsou stále větší výzvou pro relační databáze, které jsou založeny na určitém schématu, a tudíž je jejich škálovatelnost do jisté míry omezená.

Na tyto problémy narazily firmy pracující s velkými daty a jejich infrastruk- turami, jako Google, Amazon nebo Facebook. Tyto firmy následně začaly přicházet s vlastními řešeními, technologiemi jako BigTable, DynamoDB nebo Cassandra.

Začaly vznikat spousty alternativ v podobě NoSQL Database Management Systems (DBMS), jejichž primárními cíly byly rychlost, spolehlivost a kon- zistence. Již první takové systémy se staly brzy velice úspěšnými a to dalo za vznik spoustě nových, open-source systémů jako MongoDB, HBase nebo Redis.

Typickým rozdílem NoSQL databází od běžných relačních databází je fakt, že NoSQL je formou nestrukturovaného úložiště. To znamená, že NoSQL databáze nemají fixní tabulkovou strukturu typickou právě pro relační typ databází.

Důležitým faktorem, který může odradit od použití většiny nerelačních da- tabází je ten, že tyto databáze nativně nepodporují vlastnosti zaručující spo- lehlivost, jako tomu je u relačních databází (Atomicita, Konzistence, Izolovanost, Trvalost). NoSQL databáze, které tyto vlastnosti nemají, tedy získávají výkon a škálovatelnost na úkor konzistentního chování. To je evi- dentně závažný problém a proto musí v mnoha případech vývojáři imple- mentovat vlastní kód řešící tyto nedostatky, což dělá systém komplexnějším.

Další komplexita vzniká z faktu, že NoSQL databáze, jak již název napoví- dá, nepodporují standardní SQL dotazy. To způsobí, že je navíc potřeba vytvořit vhodný dotazovací jazyk.

20

Kategorie nerelačních databází

Key-value Store

Tento typ funguje jako hash tabulka, v níž unikátní klíč ukazuje na specific- kou hodnotu. Tyto klíče mohou být organizovány do logických skupin tak, že jejich unikátnost se může vztahovat pouze na jejich vlastní skupinu.

K přístupu k datům je zapotřebí pouze tento klíč a data jsou uložena ve for- mě textových řetězců nebo JSONu. Nejznámější databází tohoto typu je DynamoDB od Amazonu.

Document Store

Typ, který se velice podobá typu key-value v tom, že postrádá schéma a je také založen na modelu klíč-hodnota. Zrovna tak se příliš neliší jejich výho- dy a nevýhody. Významým rozdílem je ten, že hodnoty v tomto typu (do- kumenty) poskytují zakódování pro uložená data. Tyto kódování mohou být XML, JSON nebo BSON (Binárně zakódovaný JSON). Zároveň je u tohoto typu možné používat dotazy pracující přímo s daty. Nejpopulárnější databá- ze tohoto typu je MongoDB.

Column Store

V tomto typu databáze jsou data ukládány do sloupců na rozdíl od řádků, jak je tomu u sytémů relačních databází. Toto úložiště se skládá z jedné ne- bo více rodin sloupců, které logicky seskupují specifické sloupce databáze.

Klíč je používán k identifikaci a jako ukazatel na počet sloupců. Tento klíč obsahuje atribut keyspace, který definuje rozsah toho klíče. Každý sloupec obsahuje n-tice typu jméno-hodnota, které jsou seřazené a oddělené čárkami (comma separated). Vzhledem ke způsobu, jakým jsou data ukládány na disk, umožňuje tento typ databáze rychlé čtecí a zápisové operace. Mezi významné databáze tohoto typu patří například Cassandra, BigTable nebo HBase.

Graph Base

U tohoto modelu jsou pro reprezentaci dat užívána struktura orientovaných grafů, skládajících se z hran a uzlů. Graf je reprezentací skupiny objektů,

21

kde některé páry těchto objektů jsou propojeny. Vzájemně propojené objek- ty jsou poté reprezentovány vrcholy a jejich propojení je hranou. Typicky se tento typ databáze používá pro aplikace, u nichž jsou důležitější vztahy mezi objekty než hodnota samotných objektů. Mezi současné populární databáze tohoto typu patří InfoGrid nebo InfiniteGraph.

Silné stránky nerelačních databází:

 Efektivní horizontální škálovatelnost a práce s částečně strukturova- nými daty

 Není zapotřebí schéma

 Vysoká dostupnost

Slabé stránky nerelačních databází:

 Slabší nebo eventuální konzistence

 Limitovaná podpora spojení

 Data nejsou normalizována, vyžadují hromadné updaty.

 Nemají vestavěnou datovou integritu

 Limitované indexování 1.3.3 MongoDB

Document-oriented databáze bez fixního schéma. Je napsána v C++ a hod- noty ukládá coby dokumenty ve formě zakódovaných dat. Formátem kódo- vání u MongoDB je JSON, což znamená, že zapouzdřené hodnoty v dokumentech jsou indexovatelné a lze na ně tedy aplikovat dotazy.

Mezi klíčové vlastnosti MongoDB patří sharding. Jak je popisováno v do- kumentaci MongoDB [4], tato vlastnost umožňuje rozdělit data mezi více uzlů (strojů) a tím zajistit schopnost efektivně pracovat s enormním množ- stvím dat. Tento způsob získávání výpočetního výkonu se nazývá právě horizontálním škálováním. Naopak pokud se výkon zvyšuje v rámci pouze jednoho serveru, potom se jedná o škálování vertikální. Vertikální škálování je samozřejmě limitováno dostupností technologií, proto u něj existuje urči- tý strop.

22 Horizontální škálování zahrnuje rozdělování dat a zátěže mezi více serverů, kde každý nový přidaný server zvyšuje celkovou kapacitu a výkon, je-li potřeba. Zatímco celková rychlost či kapacita jednoho stroje nemusí být příliš vysoká, každý ze strojů pracuje pouze s podmnožinou z celkové zátě- že, čímž potenciálně poskytuje vyšší efektivitu než-li jediný silný stroj. Ne- výhodou je potom samozřejmě komplexnost infrastruktury a vyšší náročnost na údržbu.

MongoDB používá RESTful API. K získání dokumentů z kolekce v databázi se vytvoří dotazový dokument, který obsahuje jednotlivá pole, která by měl hledaný dokument obsahovat.

1.4 HTML

Hypertext Markup Language je standardní značkovací jazyk, který se vyu- žívá k tvorbě webových stránek a aplikací. Společně s kaskádovými styly (Cascading Style Sheets) a JavaScriptem tvoří základní trojici technologií ve World Wide Webu.

Webové prohlížeče získávají HTML dokumenty z webových serverů nebo z lokálního úložiště a tyto dokumenty následně vykreslují uživateli jako multimediální webové stránky. HTML jako takové slouží především k popisu obsahu dokumentu a sémantické struktury. Navzdory tomu, že je to do jisté míry možné, nedoporučuje se pomocí HTML popisovat vzhled stránky. O design se starají především kaskádové styly.

HTML elementy jsou stavebními kameny HTML stránek. Tento jazyk po- skytuje prostředky pro sestavení strukturovaných dokumentů pomocí množ- ství tagů, které mají každý svou vlastnost a tyto tagy určují, o jaká data se jedná. Je tedy možné pomocí HTML tagů určit, zda je daný text hlavičkou, odstavcem, seznamem, odkazem apod. Zrovna tak je možné vkládat do do- kumentů obrázky nebo například vytvářet interaktivní formuláře.

Do HTML lze vkládat programy psané ve skriptovacím jazyce, jako je na- příklad právě zmíněný JavaScript, který ovlivňuje chování obsahu webové stránky. Díky základní struktuře, kterou HTML poskytuje, je velice pohodl-

23

né pro tyto scriptovací jazyky přistupovat k datům, se kterými se má praco- vat.

Současným standardem je od roku 2014 HTML 5, který je pátou hlavní ver- zí HTML standardu. Tento standard zahrnuje detailní procesové modely, aby bylo možné psát lépe spolupracující implementace. Dále rozšiřuje a vylepšuje značky (tagy) dostupné pro strukturování dokumentů. Zahrnuje mnoho nových syntaktických vlastností pro inkluzi multimediálních dat a grafického obsahu. Mezi tyto nové vlastnosti patří především elementy

<canvas>, <audio> a <video> nebo například podpora Scalable Vector Graphics (SVG) obsahu.

1.5 Kaskádové styly

Nezbytnou součástí každého webového front endu jsou kaskádové styly.

Zkratka CSS z anglického originálu Cascading Style Sheets. Používají se pro popis vzhledu dokumentu napsaného ve značkovacím jazyce.

Primárně slouží k oddělení obsahu od formy, jakým je obsah prezentován.

Upravují například rozvržení obsahu, barvy nebo písmo. Díky tomu, že se na toto nastylování dokumentů lze odkazovat v jiném dokumentu, umožňuje to vývojáři snadno specifikovat styly, které chce aplikovat ve kterých do- kumentech a pro které elementy.

Kaskádové styly se aplikují na určitý selektor, který deklaruje, na kterou část dokumentu se má styl aplikovat. Těmto selektorům odpovídají značky (tagy) nebo identifikační atributy:

 id – je unikátní, aplikuje se pouze k jedinému elementu

 class – pomocí tohoto atributu lze identifikovat vícero elementů Kromě toho se lze odkazovat na část dokumentu vzhledem k relativnímu umístění v rámci dokumentového stromu.

Pro formátování na základě informací, které nejsou obsaženy v dokumentovém stromu, existují takzvané pseudo-třídy. Typickým příkla- dem takové pseudo-třídy je :hover, která identifikuje pouze ten obsah, na který uživatel právě ukazuje, zpravidla prostřednictvím ukazetele myši. Ta-

24 ková pseudo-třída se potom přidá k selektoru, na který se má speciální pra- vidlo aplikovat.

Kaskádové styly je možné do dokumentu zavést několika způsoby:

 Inline styly

 Vložené styly

 Externí styly 1.5.1 Inline styly

Jedná se o styly, které jsou aplikovány na obsah ihned při jeho vytváření, protože jsou vepsány přímo coby atribut v tagu. Např.:

<p style=”color:blue;”></p>

Takto psané styly se však nedoporučují především proto, aby zůstalo zacho- váno oddělení obsahu dokumentu od formy. Zároveň je však v některých případech takové psaní stylů pohodlné a lze vzít v potaz i fakt, že takto apli- kované styly mají přednost před ostatními, takže mohou přepsat formátova- ní, aplikované jiným způsobem.

1.5.2 Vložené styly

Tyto styly jsou definované v párovém tagu <style>, zachovávají přehled- nost značkování, nicméně jsou svázány s jediným dokumentem. Proto ani tento způsob nebývá doporučován, neboť ve většině případů je zapotřebí styly aplikovat ve vícero dokumentech.

1.5.3 Externí styly

Preferovaný způsob zápisu kaskádových stylů, protože umožňuje sdílení stylů mezi více dokumenty a snižují tak celkový objem kódu, který musí prohlížeč stáhnout. V HTML dokumentu se na soubor, kde jsou styly defi- novány lze jednoduše odkázat.

V této práci byly některé styly aplikovány prostřednictvím pre-processoru CSS.

25

1.6 CSS Pre-processory

Již několik let jsou k vývoji u některých webových front endů využívány takzvané CSS pre-processory. Během času získaly mnoho vlastností, mezi něž se řadí možnost práce s proměnnými, operátory, interpolacemi, funkce- mi a dalšími užitečnými prvky. Mezi nejznámější pre-processory CSS patří SASS, LESS a Stylus.

Důvodem, proč se tyto pre-processory používají je fakt, že CSS jako takové je velice primitivní a dalo by se říct neúplné. S těží v něm lze například vy- tvořit funkci nebo využít dědičnosti. Jakmile se projekty rozrostou do vel- kých rozměrů, z údržby kódu se stává větší a větší problém.

Aby se daly psát lepší kaskádové styly, vytvářely se různé přístupy jako například rozdělení definic stylů do menších souborů a jejich následný im- port do hlavního souboru. Tento přístup pomohl se vypořádat s komponentami, ale nevyřešil opakování kódu a problém s náročnou údrž- bou. Dalším přístupem bylo původní zobjektizování kaskádových stylů. V tomto případě šlo o aplikaci dvou a více definic tříd, kde každá přídává da- nému elementu jeden typ stylování. Díky tomu se zvýšila možnost znovu použití již implementovaného kódu, ale zároveň se opět snížila jeho udržo- vatelnost.

Pre-processory se svými pokročilými vlastnostmi pomohly k dosáhnutí na možnost psaní znovu použitelného, dobře udržovatelného a snadno rozšiři- telného kódu v CSS.

Stejně jako každý programovací jazyk, mají i tyto pre-processory rozdílnou syntaxi. Všechny však podporují základní CSS syntaxi. Například SASS a Stylus mají některé styly navíc, v SASSU je možné vynechat složené závor- ky a středníky, zatímco ve Stylusu lze vynechat i čárky.

1.6.1 Proměnné

Odjakživa chtěná vlastnost pro CSS. Díky nim lze například definovat zá- kladní barvu, která bude používána v rámci celého souboru se styly.

V SASSu začíná definice proměnné znakem $, v LESSU znakem @ a Sty- lus žádnou předponu nemá.

26 1.6.2 Vnořování

CSS postrádá vizuální hierarchii při práci se selektory, které jsou zároveň potomky. V CSS je zapotřebí kombinaci selektorů zvlášť do řádků. Vnořo- vání, které pre-processory poskytují, usnadňuje čitelnost kódu

1.6.3 Mixins

Mixin umožňuje vytvářet skupiny CSS deklarací, o kterých vývojář ví, že se budou v rámci souboru vícekrát opakovat. Po deklaraci mixinu je možné jej poté možné je přidávat k selektorům. V SASSU se mixin definuje klíčovým slovem @mixin a pro vkládání do selektoru pomocí @include.

1.6.4 Extends

Extends jsou užitečné pro sdílení běžných definic mezi selektory namísto jejich kopírování. V SASSU lze tuto vlastnost použít s pomocí klíčového slova @extend a poté vybráním konkrétního selektoru.

Dalšími užitečnými prvky, které CSS pre-processory nabízejí, jsou podmín- ky, cykly nebo matematické operace.

1.7 JavaScript

Jedná se o lightweight, interpretovaný programovací jazyk s first-class funkcemi. Programovací jazyk se považuje za lightweight, pokud byl nav- ržen tak, aby příliš nezatěžoval paměť, byl jednoduchý na implementaci a měl minimalistickou syntaxi.

Je interpretovaný, protože jeho implementace nevyžaduje předchozí kompi- laci programu do strojového jazyka.

JavaScript je programovací jazyk s first-class funkcemi, protože se chová k funkcím jako first-class objektům, které lze předávat jako argumenty, mo- hou být vráceny z funkce, jsou modifikovatelné a mohou být přiřazeny jako hodnota do proměnné.

Tento programovací jazyk je nejznámější pro své využití při psaní scriptů pro webové stránky. Je však využíván i v mnoha prostředích mimo prohlí- žeče, například v Node.js nebo Apache CouchDB.

27

Jedná se o prototype-based programovací jazyk. Jde o formu znovu-užívání kódu v objektově orientovaném prostředí v podobě dědičnosti. U tohoto typu dědičnosti, objekty dědí přímo z jiných objektů, nikoli z tříd, jak je tomu u klasického typu dědičnosti. V JavaScriptu lze proto vytvořit objekt bez předchozí definice třídy. Každý objekt v JavaScriptu má v sobě odkaz na objekt, který jej vytvořil, čímž se vytváří jakýsi řetěz. Je-li objekt dotázán na vlastnost, kterou nemá, bude dotázán jeho předek. Tento princip pokraču- je, dokud se nedosáhne kořenového objektu.

Současným standardem pro JavaScript je ECMAScript. Od roku 2012 pod- porují všechny moderní prohlížeče verzi ECMAScript 5.1. Starší prohlížeče podporují alespoň ECMAScript 3. V roce 2015 byla vydána šestá hlavní verze ECMAScriptu, která se oficiálně jmenuje ECMAScript 2015, ale běž- ně se na ní odkazuje jako na ECMAScript 6 nebo ES6. Nejaktuálnější je potom ECMAScript 2017.

Je možná důležité zmínit, že JavaScript nemá nic společného s programovacím jazykem Java. Obě tyto ochranné známky jsou registrová- ny pod společností Oracle, ale oba tyto jazyky mají velmi rozdílné syntaxe, sémantiku a využití.

1.7.1 JSX

const element = <h1>Hello, world</h1>

Zdrojový kód 1: ukázka JSX

Nejedná se o řetězec, ani o HTML. Nazývá se to JSX a je to vlastně syntak- tické rozšíření JavaScriptu. Je doporučeno používat JSX při práci s Reactem k popisu, jak má uživatelské rozhraní vypadat. JSX produkuje takzvané Re- act elementy, jímž je věnována vlastní kapitola.

React nevyžaduje použití JSX, ale většina lidí ho považuje za vizuální po- moc při práci s uživatelským rozhraní uvnitř JavaScriptového kódu. Zá- roveň JSX umožňuje React ukazovat více užitečných chybových a varovných zpráv.

28 Zapouzdření výrazů v JSX

Jakýkoli JavaScriptový výraz je možné zapouzdřit v JSX pomocí složených závorek. Např.:

const user = {

firstName: 'Tomáš', lastName: 'Klikorka' };

const element = ( <h1>

Hello, {user.firstName}

</h1>

);

Zdrojový kód 2: další ukázka JSX

Po kompilaci se z JSX výrazů stávájí běžné JavaScriptové funkční volání, které se vyhodnotí jako JavaScriptové objekty. To znamená, že je také mož- né použít JSX uvnitř podmínek, cyklů, lze jej přiřadit do proměnné, při- jmout jej jako argument a vrátit jej z funkce.

JSX brání injection útokům

React DOM už v základu escapuje všechny hodnoty zapouzdřené v JSX předtím, než jsou vykresleny. To zajišťuje, že nebude možné provézt in- jection, pokud není takový kód zapsaný přímo v aplikaci. Vše je konverto- váno na řetězec předtím, než se to vykreslí, což pomáhá bránit útokům známým jako XSS (Cross Site Scripting).

29

1.8 AJAX

Zkratka odvozená z Asynchronous JavaScript + XML. Nejedná se o samo- statnou technologii, ale označuje se tak způsob přístupu k použití několika technologií dohromady. Do těchto technologií patří HTML nebo XHTML, CSS, JavaScript, DOM, XML, XSLT a především XMLHttpRequest objekt.

Jsou-li tyto technologie zkombinovány Ajax modelem, potom jsou webové aplikace schopné provádět rychlé, inkrementální aktualizace uživatelského rozhraní bez potřeby znovu načítat celou stránku v prohlížeči. To zajistí, že je aplikace rychlejší a lépe reagující na uživatelské akce.

Navzdory tomu, že X v Ajaxu znamená XML, mnohem častěji se používá JSON, protože je lehčí („lightweight“) a je součástí JavaScriptu. Jak JSON tak XML se používají pro zabalení informací v Ajax modelu.

1.8.1 XMLHttpRequest

Zkráceně XHR je objekt, který se používá k interakci se serverem, kdy je možné získat data z URL bez potřeby znovu načtení stránky a také je možné stejným způsobem v pozadí data na server odesílat.

1.9 React.js

React je JavaScriptovou knihovná knihovna, která je určená pro vytváření uživatelských rozhraní. Hlavními vývojáři této knihovny jsou Facebook a Instagram.

Tato moderní knihovna umožňuje vývojářům vytvářet rozměrné webové aplikace, které jsou schopny zobrazovat měnící se data bez nutnosti znovu načítání webové stránky. Hlavní cíle této knihovny je poskytnutí rychlosti, jednoduchosti a škálovatelnosti pro tyto aplikace. Vzhledem k tomu, že Re- act pracuje pouze s uživatelským rozhraním, je možné jej využít v rámci MVC architektury coby View.

React poskytuje schopnost rozdělení stránky na jednotlivé komponenty, jejichž kombinací je daná stránka tvořena. Tyto komponenty mohou také obsahovat další komponenty a každá komponenta lze použít i kdekoli jinde v aplikaci.

30 Vzhledem k tomu, že React je sám o sobě pouze jednou knihovnou a nikoli celým frameworkem, je zapotřebí si při tvorbě aplikace vytvořit jakýsi vlastní framework, který bude obsahovat potřebné nástroje a knihovny pro práci s Reactem.

S Reactem souvisí spousta unikátních konceptů, o kterých je psáno přede- vším v dokumentaci [5].

1.9.1 Virtual DOM

Document Object Model, neboli DOM je abstrakcí HTML dokumentu. Jed- ná se vlastně o API s jehož pomocí lze pracovat se samotnou HTML strán- kou. Toto API umožňuje přistupovat k jednotlivým objektům dokumentu a dále s nimi pracovat zpravidla prostřednictvím JavaScriptu. Mezi tyto ob- jekty patří elementy, atributy texty a komentáře. Objekty v rámci DOMu tvoří stromovou strukturu díky tomu, jak jsou HTML dokumenty postavené, což znamená, že každý jednotlivý objekt může mít předka, potomka nebo sourozence. Stromy se dají zpravidla snadno procházet, což však nezaručuje zároveň rychlost.

V dnešní době jsou DOM stromy velmi rozsáhlé a vzhledem k faktu, že se snažíme tvořit především dynamické webové aplikace(Single Page Applica- tions), jsme nuceni modifikovat DOM takřka neustále, což znamená velkou zátěž. Standardní zpracování události funguje stylem „najdi každý uzel, kte- rý souvisí s danou událostí a je-li to zapotřebí, aktualizuj jeho stav“. Místo toho, aby se musely manuálně hledat uzly, které potřebují update, hodilo by se vědět předem, který konkrétní uzel se bude upravovat. React proto posky- tuje řešení jménem Virtuální DOM o kterém píše Bartozs Krajka [2].

Virutální DOM je abstrakcí HTML DOMu, což z něj dělá vlastně abstrakci abstrakce. Dá se o něm přemýšlet jako o lokální, zjednodušenou kopii HTML DOMu, která umožní Reactu provádět výpočty v rámci této abstrak- ce, čímž se vyhne pomalým operacím uvnitř skutečného DOMu.

Základními uzly v tomto virtuálním DOMu jsou ReactElementy. O nich dokumentace říká, že jsou lehké, bezstavové, neměnné, virtuální reprezenta- ce DOM elementů. Jejich neměnnost způsobuje, že se dají snadno a velmi

31

rychle porovnávat a obnovovat, což je hlavním důvodem proč je React tak rychlý. Jakmile je ReactElement nadefinován, stává se součástí skutečného DOMU a React nad ním ztrácí kontrolu.

Mnohem zajímavějšími prvky jsou však ReactComponenty. Tyto kompo- nenty již totiž nejsou bezstavové a lze s nimi pracovat coby s třídami, včetně proměnných konstant apod. Vykreslované HTML bloky mohou mít stav a nejlepší na tom je, že kdykoli se tento stav změní, komponenta se překreslí, což je velice užitečná vlastnost pro tvorbu dynamických webových aplikací.

Tyto samotné komponenty nemají přístup do virtuálního DOMu, avšak mo- hou být překonvertovány na ReactElementy, potom být v rámci virtuálního DOMu rychle porovnány nebo obnoveny. Tento postup stále zaručuje vyšší efektivitu než práce s bežným DOMem.

1.9.2 Vykreslování Elementu do DOMu

Aplikace psaná v Reactu musí obsahovat ve svém HTML souboru takzvaný kořenový DOM uzel, který může vypadat například takhle:

<div id="root"></div>

Říká se mu kořenovým DOM uzel, protože všechno uvnitř tohoto uzlu bude řízeno React DOMem. Aplikace psané čistě v Reactu mají obvykle jediný kořenový DOM uzel. Pokud je React pouze integrován do již existující apli- kace, potom může takových izolovaných kořenových DOM uzlů i více.

32 K vykreslení React elementu do kořenového DOM uzlu se používá funkce ReactDOM.render(), do které se jako argumenty předají jak daný element, tak kořenový DOM uzel. Např.:

const element = <h1>Hello, world</h1>;

ReactDOM.render(

element, document.getElementById('root') );

Zdrojový kód 3: ukázka práce s ReactDOM

Tento kód vykreslí na stránce textový řetězec „Hello, world“.

React elementy jsou neměnné (immutable). Jakmile je React element vytvo- řen není možné měnit jeho potomky ani atributy. Takový element je jako jediný snímek ve filmu: reprezentuje uživatelské rozhraní v určitém časo- vém okamžiku.

React aktualizuje pouze to, co je potřeba. React DOM porovnává element a jeho potomky s předchozím stavem a aplikuje aktualizaci DOMu pouze v místech, kde skutečně došlo ke změně.

1.9.3 Komponenty a Props

Komponenty umožňují vývojářům rozdělit uživatelské rozhraní do nezávis- lých, znovu použitelných částí a přemýšlet o jednotlivých částech samostat- ně.

Konceptuálně jsou komponenty stejné jako JavaScriptové funkce. Příjmají volitelné vstupy, kterým se říká „props“, což se jako slovo dá považovat za zkráceninu slova „properties“ neboli vlastnosti, a vrací React elementy po- pisující co by se mělo objevit na obrazovce.

Nejjednodušším způsobem definice nové komponenty je zápis ve tvaru JavaScriptové funkce:

function MyComponent(props) {

return <h1>Hello, {props.name}</h1>;

}

Zdrojový kód 4: ukázka definice nové komponenty

33

Tato funkce je platným zápisem Reactové komponenty, protože přijímá jediný objektový argument „props“ s daty a vrací React element. Takové komponenty se nazývají „funkční“, protože se jedná doslova o JavaScripto- vou funkci.

Dalším způsobem definice komponenty je použití ES6 třídy:

class MyComponent extends React.Component { render() {

return <h1>Hello, {this.props.name}</h1>;

} }

Zdrojový kód 4: ukázka definice nové komponenty pomocí třídy

Z pohledu Reactu jsou oba zápisy ekvivalentní, ale ES6 třídy mají navíc některé užitečné vlastnosti.

1.9.4 Vykreslování komponent

React element může reprezentovat běžný DOM tag:

const element = <div />;

Nebo může React element reprezentovat uživatelsky definované komponen- ty:

const element = <MyComponent name=”Tom” />;

Jakmile vidí React element, který reprezentuje uživatelsky definovanou komponentu, předá této komponentě prostřednictvím jediného objektu atri- buty. Jedná se o již zmíněné props.

Takový element se poté nechá předat vykreslovací funkci.

Je třeba zmínit, že komponenty mohou odkazovat na jiné komponenty ve svém výstupu, což uživateli umožňuje použít stejnou abstrakci pro libovol- nou úroveň detailu. Komponentou tak nemusí být pouze jednoduchá věc

34 typu tlačítko, ale klidně celý formulář nebo stránka, kde každá větší kompo- nenta může obsahovat ty menší. Všem těmto případům se v React aplikaci říká stejně, tedy komponenta.

Typicky je na vrcholu každé React aplikace komponenty s názvem „App“, která pod sebou obsahuje všechny ostatní.

Props jsou pouze pro čtení

Na rozdíl od state, o kterém je řeč později, props jsou v komponentě vý- hradně pro čtení. Ať už je komponenta deklarována jako funkce nebo třída, nemůže nikdy modifikovat své props. Komponenty se ve vztahu ke svým props musejí chovat jako čisté (pure) funkce, kterým se tak říká, protože nemění svůj vstup.

1.9.5 State a Lifecycle

State, který by se počeštil jako „stav“ je velice podobný props s tím rozdí- lem, že je privátní a plně ovládaný komponentou. Lokální stav je k dispozici váhradně komponentám definovaným jako třídy.

Lifecycle, neboli životní cyklus komponenty se týká speciálních metod, které se volají v určitých fázích života komponenty. Jsou vhodné například v případě, kdy je komponenta odstraněna a chceme, aby byly uvolněny zdroje, které využívala.

Vykreslování komponenty v aplikace se v Reactu nazývá „mounting“ a od- straňování komponenty naopak „unmounting“.

1.9.6 Lifecycle metody

Mezi zmíněné speciální lifecycle metody, kterým se také říka „lifecycle hooks“ patří:

componentWillMount

Metoda, která je volána předtím, než se komponenta vůbec nechá vykreslit.

Z toho důvodu nelze zatím nikterak pracovat s DOMem. Tato metoda se může jevit jako poněkud zbytečná neboť zatím během životního cyklu ne- mohlo k ničemu dojít a základní konfigurace komponenty bývá definována v jejím konstruktoru. Výjimkou by mohlo být například připojování exter-

35

ního API, což by se však přesto mělo ošetřovat pouze v kořenové kompo- nentě. Z těchto důvodů se jedná o velmi zřídka využívanou lifecycle meto- du.

componentDidMount

Metoda, která je volána poté, co je komponenta vykreslena do DOMu. Zde je možné nechat provézt vše, co nebylo možné bez DOMu, jako například přidání event listeneru. Nejobvyklejší využití pro tuto metodu je AJAX volání pro načtení potřebných dat pro danou komponentu.

componentWillReceiveProps

Pokud dojde k situaci, kdy mají například přijít props z rodičovské kompo- nenty, tak předtím, než se s těmito props bude moci jakkoli nakládat, zavolá se tato metoda. V tomto místě má uživatel přístup jak k současným props, tak k těm novým. Obvykle se tak zkontroluje, zdali došlo k významné změ- ně v props a v případě, že ano, lze na to vytvořit vhodnou reakci.

shouldComponentUpdate

Kdykoli React komponenta obdrží nové props nebo state, měla by se zak- tualizovat. Z toho důvodu existuje tato metoda, která se v podstatě ptá, zdali se má komponenta překreslit nebo ne. Vrací boolean a výchozí hodnotou je true. Hlavním využítím této metody je tedy kontrola nad tím, v jakých situa- cích se má komponenta překreslit a v jakých naopak nikoliv.

componentWillUpdate

Chystá-li se komponenta překreslit, zeptá se touto metodou, co se má stát než k samotnému překreslení opravdu dojde.

componentDidUpdate

Metoda, která se zavolá poté, co došlo k aktualizaci komponenty. Používá se k upravování DOMu v reakci na změny v props nebo ve state.

36 componentWillUnmount

Metoda, která je volána předtím, než bude komponenta odebrána z DOMu.

Zde je možné například odebrat veškeré naslouchače událostí(event listene- ry) nebo ukončit síťové requesty, tak aby po dané komponentě nic zbyteč- ného nezůstalo.

1.10 Webpack

Webpack, který byl použit v této aplikaci, je mocná JavaScriptová knihovna vytvořena Tobiasem Koppersem, kterou využívá takřka každý JavaScripto- vý framework či projekt. Jedná se o nástroj, který je schopný seskupit veš- keré moduly v aplikaci, ať jde o JavaScript, kaskádové styly, fonty, obrázky nebo HTML. Tyto moduly poté transformuje do vhodného formátu pro in- ternetový prohlížeč. Webpack při zpracovávání dané aplikace připravuje graf závislostí. Začne vždy ze seznamu modulů definovaných ve vlastním konfiguračním souboru a rekurzivně pokračuje v tvorbě grafu, který obsahu- je všechny potřebné moduly pro danou aplikaci a následně utvoří jeden nebo malé množství balíčků, které prohlížeč zpracuje.

Při konfiguraci se zadává jeden nebo více vstupních bodů odkud má Webpack začít tvořit graf závislostí. Následně se specifikuje výstupní bod jímž bude výsledný balíček. Dále jsou zde definovány Loadery, které mají za úkol zpracovat konkrétní typy souborů a přeložit či upravit jejich obsah do formy, kterou zvládne zpracovat webový prohlížeč. Mezi tyto Loadery patří například Babel, který překládá JSX nebo pozdější verze ECMAScrip- tu do ES5, se kterým si prohlížeče poradí. V neposlední řadě jsou zde defi- novány také pluginy, které dokáží například zkomprimovat všechny JavaScriptové soubory než se odešlou prohlížečí, což aplikaci také urychlí.

1.11 Angular

Zvažovanou alternativou pro React byl právě Angular a proto by bylo dobré o něm něco také říci. Jak popisuje TJ VanToll [7], Angular začal jako ve- dlejší projekt v roce 2009, na kterém pracovali Miško Hevery a Adam Abrons. Projekt měl pomoci webovým vývojářům, ale i designérům s tvor- bou webových aplikací pomocí HTML. Nápad byl takový, že by právě třeba designéři mohli, s pomocí malého množství extra HTML, například vytvořit

37

formulář, který by se odesílal e-mailem. Miško během práce pro Google přesvědčil manažera o efektivitě tohoto projektu, což později vedlo k vydání Angularu pro veřejnost jako opensource projekt, jehož popularita velmi rychle rostla.

Angular je na rozdíl od Reactu, který je pouze knihovnou, celým JavaScrip- tovým frameworkem, který pomáhá vývojářům stavět webové aplikace.

Značně zjednodušuje implementaci komplexních požadavků moderních aplikací, mezi které patří data binding, směrování a animace. Zároveň po- skytuje řadu konvencí pro přístup k vývoji aplikací, které mohou být velice užitečné pro velké vývojařské týmy, které potřebují spolupracovat na stej- ném kódovém základu.

Využití Angularu je vhodné pro mnoho případů, ale především vyniká při tvorbě netriviálních aplikací obsahujících data. Pracuje dobře s aplikacemi, které jsou založené na formulářích a zároveň se hodí pro velké, komplexní aplikace. Není to však nejjednodušší, ani nejmenší JavaScriptový frame- work, proto se nejedná o jasnou volbu, ale je potřeba pečlivě zvážit, zda se vyplatí tento framework naučit používat a následně jej využít.

38

2 Návrh řešení

2.1 Příprava

Primárním úkolem v rámci této práce bylo vytvoření vhodného Front Endu pro vizualizaci dat přijímaných z cloudu. V rámci rešerše byly porovnány možné cesty, kterými bylo možné se vydat k řešení.

Aby bylo možné vytvářet a testovat aplikační Front End, bylo zapotřebí pro tyto, především testovací účely, také pracovat s ostatními aplikačními vrst- vami, mezi které patří Back End a databáze.

Databází, která byla na lokálním stroji nainstalována pro testování, byla MongoDB. Tato nerelační databáze byla stažena přímo z webu na adrese www.mongodb.com. Krom toho je na tomto webu k dispozici také doku- mentace, která byla zapotřebí pro seznámení se s použitím této databáze.

Jako vhodným doplňkem se ukázal být MongoDB Compass, který umožňu- je sledovat a analyzovat obsah dat v kolekcích a také provádět dotazy bez nutnosti velké znalosti dotazové syntaxe MongoDB.

Pro Back End byl zvolen Node.js, který poskytuje běhové prostředí napsané v JavaScriptu. S Node.js přichází také užitečný balíčkovací nástroj „node package manager“ (zkráceně npm), využívaný pro snadnou instalaci kniho- ven do aplikace.

Prvním využitím „npm“ byla instalace pružného frameworku pro vytváření webových aplikací s Node.js, nesoucí název Express.js nebo pouze Express.

Tento framework umožnil vytváření middlware a směrovací tabulky, díky které lze jednoduše provádět různé akce na základě metody v HTTP reques- tu a URL.

Velmi užitečnou knihovnou, která byla použita pro zastání funkce modelů v rámci MVC architektury, je Mongoose. Především Mongoose byla použita pro komunikaci serveru s databází a vytváření modelů.

39

2.2 Front End

Pro vyšší efektivitu při psaní Front Endu v Reactu, byly do aplikace přidány knihovny Webpack a Babel. S jejich pomocí je možné používat moduly, JSX, ES6 a některé pokročilé vlastnosti. Lze také použít různé loadery pro nahrání css post-processorů jako je Sass anebo optimalizovat kód, se kterým bude prohlížeč pracovat. V podstatě tyto nástroje přeloží napsaný kód do podoby, se kterou budou prohlížeče schopny pracovat. Webpack sloučí všechny moduly v aplikaci v jediný svazek, který bude prohlížeči předán.

Webpack se použije jako middleware, který se předá Express aplikaci spo- lečně se svou konfigurací. V této konfiguraci jsou specifikovány parametry, které Webpack potřebuje, aby věděl, jak se má chovat. Právě zde je mezi

„loadery“ uveden Babel, starající se o překlad JSX, který je hojně využíván v Reactu, do JavaScriptu.

S webpackem také přichází možnost takzvaného hot realoadingu při vývoji, což je další middleware, který způsobí, že se při změně kódu nechá znovu vytvořit svazek s aktuálním kódem a aplikace se sama okamžitě aktualizuje i v prohlížeči. Při vývoji se jedná o velice užitečnou vlastnost.

2.3 Vývojové prostředí

Pro každou aplikace je potřeba vybírat vhodné vývojové prostředí, které programátorovi usnadní práci s kódem a zvýší jeho přehlednost. Vzhledem k rozhodnutí, že se v této práci bude pracovat s Reactem, který používá kromě standardního JavaScriptu také JSX, byl zapotřebí vybrat takový edi- tor, který dokáže JSX rozpoznat a správně s ním pracovat. Volba nakonec padla na Sublime Text, do něhož byl nainstalován doplněk právě pro práci s JSX. S pomocí tohoto editoru se nechala napsat zároveň serverová část pro vývoj.

2.4 CRUD operace

Aplikace, která obsahuje uživatelská oprávnění, zobrazuje data uložena v databázi nebo je nějakým způsobem modifikuje, bude nějakým způsobem komunikovat se serverem a požadovat provedení určitých CRUD operací.

40 Standardním způsobem pro odesílání requestů serveru bez toho, aby bylo zapotřebí znovu načítat stránku, je použití objektu XMLHttpRequest (XHR).

V této aplikaci byl však zvolen trochu jiný způsob pro provádění takových asynchronních requestů. V první fázi vývoje se pracovalo s JavaScriptovým Fetch API. Hlavním rozdílem mezi Fetch API a XMLHttpRequestem je ten, že Fetch API používá Promises, což nabízí jednodušší a čístší API na rozdíl od komplexního API u XHR.

2.4.1 Promises

V JavaScriptu, který je jednovláknový, což znamená, že dvě části scriptu nemohou běžet zároveň, vznikly způsoby, jak toto omezení řešit. Nejběžněj- ším způsobem je použití eventů a callback funkcí. K zachycení eventů slou- ží event listener, jenomže může nastat situace, kdy k eventu dojde dříve, než je vůbec event listener aktivní. Pro takové případy jsou tu promises.

Promises jsou velice podobné event listenerům s tím rozdílem, že promise může projít nebo selhat pouze jednou. A pokud je callback, který má být volán při úspěchu či neúspěchu, přidán později, poté co již promise prošel nebo selhal, bude správný callback přesto zavolán. Toto je užitečné, protože většinou není důležité, kdy přesně bylo něco k dispozici, ale mnohem důle- žitější je samotná reakce na tento fakt.

2.4.2 Fetch API

Jak už bylo řečeno, Fetch API používá promises, což přináší mimo jiné tu výhodu, že je možné tyto promises zřetězit. Jednotlivé requesty si tak mo- hou snadno předávat logiku. Při práci s JSON daty, je však zapotřebí pro- vést dva kroky. Nejdříve provést daný request a následně zavolat metodu pro parsování JSONu, která se použije na obsah odpovědi serveru. To by ještě nebyl takový problém, ale Fetch API v některých situacích nevhodně zpracovává chybové odpovědi serveru. Brzy byl tento problém objeven, když při odpovědi se statusem 400, což je chybový kód, byl spuštěn blok kódu, který měl reagovat na kladnou odpověď serveru.

41

Při hledání řešení tohoto problému bylo objeveno jednoduché řešení, a tím byl Axios.

2.4.3 Axios

Axios, podobně jako Fetch API, posílá asynchronní HTTP requesty a je také založen na promises. Instalace tohoto modulu se však ukázala být spásou, neboť Axios vyřešil problém se špatným vyhodnocováním serverových od- povědí a zároveň usnadnil práci s daty, kdy mohl být vynechán krok parso- vání odpovědi do JSONu.

2.5 Uživatelská registrace a přihlašování

Součástí zadání této práce bylo mimo jiné vytvoření vhodného systému uži- vatelských registrací a následného ověřování a přihlašování registrovaných uživatelů. Pro tento problém bylo zapotřebí zvolit vhodnou knihovnu, v tomto případě Redux, který velmi dobře pracuje v kombinaci s Reactem.

Redux umožňuje snadno udržovat stav aplikace a pomáhá vývojáři lépe ovládat, jak bude aplikace reagovat na uživatelské akce. Používá koncept jednosměrného toku dat. Tento koncept obsahuje následující:

 Aplikace má centrální/kořenový stav

 Změna stavu spouští aktualizaci pohledu

 Pouze speciální funkce mohou měnit stav

 Takové speciální funkce jsou spouštěny uživatelskými akcemi

 Může se odehrát pouze jedna změna v jeden čas

Tato pravidla například znamenají, že centrální stav nemůže spustit žádné další akce, protože pouze vstup od uživatele může spustit další akci. Díky tomu je stav aplikace mnohem lépe udržovatelný a snižuje se tím riziko vzniku nekonečných smyček.

Princip je takový, že konkrétní uživatelský vstup jako je například odeslání registračního formuláře, znamená akci, která řekne funkci (taková funkce se v Reduxu nazývá reducer), která zajistí aktualizaci stavu. Každá taková ak- ce, řekne reduceru aby nahradil existující stav novou verzí. Tyto akce zůstá- vají zaznamenány, což přidává možnosti například při debugovaní aplikace.

42 Stav aplikace je uchováván ve stromovém objektu v jediném úložišti, který se nazývá store. Skrze tento store dostává aplikace přístup k mnoha užiteč- ným metodám. Lze zavolat metodu na získání současného stavu, odeslání akce (action dispatch), která aktualizuje stav, nebo subscribe metodu, do níž lze vložit další metody, které budou automaticky volány při změně stavu.

Akce v Reduxu je čistý JavaScriptový objekt, který vždy obsahuje typ (ty- pe) a potom užitečná data související s danou akcí.

Reducer je funkce, která pracuje s odeslanou akcí a ví, co má dělat s daty, které tato akce obsahuje. Přijímá na vstupu současný stav a akci, potom vra- cí na výstup nový stav.

2.6 Interaktivní mapa

Součástí zadání je zainkludování interaktivní mapy do webové aplikace. Pro tento úkol bylo nutné vybrat vhodnou knihovnu, která bude k dispozici bez nutnosti zakoupení licence.

2.6.1 Google map

Společnost Google poskytuje JavaScriptové API, umožňující vývojářům nejen využívat Google mapy, ale zároveň je upravovat pro podle svých po- třeb pro své aplikace, ať už webové nebo mobilní. Google maps JavaScript API nabízí čtyři základní typy mapy (roadmap, satellite, hybrid a terrain), které lze modifikovat použitím vrstev, stylů, ovládacích prvků, eventů a dalšími službami nebo knihovnami. Mapy od společnosti Google jsou v současné době zdaleka nejpopulárnější volbou.

2.6.2 Mapbox

Alternativou ke Google mapám je například Mapbox. Klíčovou výhodou oproti Google mapám a další konkurenci je velká pozornost na tvorbu map.

Mapbox pro tento účel poskytuje výborně navržený interface, který nejen dobře vypadá, ale je zároveň velice praktický. Při vytváření nové mapy vy- bírá uživatel design. Pokud nevyžaduje nic extra, může zachovat jeden ze základních návrhů, mezi něž patří:

 Street

 Terrain

43

 Satellite

Mapování jako takové poskytuje OpenStreetMap, což je kolaborační pro- jekt, který si dal za úkol vytvořit editovatelnou mapu světa, která je zároveň zdarma. Tato mapa je přesná i detailní, ačkoli postrádá například mnoho zajímavých bodů (points of interest), které má k dispozici Google.

Pro tento projekt bylo vybráno API od společnosti Google, protože nebylo zapotřebí vytvářet mapu se speciálním designem a zároveň Google poskytu- je dobrou dokumentaci k jeho API a jeho použití není nikterak složité.

44

3 Řešení

3.1 Vývoj aplikace

3.1.1 Směrování (Routing)

Ke směrování, které se týká pouze navigace v rámci aplikace, byla použita knihovna React Router, která poskytuje vytvoření takzvaného dynamického směrování na rozdíl od běžného statického směrování. Statické směrování znamená, že cesty jsou deklarovány při inicializaci aplikace, ještě před ja- kýmkoli vykreslováním, zatímco dynamické směrování vzniká až během vykreslování aplikace. To také znamená, že takřka vše v React Routeru je komponentou.

Menu pro orientaci v aplikaci bylo vytvořeno coby komponenta s názvem Header, protože se jedná o jakési záhlaví, které zůstává k dispozici pro uži- vatele bez ohledu na obsah konkrétní cesty.

Nadefinované cesty se byly předány kořenové komponentě, která obsahuje právě i zmíněnou komponentu s nabídkou, která se na tyto cesty bude odka- zovat.

To, které položky uživatel v menu uvidí, záleží na tom, zda je či není aktu- álně přihlášen v aplikaci.

3.1.2 Registrace

Pro registraci uživatelů byla napsána komponenta obsahující formulář. Tato komponenta potřebuje pracovat se stavem(state), proto byla napsána jako třída. Formulář obsahuje následující položky:

 Username

 Password

 Password confirmation

45

Obrázek 1: Registrační formulář

Jedná se tedy o jednoduchý formulář, ve kterém jsou uživatelské vstupy ověřovány. Při odeslání formuláře se nechá ověřit, zda byly vstupy v první řadě vůbec zadány a zda se zadané heslo shoduje s jeho konfirmací.

Pokud vstupy projdou touto fází ověření, nechá se odeslat request serveru, na jehož straně se dále ověřuje, zda zadaný uživatel již neexistuje v databázi. Projde-li ověření vstupů i na serverové straně bez chyb, potom je nový uživatel zaregistrován a uložen v databázi.

Šifrování uživatelských hesel probíhá na serveru pomocí hashovací funkce bcrypt od Nielse Provose a Davida Maziérese, která je založena na šifře Blowfish. Tato hashovací funkce přidává do šifrování takzvanou sůl(salt), nebo-li náhodná data, která pomáhají chránit hesla proti slovníkovým úto- kům a rainbow table útoku.

3.1.3 Přihlášení uživatele

Uživatel musí pochopitelně mít možnost po registraci se také v aplikaci při- hlásit. Pro tento účel vznikla další komponenta s formulářem, fungující na podobném principu jako registrační formulář.

46

Obrázek 2: Přihlašovací formulář

Od uživatele se očekává vyplnění kolonek Username a Password a následné odeslání formuláře. Než je tedy formulář odeslán pro zpracování na server, zkontroluje se, zda nejsou vstupy prázdné. Jakmile request dorazí na server, nechá se zjistit, zda uživatelské jméno je v databázi a pokud ano, zjistí se také, zda se shoduje hash zadaného hesla s tím, které je uloženo v databázi společně s daným uživatelským jménem.

Neshodují-li se vstupní údaje s daty uloženými v databázi, vrátí server od- pověď s chybovým statusem a uživateli se nechá zobrazit patřičná hláška.

Z bezpečnostních důvodů se v této hlášce neuvádí, zda se jedná o chybné uživatelské jméno nebo heslo.

Obrázek 3: Hláška oznamující neúspěšné přihlášení

Pokud vše proběhne jak má, nechá se na serveru vygenerovat JSON Web Token z přihlašovacích údajů, který je podepsán speciálním klíčem, s jehož pomocí jsou server i klient schopni verifikovat legitimitu tokenu. Tento to- ken se odešle společně s odpovědí prohlížeči. Token se umístí do všech ná- sledujících klientských requestů mezi hlavičky, což zaručí, že aplikace bude vědět o tom, že její uživatel je autentizován, což ovlivní, jaký obsah bude mít uživatel k dispozici.

47

3.1.4 Zobrazení dat regulátoru teplného čerpadla

Přihlášený uživatel získá v nabídce přístup k sekci, ve které jsou zobrazeny živá data přenášená přes websocketové spojení, týkající se stavu tepelného čerpadla a jeho parametrů.

V záhlaví komponenty nazvané Monitoring je uživateli k dispozici další nabídka sekcí, mezi nimiž má uživatel možnost přepínat pro zobrazení růz- ných dat.

V sekci Teploty jsou do řádků zobrazeny jednotlivé údaje o současných teplotách, které server aplikaci poskytuje.

K získávání aktuálních informací uložených na serveru se nechá v komponentě napsat výchozí „prop“ obsahující zprávu ve formátu JSON, kterou klient odešle přes websocketové spojení na server, který tuto zprávu zpracuje a vrátí data.

Po vykreslení komponenty se nadefinuje chování, jak má aplikace reagovat na příchozí zprávu od serveru. V tomhle případě se nechá zavolat funkce, která přijatá data vyparsuje a uloží ve vhodném formátu do „state“ neboli stavu komponenty. Změna state způsobí, že se komponenta překreslí, aby uživatel mohl vidět aktuální data.

Zpráva dotazující se na data se nechá serveru posílat pomocí časovače kaž- dou sekundu. Tohoto časovače je potřeba se zbavit při mazání komponenty.

3.1.5 Mapa

Pro zavedení interaktivní mapy bylo vybráno Google Maps JavaScript API.

Implementace interaktivní mapy v této aplikaci by měla sloužit k tomu, aby uživatelé mohli sledovat měnící se údaje také v závislosti na tom, odkud přicházejí. Server poskytne informaci o tom, kam údaje patří v podobě sou- řadnic, s nimiž bude mapa pracovat.

Vhodnou volbou při řešení toho problému se ukázala být knihovna react- google-maps z GitHub repozitáře tomchentw. Tato knihovna poskytuje sadu React komponent obalující Google Maps JavaScript API v3. Zároveň k této knihovně byla napsána velmi dobrá a užitečná dokumentace.