Фронт-енд и посебно ЈаваСцрипт су чудан свет. Количину нових ствари које се свакодневно уводе често исмевају људи који не раде са њима, а многи то раде. Ипак, понекад смо помало затрпани новим информацијама, библиотекама и дискусијама и желели бисмо нешто стабилно, попут сигурног уточишта за бродове на којима бисмо могли да останемо мало дуже. Касније се чини да је Реацт ова послушна лука у мору динамичне еволуције ЈаваСцрипт-а.
Имајући то на уму, одлучили смо да произведемо овај вишеделни водич за Реацт, како бисмо приказали његове могућности и видели како се пореди са Ангулар-ом и ВуеЈС-ом.
Наравно, Реацт није једина лука коју можемо користити, али тренутно је једно од најпопуларнијих, најстабилнијих и најиновативнијих решења, и иако још увек има много надоградњи, они су више опција за побољшање него него потреба за функцијом.
Реагуј је библиотека погледа до које можемо пратити већ 2011. године, када се њен први прототип, назван ФакЈс, појавио на његовој Фацебоок страници, а сам Реацт је представио Јордан Валке (који је такође аутор поменутог прототипа) у ЈСЦонфУС у мају 29. и 2013. године је отворено доступна на ГитХуб-у 2. јула 2013.
Реацт је наставио да стиче популарност 2014. године, када су почеле да се појављују конференције за ширење заједнице и популаризацију Реацт-а. Из моје перспективе, међутим, 2015. је била прекретница за Реацт - велике компаније (нпр. Аирбнб и Нетфлик) почеле су да воле и усвајају Реагујте решења . Такође, Реацт Нативе појавила се те године. Идеја која стоји иза Реацт Нативе-а није била нешто сасвим ново, али било је занимљиво за гледати, поготово јер је иза ње био Фацебоок.
Још једна велика промена била је Редук , имплементација Флук-а. Ово је начин управљања државом учинило приступачнијим и лакшим, чинећи ово најуспешнијом применом до сада.
Од тада до данас, постало је доступно много других ствари, укључујући Реагујте алате , преписивање основног алгоритма, Фибер, промена семантичког верзирања итд. Премотавајући унапред до данас, кренули смо са 16.6.3, вероватно неколико недеља пре него што нова верзија са Хоокс-ом постане доступна (требало је да буде 16.7.0, али та је већ објављена због неких исправки за Реацт.лази). Реацт је добро познат и стабилан и добија сјајна мишљења.
Па, ако сте фронт-енд програмер и још нисте чули за то, онда морам да кажем да су честитке у реду, јер је то поприличан подвиг.
Шалу на страну, Реацт је декларативна библиотека погледа заснована на компонентама која вам помаже да направите кориснички интерфејс. То је библиотека, а не оквир, мада су је у почетку многи људи описивали као потоњу.
Очигледно је да, ако ћемо додати Редук, Реацт Роутер, и тако даље, он почиње да има све потребне ствари за израду редовне апликације на једној страници, што би могао бити разлог зашто је понекад погрешно окарактерисана као оквир, а не као библиотека . Ако било шта друго, могло би се тврдити да, са свим компонентама тог окружења, термин „оквир“ донекле одговара, али Реацт је само по себи библиотека.
Зауставимо се на номенклатури и фокусирајмо се на оно што је различито у Реацт-у, на ствари које нисмо имали пре његовог настанка. Пре свега, кад први пут помислите на Реацт, мислите ЈСКС , јер је то прва ствар која вам се укаже кад погледате код. ЈСКС је ЈаваСцрипт синтаксно проширење које помало личи на ХТМЛ / КСМЛ. Када је реч о Реацт-у и ЈСКС-у, имамо неколико разлика од ХТМЛ-а, нпр. Класа у Реацт-у је className
, не постоји табиндек, али tabIndex
, стил прихвата ЈаваСцрипт објекте који имају цамелЦасед својства, и тако даље.
Постоје неке мање разлике, али свако би их зачас требао покупити. Обрада догађаја се обавља, на пример, onChange
и onClick
атрибути који се могу користити за придруживање неке функције за руковање догађајима. Такође, компоненте се касније могу слободно поново користити и прилагодити коришћењем реквизита, тако да нема разлога да исти код пишете неколико пута.
import React, { Component } from 'react'; export default class App extends Component { render() { return ( Hello World, {this.props.name} ); } }
Међутим, ЈСКС заправо није апсолутно неопходан у Реацт-у. Можете да напишете уобичајене функције за креирање елемената без употребе ЈСКС-а. Исти код који је горе, може се користити као доле.
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.createElement
. Дакле, ако не увеземо Реацт, он ће нам једноставно пропасти. Споменуо сам Бабел, који је алат који нам помаже да представимо ствари које још увек нису у ЈаваСцрипт-у (или тачније у прегледачима) или су некако његова проширења (или различите језике попут ТипеСцрипт-а, који Бабел подржава из Бабел-а 7). Захваљујући Бабел-у:
Укратко, сутра је данас у ЈаваСцрипт-у; ово је вероватно нешто што би захтевало сопствени чланак. Вреди напоменути да увоз Реацт-а могу заобићи и неке друге технике (попут увођења ПровидеПлугин-а путем Вебпацк-а и тако даље), али због ограниченог простора овде, ми ћемо га избећи и претпоставити да ће корисник користити Цреате Реацт Апп ( ЦРА) (више о овом алату биће поменуто касније).
Друга важна ствар, и далеко важнија од самог ЈСКС-а, је та да је Реацт заснован на виртуелном ДОМ-у. Укратко, виртуелни ДОМ је меморија идеалног стабла које представља ЈаваСцрипт који програмер пише, а које се касније упоређује са стварним ДОМ-ом и синхронизује се с њим у процесу који се назива помирење.
Прилично ми се не свиђа да упоређујем библиотеке, посебно када смо приморани да упоређујемо крушке са јабукама ( библиотеке наспрам оквира и тако даље).
Стога ћу покушати да упоредим Реацт са Угаона и Поглед користећи низ кратких питања и одговора који немају много везе са техничким стварима, уместо да кажу нешто слично „Кс је бољи од И јер користи ЈСКС, а не шаблоне.“ Тачке попут ове обично су личне преференције, нечији субјективни избор. Такође су брзина, додељивање меморије итд. Прилично слични у Реацт-у и свим његовим главним конкурентима (Ангулар и Вуе им падају на памет). Постоји стварно добар извештај по том питању , али имајте ово на уму: Велика већина апликација не изгледа као заиста велике табеле које замењују редове у 10к табели. Стога су и ови резултати чисти експеримент брзине. У стварном свету уопште не бисте учинили тако нешто.
Па, погледајмо неколико питања која се односе на Реацт и како се он упоређује са конкуренцијом:
Желим да имам пуно могућности за посао. Колико је популаран Реацт?
Па, на то је лако одговорити - изаберите Реагуј. Заправо, рекао бих да Реацт има отприлике 6-10 пута (прилично велико ширење, али постоје неки портали где је 1:50, а неки где је 1: 6) више отворених радних места него Вуе и 2-4 пута више од Угаоне. Потражња за Реагујте стручњаци је јак, па зашто је Вуе толико популаран на ГитХуб-у (у ствари има више звезда него Реацт), а има мање отворених радних места? Немам појма.
Желим велику заједницу, мноштво библиотека, брза решења за проблеме који могу настати.
Реагуј. Гледати на будућност.
Да ли је једноставан за употребу и чини ли развој пријатним?
Још једном, према извештајима Стате оф ЈС за 2018. и 2017. годину, и Реацт и Вуе уживају заиста добру репутацију и већина програмера каже да би их поново користили. С друге стране, Ангулар има тенденцију да из године у годину шаље све више људи који кажу да би не искористите га поново.
Желим да направим нову апликацију на једној страници, али не желим да тражим библиотеке.
То је вероватно једино место где бих рекао да је Ангулар бољи избор.
Нема великих корпорација. Желим да будем што независнији, шта да одаберем?
Вуе - једини је независни у нашем великом тројку. (Фацебоок подржава Реацт, док Гоогле стоји иза Ангулар-а.)
Најлакши почетак и најбржа крива учења?
Вуе / Реагуј. Овде се нагињем Вуеу, али то је само моје лично мишљење.
Зашто? Јер не требате ни знати ЈСКС (није обавезан), а у основи је то само ХТМЛ + ЦСС + ЈаваСцрипт.
Најлакши начин да започнете са Реацт-ом данас је употреба ЦРА, ЦЛИ алата који креира пројекат за вас и помаже вам да избегнете сва потребна подешавања за Вебпацк / Бабел и још више. Уместо тога, ослањате се на то како је подразумевано конфигурисано и шта је временом укључено у њега. Захваљујући томе, не требате бринути о главним исправкама за неке критичне библиотеке.
Наравно, касније можете сами да се „избаците“ и самостално рукујете сваким аспектом покретањем npm run eject
. Овај приступ има своје јаке стране, јер апликацију можете побољшати стварима које иначе не би биле доступне (нпр. Декоратори), али такође може бити извор главобоље јер захтева много додатних датотека и много више времена.
Дакле, прво што треба урадити је:
npx create-react-app {app-name}
Тада npm run start
и спремни сте за полазак.
Требало би да почнемо објашњавањем како се ове компоненте разликују. У основи, свака компонента може бити а функцију или класа . Главна разлика између њих је та што класа има неке функције које су недоступне у компоненти функције: могу да имају стање и користе реф, животни циклус итд. То је тренутно стање игре, а од верзије 16.7 (или како год хоће бити позван због већ поменутих промена), имаћемо и куке, па ће стање и реф бити могући са кукама.
Постоје две врсте компонената класе: Component
и PureComponent
. Једина разлика између њих је PureComponent
ради плитко поређење реквизита и стања - има своје користи у ситуацији када не желите да правите „расипане“ рендере, када су компонента и њена деца у потпуно истом стању након рендера. Ипак, то је само плитко поређење; ако желите да примените сопствено поређење (нпр. јер пролазите сложени реквизити), само користите Component
и замени shouldComponentUpdate
(који по дефаулту враћа труе). Од 16.6+, нешто слично је доступно и са функцијским компонентама - захваљујући React.memo
која је компонента вишег реда и подразумевано се понаша као PureComponent
(плитко поређење), али потребан је други аргумент где можете проследити своје прилагођено поређење реквизита.
Као опште правило, ако можете да користите функцијску компоненту (не требају вам функције класе), онда је користите. Ускоро, почев од 16.7.0, коришћење компонената класе биће потребно само због метода животног циклуса. Склон сам веровању да су функционалне компоненте транспарентније, лакше их је расуђивати и разумети.
Конструктор (реквизити)
цомпонентДидМоунт ()
setState
овде (али учинит ће да се компонента поново прикаже).цомпонентВиллУнмоунт ()
setState
, јер је бесмислено јер ће компонента бити демонтирана (и добићете упозорење).цомпонентДидУпдате (превПропс, превСтате, снапсхот)
getSnapshotBeforeUpdate
).shouldComponentUpdate
враћа тачно.setState
овде бисте га требали чувати или ћете слетјети у бесконачну петљу.схоулдЦомпонентУпдате (нектПропс, нектСтате)
PureComponent
може се користити уместо тога ако је замењени СЦО само плитко упоређивање реквизита / стања.гетСнапсхотБефореУпдате ()
componentDidUpdate
да вратите положај свитка.цомпонентДидЦатцх (грешка, информације)
setState
, али у будућим издањима ће бити изостављен у корист статичке методе getDerivedStateFromError(error)
, која ће ажурирати стање враћањем вредности за ажурирање стања.Постоје две додатне методе које су обе статичне и споменуте су у другим објашњењима
статиц гетДериведСтатеФромЕррор (грешка)
статиц гетСнапсхотБефореУпдате (реквизити, стање)
Имајте на уму да је од данас доступно још неколико метода, али би требало да буду уклоњене у Реацт-у 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
користи се 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}
Реацт је недавно стабилизовао Цонтект АПИ (који је у Реацту био доста дуго, али је био експериментална карактеристика, упркос томе што га неке од најпопуларнијих библиотека попут Редука широко користе), што нам помаже да решимо један проблем: бушење реквизита. Бушење реквизита укратко је начин за дубоко проношење реквизита унутар структуре - нпр. То може бити нека врста теме за компоненте, локализација за одређени језик, информације о кориснику и тако даље. Пре контекста (тачније пре него што је постао неексперименталан), проучаван је преношењем на рекурзиван начин преласка са родитеља на дете до последњег листа (очигледно је постојао Редук који је такође могао да реши проблем). Имајте на уму да ова функција решава САМО бушење реквизита и није замена за ствари као што су Редук или Мобк. Очигледно је, ако сте само за то користили државну библиотеку за управљање, онда је можете слободно заменити.
Овим је завршен први део нашег Реацт водича. У наредним чланцима надамо се да ћемо се позабавити напреднијим темама, почев од стилова и провера типова, до примене производње и оптимизације перформанси.
Повезан: Одржавајте контролу: Водич за Вебпацк анд Реацт, Пт. 1Реацт је декларативна библиотека погледа која потиче од Фацебоок-а и стекла је популарност током последњих неколико година. Вештине усавршене у веб верзији такође се лако могу превести у матичну верзију за мобилне апликације, тј. Реацт Нативе.
Укратко, ако сте фронт-енд програмер и желите да имате пуно могућности за посао, онда бисте требали научити Реацт. Није само Реацт популаран, већ је и једноставан и забаван за рад.
Рекао бих да је Реацт прилично лако научити, али треба неко време да се човек заиста осети сјајно док га користи. ЈСКС је такође лако разумљив, па би у почетку требао представљати велики проблем.