Front-end и по-специално JavaScript са странен свят. Количеството нови неща, които се разгръщат ежедневно, често се подиграват от хора, които не работят с тях, а много от тях го правят. И все пак понякога сме затрупани с нова информация, библиотеки и дискусии и бихме искали нещо стабилно, като безопасно убежище за кораби, където можем да останем малко по-дълго. В последно време React изглежда е това послушно пристанище в море от динамична еволюция на JavaScript.

Имайки това предвид, решихме да създадем този многостранен урок за React, за да покажем неговите възможности и да видим как се сравнява с Angular и VueJS.

Разбира се, React не е единственото пристанище, което можем да използваме, но в момента това е едно от най-популярните, стабилни и иновативни решения и въпреки че все още получава много подобрения, те са по-скоро вариант за подобрение, отколкото отколкото необходимост за функция.

Състоянието на реакция през 2019 г.

Реагирайте е библиотека с изгледи, към която можем да проследим още през 2011 г., когато първият му прототип, наречен FaxJs, се появи на страницата му във Facebook, самата React беше представена от Джордан Уолк (който също е автор на споменатия прототип) в JSConfUS на май 29, 2013 г. и беше открито достъпна в GitHub на 2 юли 2013 г.

React продължи да набира популярност през 2014 г., когато започнаха да се появяват конференции за разширяване на общността и популяризиране на React. От моя гледна точка обаче 2015 г. беше важна за React - големите компании (например Airbnb и Netflix) започнаха да харесват и да приемат Реагирайте решения . Също, React Native се появи същата година. Идеята зад React Native не беше нещо абсолютно ново, но беше интересно да се гледа, особено след като беше подкрепена от Facebook.

Друга голяма промяна беше Redux , изпълнение на Flux. Това направи начина на управление на държавата по-достъпен и по-лесен, правейки това най-успешното прилагане до момента.

Между тогава и сега станаха налични много други неща, включително Реагирайте инструменти , пренаписване на основен алгоритъм, Fiber, промяна в семантична версия и т.н. Бързо напред към днес, ние сме на 16.6.3, вероятно няколко седмици преди новата версия с Hooks да стане достъпна (трябваше да бъде 16.7.0, но тази вече е пусната поради някои поправки за React.lazy). React е добре познат и стабилен и получава страхотни мнения.

Но какво Е Реагира ли?

Е, ако сте разработчик от преден край и все още не сте чували за него, тогава трябва да кажа, че поздравленията са в ред, тъй като това е доста подвиг.

На шега настрана, React е декларативна библиотека за изгледи, базирана на компоненти, която ви помага да изградите потребителски интерфейс. Това е библиотека, а не рамка, въпреки че в началото много хора я описват като последната.

Очевидно е, че ако ще добавим Redux, React Router и т.н., той започва да има всички необходими неща, за да направи редовно приложение на една страница, което може да е причина понякога да е неправилно характеризирано като рамка, а не като библиотека . В противен случай би могло да се твърди, че с всички компоненти на тази среда заедно, терминът „рамка“ е донякъде подходящ, но сам по себе си React е просто библиотека.

Да спрем с номенклатурата и да се съсредоточим върху различното в React, върху нещата, които не сме имали преди създаването му. На първо място, когато за първи път мислите за React, вие мислите JSX , тъй като това е първото нещо, което ви се вижда, когато погледнете кода. JSX е синтаксисно разширение на JavaScript, което донякъде прилича на HTML / XML. Що се отнася до React и JSX, имаме няколко разлики от HTML, например клас в React е className, няма tabindex, но tabIndex, стилът приема JavaScript обекти, които имат свойства на camelCased, и така нататък.

Има някои малки разлики, но всеки трябва да ги вземе за нула време. Обработката на събития се извършва, например onChange и onClick атрибути, които могат да се използват за прикачване на някаква функция за обработка на събития. Също така, компонентите по-късно могат свободно да се използват повторно и да се персонализират чрез използване на реквизит, така че няма причина да пишете същия код няколко пъти.

