- Аптымізацыя Рэагаваць з самага пачатку
- Серверная візуалізацыя для SEO
- Убудаваныя стылі і імпарт CSS
- Укладзены патройны аператар
- Закрыццё ў рэакцыі
- выснову
На дадзены момант складана сцвярджаць, што React з'яўляецца адной з самых любімых бібліятэк на планеце. React выклікае вялікую цікавасць і новыя распрацоўшчыкі знаходзяцца пад уплывам першага карыстацкага інтэрфейсу. І хоць і бібліятэка, і ўся экасістэма React выраслі на працягу многіх гадоў, ёсць пэўныя выпадкі, калі вы задаеце пытанне: "Які правільны спосаб гэта зрабіць?"
І гэта справядлівы пытанне - заўсёды не існуе цвёрдага «правільнага» спосабу вядзення. Насамрэч, як вы ўжо ведаеце, часам лепшыя практыкі не такія вялікія. Некаторыя з іх могуць паставіць пад пагрозу прадукцыйнасць, чытальнасць і зрабіць прадукты ў перспектыве.
У гэтым артыкуле я апішу 5 агульнапрынятых метадаў распрацоўкі, якіх можна пазбегнуць пры выкарыстанні React. Натуральна, я растлумачу, чаму я лічу гэтую практыку непазбежнай і прапаную альтэрнатыўныя падыходы, якія дазволяць вам зрабіць тое ж самае.
Аптымізацыя Рэагаваць з самага пачатку
Распрацоўшчыкі React прыклалі шмат намаганняў, каб зрабіць React хуткім і пасля кожнага новага абнаўлення былі дададзены новыя кампазіцыі. На маю думку, вы не павінны марнаваць час на аптымізацыю матэрыялаў, пакуль не ўбачыце фактычныя хіты прадукцыйнасці.
Чаму?
Лягчэй маштабаваць React у параўнанні з іншымі інтэрфейснымі платформамі, таму што вам не трэба перапісваць усе модулі, каб зрабіць усё хутчэй. Звычайным вінаватым, які выклікае праблемы з прадукцыйнасцю, з'яўляецца працэс прымірэння, які React выкарыстоўвае для абнаўлення віртуальнага DOM.
Давайце паглядзім, як React апрацоўвае рэчы пад капотам. На кожным render (), React стварае дрэва, якое складаецца з элементаў карыстацкага інтэрфейсу - ліставыя вузлы з'яўляюцца фактычнымі элементамі DOM. Калі стан ці рэквізіт абнаўляюцца, React павінен стварыць новае дрэва з мінімальнымі зменамі ў колькасці і захаваць прадказальныя.
Уявіце, што ў вас ёсць дрэва, якое выглядае наступным чынам:
Уявіце сабе, што дадатак атрымлівае новыя дадзеныя і неабходна абнавіць наступныя вузлы:
Звычайна рэакцыя заканчваецца паўторным рэндэрынгам, а не адлюстроўваецца толькі адпаведныя вузлы:
Калі стан змяняецца ў кампанентах вышэйшага парадку, усе кампаненты, якія знаходзяцца пад ім, будуць паўторна адноўлены. Гэта паводзіны па змаўчанні, і гэта добра для прыкладання малога памеру. Па меры росту прыкладання вы павінны разгледзець пытанне аб вымярэнні фактычнай эфектыўнасці з дапамогай інструментаў Chrome Profiling. Інструмент дасць вам дакладную інфармацыю пра час, выдаткаванае на непажаданыя выдачы. Калі лічбы з'яўляюцца значнымі, вы можаце аптымізаваць час аказання, дадаўшы ў ваш кампанент кручок shouldComponentUpdate.
Крук спрацоўвае перад пачаткам працэсу паўторнага рэндэрынгу і па змаўчанні вяртае true:
Калі ён вернецца true, diff алгарытм React бярэ на сябе і паўторна адлюстроўвае ўвесь падтэтр. Вы можаце пазбегнуць гэтага, дадаўшы логіку параўнання ў shouldComponentUpdate і абнавіць логіку толькі тады, калі адпаведныя рэквізіты змяніліся.
Кампанент не будзе абнаўляцца, калі змянілася любая іншая рэквізіт / стан, акрамя колеру / колькасці.
Акрамя таго, існуюць пэўныя хітрыкі аптымізацыі, якія звычайна не хапае распрацоўшчыкам, не рэагуюць, але яны ўплываюць на прадукцыйнасць прыкладання.
Я пералічыў некаторыя звычкі, якіх можна пазбегнуць:
- Несаптымізаваныя выявы - Калі вы выкарыстоўваеце дынамічныя выявы, вам трэба ўлічваць свае варыянты пры працы з выявамі. Выявы з вялізнымі памерамі файлаў могуць выклікаць ўражанне, што прыкладанне павольны. Сціскаеце выявы, перш чым націснуць іх на сервер або выкарыстоўваць дынамічнае кіраванне малюнкам замест гэтага рашэнне. Я асабіста люблю Cloudinary, каб аптымізаваць выявы рэагавання, таму што ў яго ёсць уласная бібліятэка рэагавання, але вы таксама можаце выкарыстоўваць Amazon S3 або Firebase.
- Несжатые файлы зборкі - Gzipping файлы зборкі (bundle.js) могуць паменшыць памер файла на вялікую колькасць. Вам трэба будзе ўнесці змены ў канфігурацыю вэб-сервера. Webpack мае убудовы сціску gzip, вядомы як compression-webpack-plugin , Вы можаце выкарыстоўваць гэты метад для стварэння bundle.js.gz падчас зборкі.
Серверная візуалізацыя для SEO
Хоць прыкладанні з адной старонкі дзіўныя, ёсць дзве праблемы, якія па-ранейшаму адносяцца да іх.
- Калі прыкладанне загружаецца першапачаткова, у браўзэры няма кэша JavaScript. Калі дадатак вялікае, час, якое спачатку загрузіцца, таксама будзе велізарным.
- Паколькі прыкладанне аказваецца на баку кліента, вэб-сканеры, якія выкарыстоўваюць пошукавыя сістэмы, не змогуць праіндэксаваць змесціва, згенераванае JavaScript. Пошукавыя сістэмы ўбачаць ваша прыкладанне пустым, а потым ацэньваюць вас дрэнна.
Вось дзе зручная тэхніка рэндэрынгу. У SSR змест JavaScript аказваецца з сервера першапачаткова. Пасля першапачатковага рэндэрынгу сцэнар на кліенце бярэ на сябе і працуе як звычайны SPA. Складанасць і выдаткі, звязаныя з стварэннем традыцыйнай SSR, вышэй, таму што вам трэба выкарыстоўваць сервер Node / Express.
Ёсць добрыя навіны, калі вы знаходзіцеся ў гэтым для інтарэсаў SEO, індэксы Google і скантуе змесціва JavaScript без праблем. Google фактычна пачаў абыход матэрыялаў JavaScript яшчэ ў 2016 годзе, і зараз алгарытм працуе бездакорна.
Вось вытрымка з блога Webmaster яшчэ ў кастрычніку 2015 года.
Аднак, калі вы робіце гэта, каб палепшыць першапачатковую хуткасць рэндэрынгу, вам варта паспрабаваць палегчыць рэалізацыю SSR з дапамогай бібліятэкі накшталт Next.js. Далей зэканоміць час, якое вы патрацілі б на ўстаноўку сервера Node / Express.
Убудаваныя стылі і імпарт CSS
Працуючы з React, я асабіста спрабаваў розныя ідэі стылю, каб знайсці новыя спосабы ўкаранення стыляў у кампаненты React. Традыцыйны CSS-у-CSS падыход, які існуе ўжо шмат дзесяцігоддзяў, працуе з кампанентамі React. Усе вашы табліцы стыляў будуць уключаны ў каталог стыляў, і вы можаце імпартаваць неабходны CSS у ваш кампанент.
Аднак, калі вы працуеце з кампанентамі, табліцы стыляў больш не маюць сэнсу. Хоць React заклікае вас думаць пра сваё прыкладанне з пункту гледжання кампанентаў, табліцы стыляў прымушаюць вас думаць пра яго на ўзроўні дакумента.
У працэсе аб'яднання CSS і JS-кода ў адзін файл практыкуюцца і іншыя падыходы. Стыль Inline, верагодна, самы папулярны сярод іх.
Вам больш не прыйдзецца імпартаваць CSS, але вы ахвяруеце чытальнасцю і даступнасцю. Акрамя таго, Inline Styles не падтрымлівае медыя-запыты, псеўда-класы і псеўда-элементы і адкатныя стылі. Вядома, ёсць хакі, якія дазваляюць вам зрабіць некаторыя з іх, але гэта проста не так зручна.
Вось дзе CSS-у-JSS спатрэбіцца, а Inline стылі не зусім CSS-у-JSS. Прыведзены ніжэй код дэманструе паняцце з выкарыстаннем стылявых кампанентаў.
Што бачыць браўзэр, гэта нешта накшталт гэтага:
Новы тэг <style> дадаецца ў верхняй частцы DOM і ў адрозненне ад убудаваных стыляў, тут ствараюцца фактычныя стылі CSS. Такім чынам, усё, што працуе ў CSS, працуе і ў стыльных кампанентах. Акрамя таго, гэтая тэхніка паляпшае CSS, паляпшае чытальнасць і ўпісваецца ў архітэктуру кампанентаў. У lib-стылі-кампанентаў вы таксама атрымаеце падтрымку SASS, якая была ў камплекце з lib.
Укладзены патройны аператар
Тройныя аператары карыстаюцца папулярнасцю ў React. Гэта мой аператар да стварэння ўмоўных заяваў, і ён выдатна працуе ў метадзе render (). Напрыклад, яны дапамагаюць адлюстроўваць элементы ў радку ў прыкладзе ніжэй, я выкарыстаў яго для адлюстравання статусу ўваходу.
Аднак, калі вы зноў і зноў укладваеце тройныя аператары, яны могуць стаць выродлівымі і цяжка чытаць.
Як бачыце, скарочаныя абазначэння з'яўляюцца больш кампактнымі, але яны робяць код брудным. Цяпер выявіце, калі ў вас у вашай структуры некалькі дзясяткаў і больш укладзеных паток. І гэта адбываецца нашмат часта, чым вы думаеце. Пасля таго, як вы пачынаеце працаваць з умоўнымі аператарамі, лёгка працягваць укладваць яго, і, нарэшце, вы дасягне кропкі, у якой вы вырашыце, што вам патрэбен лепшы метад для апрацоўкі умоўнага рэндэрынгу.
Але добра, што ў вас ёсць шмат альтэрнатыў, якія вы можаце выбраць. Вы можаце выкарыстаць убудовы, падобны да JSX Control, які пашырае JSX для ўключэння кампанентаў для ўмоўных аператараў і завес.
Існуе яшчэ адзін папулярны метад, які называецца iify (IIFE - выразы функцый, якія выклікаюць неадкладна). Гэта ананімная функцыя, якая выклікаецца адразу пасля іх вызначэння.
Мы абгарнулі функцыю ў пару дужак, каб зрабіць ананімную функцыю выразам функцыі. Гэты шаблон папулярны ў JavaScript па многіх прычынах. Але ў React мы можам змясціць усе аперацыі if / else у функцыю і вярнуць усё, што мы хочам зрабіць.
Вось прыклад, які дэманструе, як мы будзем выкарыстоўваць IFFE у React.
IIFE могуць паўплываць на прадукцыйнасць, але гэта не будзе нічым значным у большасці выпадкаў. Ёсць больш метадаў для выканання ўмоўных заяваў у React, і мы разгледзім гэта 8 метадаў умоўнага рэндэрынгу ў React ,
Закрыццё ў рэакцыі
Закрыццё - гэта ўнутраныя функцыі, якія маюць доступ да зменных і параметраў знешняй функцыі. Зачыненні ўсюды ў JavaScript, і вы, верагодна, выкарыстоўвалі яго, нават калі вы яшчэ не зразумелі.
Але калі вы выкарыстоўваеце закрыцця ўнутры метаду render (), гэта сапраўды дрэнна. Кожны раз, калі выводзіцца кампанент SayHi, новая ананімная функцыя ствараецца і перадаецца кампаненту "Кнопка". Хоць рэквізіты не змяніліся, <Button /> будзе вымушана паўторна адлюстроўваць. Як ужо згадвалася раней, марнаванне рэндэрынгу можа мець прамое ўплыў на прадукцыйнасць.
Замест гэтага замяніце замыканне метадам класа. Метады класа больш даступныя для чытання і адладкі.
выснову
Калі платформа вырастае, новыя шаблоны з'яўляюцца кожны дзень. Некаторыя шаблоны дапамагаюць палепшыць агульны працоўны працэс, а некаторыя іншыя маюць значныя пабочныя эфекты. Калі пабочныя эфекты паўплываюць на прадукцыйнасць вашага прыкладання або кампрамісную чытальнасць, то, напэўна, лепш знайсці ідэі. На гэтай пасадзе я разгледзеў некаторыя практыкі ў React, якіх можна пазбегнуць з-за іх недахопаў.
Як вы думаеце пра React і лепшыя практыкі ў React? Падзяліцеся імі ў каментарах.
І хоць і бібліятэка, і ўся экасістэма React выраслі на працягу многіх гадоў, ёсць пэўныя выпадкі, калі вы задаеце пытанне: "Які правільны спосаб гэта зрабіць?Чаму?
Як вы думаеце пра React і лепшыя практыкі ў React?