import React, { Component } from 'react'; export default class App extends Component { render() { return ( Hello World, {this.props.name} ); } }

JSX обаче всъщност не е абсолютно необходим в React. Можете да пишете редовни функции за създаване на елементи, без да използвате JSX. Същият код, който е по-горе, може да се използва както по-долу.

import React, { Component } from 'react'; export default class App extends Component { render() { return React.createElement( 'div', null, 'Hello World, ', this.props.name ); } }

Очевидно не предлагам да използвате такъв синтаксис, въпреки че има случаи, в които може да е полезен (например, искате да въведете наистина малко нещо и не искате да променяте средата за изграждане).

Всъщност имам друга причина, поради която показах горния фрагмент. Често разработчиците не разбират защо трябва да направим следното:

import React from 'react';

Фрагментът трябва да е обяснителен. Въпреки че извличаме Component, все още се нуждаем от React, тъй като Babel се транспилира над JSX до долу React.createElement. Така че, ако не импортираме React, той просто ще се провали за нас. Споменах Babel, който е инструмент, който ни помага да въведем неща, които все още не са в JavaScript (или по-скоро в браузърите) или по някакъв начин са разширения за него (или различни езици като TypeScript, който Babel поддържа от Babel 7). Благодарение на Babel:

• JSX ще бъде превърнат във функции, които се разбират от браузъра.
• Можем да използваме нови функции, които все още не са в браузърите (например свойства на класа).
• Можем да добавим функции, които са в по-новите браузъри, но не са налице в по-старите, като същевременно поддържаме поддръжка на по-стари браузъри.

Накратко, утре е днес в JavaScript; това вероятно е нещо, което би изисквало собствена статия. Струва си да се спомене, че вносът на React може да бъде заобиколен и от някои други техники (като въвеждане на ProvidePlugin чрез Webpack и т.н.), но поради ограниченото място тук ще го избегнем и ще приемем, че потребителят ще използва потребителя Create React App ( CRA) (повече за този инструмент ще бъде споменато по-късно).

Второто важно нещо и много по-важно от самия JSX е, че React е базиран на виртуалния DOM. Накратко, виртуалният DOM е памет на идеално дърво, което е представено от JavaScript, който разработчикът пише, което се сравнява по-късно с реалния DOM и се синхронизира с него в процес, наречен помирение.

Как реагира в сравнение с Angular и Vue?

Не ми харесва да сравнявам библиотеки, особено когато сме принудени да сравняваме крушите с ябълките ( библиотеки срещу рамки и така нататък).

Затова ще се опитам да сравня React с Ъглова и Изглед използване на поредица от кратки въпроси и отговори, които нямат много общо с техническите неща, вместо да казват нещо подобно „X е по-добър от Y, защото използва JSX, а не шаблони.“ Точки като тези обикновено са лични предпочитания, нечии субективни избори. Също така скоростта, разпределението на паметта и т.н., са доста сходни в React и всички негови основни конкуренти (Angular и Vue ми идва на ум). Има наистина добър доклад по въпроса , но моля, имайте предвид това: По-голямата част от приложенията не изглеждат като наистина големи таблици, които сменят редове в 10k таблица. Следователно тези резултати също са експеримент с чиста скорост. В реалния свят не бихте направили такова нещо на първо място.

Така че нека да разгледаме някои въпроси, свързани с React и как той се сравнява с конкуренцията:

Искам да имам много възможности за работа. Колко популярен е React?

Е, това е лесно да се отговори - изберете React. Всъщност бих казал, че React има приблизително 6-10 пъти (доста голямо разпространение, но има някои портали, където е 1:50, а други, където е 1: 6) повече работни места от Vue и 2-4 пъти повече от ъглова. Търсенето за Реагирайте експерти е силен, така че защо Vue е толкова популярен в GitHub (всъщност има повече звезди, отколкото React), но има по-малко работни места? Нямам идея.

Искам голяма общност, много библиотеки, бързи решения за проблеми, които могат да възникнат.

Реагирайте. Не търсете повече.

Лесен ли е за използване и прави ли развитието приятно?

За пореден път, според отчетите на State of JS за 2018 и 2017 г., както React, така и Vue се радват на наистина добра репутация и повечето разработчици казват, че ще ги използват отново. От друга страна, Angular има тенденция да изпраща все повече хора, които казват, че биха го направили не използвайте го отново.

Искам да създам ново приложение на една страница, но не искам да търся библиотеки.

Това е може би единственото място, където бих казал, че Angular е по-добрият избор.

Няма големи корпорации. Искам да бъда максимално независим, кое да избера?

Vue - той е единственият независим в нашето голямо трио. (Facebook подкрепя React, докато Google е зад Angular.)

Най-лесният старт и най-бързата крива на обучение?

Vue / React. Тук клоня към Vue, но това е само моето лично мнение.

Защо? Тъй като не е нужно дори да знаете JSX (той не е задължителен) и всъщност е просто HTML + CSS + JavaScript.

React Tutorial: Първи стъпки в първото ви приложение

Най-лесният начин да започнете с React в наши дни е да използвате CRA, CLI инструмент, който създава проект за вас и ви помага да избегнете всички необходими настройки за Webpack / Babel и други. Вместо това разчитате на това как е конфигуриран по подразбиране и какво е включено в него с течение на времето. Благодарение на това не е нужно да се грижите за важни актуализации за някои критични библиотеки.

Разбира се, по-късно можете да се „извадите“ и да се справите сами с всеки един аспект, като стартирате npm run eject Този подход има свои силни страни, тъй като можете да подобрите приложението си с неща, които иначе биха били недостъпни (например декоратори), но също така може да бъде източник на главоболие, тъй като изисква много допълнителни файлове и много повече време.

И така, първото нещо, което трябва да направите, е:

npx create-react-app {app-name}

Тогава npm run start и сте готови да тръгнете.

Клас срещу Функция Компоненти

Трябва да започнем с обяснение как тези компоненти се различават. По принцип всеки компонент може да бъде a функция или клас . Основната разлика между тях е, че класният има някои функции, които не са налични във функционалния компонент: те могат да имат състояние и да използват refs, жизнен цикъл и т.н. Това е текущото състояние на играта и към версия 16.7 (или обаче ще да се извика поради вече споменатите промени), ще имаме и куки, така че състоянието и референциите ще бъдат възможни с куки.

Има два типа компоненти на класа: Component и PureComponent. Единствената разлика между двете е, че PureComponent прави плитко сравнение на реквизита и състоянието - той има своите предимства в ситуация, в която не искате да правите „пропилени“ рендери, когато компонент и неговите деца са в абсолютно същото състояние след рендиране. И все пак, това е само плитко сравнение; ако искате да приложите свое собствено сравнение (например, защото предавате сложни реквизити), просто използвайте Component и замени shouldComponentUpdate (което по подразбиране връща true). От 16.6+, подобно нещо се предлага и с функционалните компоненти - благодарение на React.memo което е компонент от по-висок ред и по подразбиране се държи като PureComponent (плитко сравнение), но е необходим втори аргумент, където можете да предадете собствено сравнение на реквизит.

Като общо правило, ако можете да използвате функционалния компонент (не се нуждаете от функции на класа), използвайте го. Скоро, започвайки от 16.7.0, използването на компоненти на класа ще се изисква само поради методите на жизнения цикъл. Склонен съм да вярвам, че функционалните компоненти са по-прозрачни, по-лесни за разсъждение и разбиране.

Методи за реагиране на жизнения цикъл

Конструктор (подпори)

• По избор, особено като CRA е толкова популярна, където декларациите за полета на класа за JavaScript са включени по подразбиране. Безсмислено е да декларирате дали свързвате методите си чрез функция стрелка в тялото на класа. Подобно състояние може също да бъде инициализирано като свойство на клас.
• Трябва да се използва само за инициализиране на локално състояние за обектни и свързващи методи в класове ES6.

componentDidMount ()

• Обаждайте се от Ajax тук.
• Ако имате нужда от слушатели на събития, абонаменти и други, добавете ги тук.
• Можете да използвате setState тук (но това ще накара компонента да се препредаде).

componentWillUnmount ()

• Почиства всички неща, които все още са в ход - напр. Ajax трябва да бъде прекъснат, абонаментът да бъде отписан, таймерите да бъдат изчистени и т.н.
• Не извиквайте setState, тъй като е безсмислено, защото компонентът ще бъде демонтиран (и ще получите предупреждение).

componentDidUpdate (prevProps, prevState, моментна снимка)

• Случва се, когато компонентът току-що завърши актуализирането (не се случва при първоначално изобразяване).
• Има три параметъра, които не са задължителни за използване (предишен реквизит, предишно състояние и моментна снимка, която ще се появи само ако вашият компонент изпълнява getSnapshotBeforeUpdate).
• Това се случва само ако shouldComponentUpdate връща true.
• Ако използвате setState тук трябва да го пазите или ще кацнете в безкраен цикъл.

shouldComponentUpdate (nextProps, nextState)

• Само за оптимизиране на производителността.
• Ако връща false, рендирането НЯМА да бъде извикано.
• PureComponent може да се използва вместо това, ако заменената SCO е просто плитка сравнение между подпори / състояния.

getSnapshotBeforeUpdate ()

• Може да се използва за запазване на известна информация за текущия DOM, например текуща позиция на превъртане, която по-късно може да бъде използвана повторно в рамките на componentDidUpdate за да възстановите позицията на свитъка.

componentDidCatch (грешка, информация)

• Място, където трябва да се случат грешки при регистриране.
• Може да извика setState, но в бъдещи версии ще бъде отхвърлен в полза на статичния метод getDerivedStateFromError(error), който ще актуализира състоянието чрез връщане на стойност за актуализиране на състоянието.

Има два допълнителни метода, които и двата са статични и са споменати в други обяснения

static getDerivedStateFromError (грешка)

• Информацията за грешки е достъпна тук.
• Трябва да върне стойност на обект, която ще актуализира състоянието, което може да се използва за обработка на грешки (чрез показване на нещо).
• Тъй като е статичен, той няма достъп до самия екземпляр на компонента.

статичен getSnapshotBeforeUpdate (подпори, състояние)

• Трябва да се използва в случаите, когато реквизитът се променя с течение на времето - например, според React docs, това може да е полезно за преходен компонент.
• Тъй като е статичен, той няма достъп до самия екземпляр на компонента.

Имайте предвид, че има още няколко метода, които са достъпни от днес, но те трябва да бъдат премахнати в React 17.0, така че затова не бяха споменати тук.

Държава срещу реквизит

Да започнем с Реквизит , тъй като те са по-лесни и бързи за обяснение. Реквизитите са свойства, които се предават на компонента, които по-късно могат да бъдат използвани повторно в него за показване на информация / бизнес логика и други подобни.

import React, { Component } from 'react'; export default class App extends Component { render() { return ( ); } } const HelloWorld = (props) => Hello {props.name}

В горния пример, name е опора. Реквизитите са само за четене елементи и не могат да бъдат променяни директно в дъщерни компоненти. Освен това има една лоша практика, която хората често правят, а именно копиране на реквизит до държавата и опериране на държавата след това. Разбира се, има случаи, когато искате да направите нещо като „първоначално състояние, което ще актуализира родителския компонент след подаване“, но това е по-рядко - в такъв сценарий може да има смисъл от първоначалното състояние. Също така, не само свойства като низове могат да бъдат предадени на дъщерни компоненти, но също така и числа, обекти, функции и т.н.

Реквизитите имат и още едно полезно нещо, което се нарича defaultProps, статично поле, което може да ви каже какви са реквизитите по подразбиране за компонент (когато те не се предават на компонента, например).

В случай на „повдигане на състоянието нагоре“, когато един компонент (родителят) има състояние, което по-късно се използва повторно от неговите деца (напр. Едно дете го показва, а друго позволява редактиране), тогава трябва да предадем функцията на дете от родител, което ни позволява да актуализираме местното състояние на родителя.

Щат , от друга страна, е локално състояние, което може да бъде модифицирано, но индиректно чрез this.setState. Ако някой мутира директно състоянието, компонентът няма да е наясно с промяната и няма да бъде повторно изобразен, за да отрази споменатите промени в състоянието.

SetState е метод за промяна на обект на локално състояние (чрез плитко сливане) и след това компонентът отговаря на това, като се препредаде. Имайте предвид, че след setState се използва, this.state свойството няма да отразява промените, споменати във функцията веднага (има асинхронен характер) като няколко случая на setState могат да бъдат групирани заедно поради оптимизация. Той има няколко начина да бъде извикан, когато една от тези възможности ни позволява да направим нещо с компонента веднага след актуализиране на състоянието:

• setState({value: ‘5’})
• setState((state, props) => ({value: state.name + “‘s”}))
• setState([object / function like above], () => {}) - този формуляр ни позволява да прикачим callback, който ще бъде извикан, когато състоянието ще отразява данните, които сме искали да имаме (в първия аргумент).

import React, { Component } from 'react'; export default class App extends Component { state = { name: 'Someone :)' } onClick = () => this.setState({ name: 'You' }) render() { return ( ); } } const HelloWorld = (props) => Hello {props.name}

Реагирайте контекст

React наскоро стабилизира Context API (който беше в React от доста време, но беше експериментална функция, въпреки че беше широко използван от някои от най-популярните библиотеки като Redux), което ни помага да разрешим един проблем: пробиване на подпори. Пробиването на реквизит накратко е начин за дълбоко предаване на реквизита в структурата - например, това може да бъде някаква тема за компоненти, локализация за конкретен език, потребителска информация и т.н. Преди контекстът (или по-скоро преди да стане не-експериментален), той беше пробит чрез преминаване по рекурсивен начин от родител на дете до последния лист (очевидно имаше Redux, който също можеше да реши проблема). Имайте предвид, че тази функция решава САМО пробиване на подпори и не е заместител на неща като Redux или Mobx. Очевидно е, че ако сте използвали държавна библиотека за управление само за това, тогава можете да я замените свободно.

Обобщавайки

С това завършва първата част от нашия урок React. В предстоящите статии се надяваме да се заемем с по-напреднали теми, вариращи от стилизиране и проверка на типове, до внедряване на продукция и оптимизиране на производителността.

Свързани: Поддържайте контрол: Ръководство за Webpack and React, Pt. 1

Разбиране на основите

Какво е React?

React е декларативна библиотека с изгледи, която произхожда от Facebook и придоби популярност през последните няколко години. Уменията, усъвършенствани в уеб версията, могат лесно да бъдат преведени в нейната родна версия за мобилни приложения, т.е. React Native.

Заслужава ли си да научите React?

Накратко, ако сте фронт разработчик и искате да имате много възможности за работа, тогава трябва да научите React. Не само, че React е популярен, но и е лесно и забавно да се работи с него.

Колко време отнема да научите React?

Бих казал, че React е доста лесен за научаване, но отнема известно време, преди човек наистина да се почувства страхотно, докато го използва. JSX също е лесен за разбиране, така че първоначално би трябвало да представлява голям проблем.