Html5 css3 — С чего начать написание своего блога на React.js


Содержание

Скринкаст по React.js

React.js — одна из самых популярных библиотек для создания сложных Frontend-приложений.

Однако, успешная разработка на нём требует хорошего понимания концепций, на которых он построен.

В этом скринкасте мы:

  • Познакомимся с основными понятиями и внутренним устройством React.js.
  • Разберёмся с тем, как создавать компоненты на React.js.
  • Разберём ряд подводных камней, на которые часто наступают начинающие React-разработчики.

Одна из главных особенностей React.js — свобода действий, существует огромное количество подходов к построению приложений с его помощью (redux, mobx и другие).

Они не являются частью собственно React.js, а представляют собой архитектурные надстройки и также постоянно развиваются. Мы осваиваем их на Основном и Продвинутом онлайн-курсах по React.JS.

Автор этого скринкаста – Роман Якобчук, с небольшой помощью в плане организации материала от Ильи Кантора.

Вы также можете скачать все скринкасты в виде архива с видео-файлами.

Основы React.js и вёрстки макетов сайтов на основе функциональных компонентов не имеющих состояний

React.js можно считать наилучшей альтернативой среди средств для разработки веб-интерфейсов. Разработка на React.js заключается в описании того, что нужно вывести на страницу (это называется: декларативный подход к описанию интерфейсов). Т.е. Вам всё равно — как браузер, на программном уровне, будет выводить элементы интерфейса на страницу.

При старте разработки проекта на React.js — Вам необходимо нарисовать прямоугольники вокруг каждого элемента (и под-элемента) в макете и дать им всем имена, после чего реализовать каждый элемент в отдельном компоненте React.js приложения.

Компонент может быть контейнером для нескольких под-компонентов (как на изображении выше). Но важно помнить три правила:

  • Все что возвращает компонент должно быть обернуто в один div.
  • Компонент должен решать только одну задачу и должен делать это качественно (принцип единственной ответственности — Single Responsibility Principle (SRP)).
  • Помещайте каждый компонент в отдельный файл (рекомендация для больших проектов).

Рассмотри React.js на 5-ти примерах (без использования Create React App и других инструментов) — для того, чтобы понять его основы и научится верстать макеты сайтов на React.js на основе функциональных компонентов не имеющих состояний.

Пример 1: «Hello World»

Простой пример показывающий как начать использовать React.js.

Содержимое index.html:

Пример 2: вынос React приложения из HTML в отдельный файл

Модифицируем пример 1, разделив HTML и React.js приложение.

Содержимое index.html:

Содержимое app.jsx:

Пример 3: реализация простого макета сайта на React.js

Модифицируем пример 2, изменив содержимое app.jsx, так — чтобы получилась реализация макета как на изображении в начале статьи. При этом содержимое файла: index.html — останется без изменений.

Важно, что из всех надписей на изображении в начале статьи — только заголовок статьи: Header Title не будет реализован как компонент. Так как в компоненте Header содержится только один логический блок — вывод заголовка: Header Title. Если в компоненте Header — выводилась бы ещё и информация о пользователе, то имело бы смысл заголовок статьи поместить в свой компонент, а информацию о пользователе в свой. Или же, если бы, заголовок статьи выводился минимум дважды в компоненте Header, то имело бы смысл заголовок статьи поместить в свой компонент.

Пример 4: рефакторинг макета сайта на React.js — разделение компонентов

Поместим каждый компонент в отдельный файл. Тогда содержимое index.html изменится, на:

A содержимое app.jsx изменится, на:

Пример 5: рефакторинг макета сайта на React.js — оптимизация компонентов

Если компоненты, как в последнем примере, не будут иметь состояний — то правильнее превратить их в функциональный компоненты. Ниже находится пример превращения компонента Wrapper в функциональный компонент.

9 полезных советов для тех, кто начинает знакомство с React.js

Я использую React.js уже 6 месяцев. Да, звучит, как короткий срок, но для постоянно изменяющегося мира JS-фреймворков это очень долго! Я уже давал советы новичкам, и поэтому решил, что будет хорошей идеей собрать их вместе.

Я рассчитываю, что вы разбираетесь в базовых понятиях; если слова “component”, “prop” и “state” вам не знакомы, то сперва стоит ознакомиться с официальными страничками Getting started и Tutorial. Кроме того, я буду использовать JSX, поскольку это более удобный синтаксис для написания компонентов.

1. Это просто библиотека для работы с представлениями

Сперва разберем основы. React — это не очередной MVC-фреймворк или какой-то другой фреймворк. Это просто библиотека для рендеринга ваших представлений. Если вы пришли из мира MVC, то стоит понять, что React — это только “V”, а “M” и “C” придётся поискать где-то ещё.

2. Компоненты должны быть небольшими

Звучит очевидно, не правда ли? Каждый толковый разработчик знает, что маленькие классы / модули / да что-угодно легче понять и поддерживать. Моей ошибкой в начале работы с React было то, что я не понял, насколько маленькими должны быть мои компоненты. Конечно, конечный размер будет зависеть от многих факторов, но вообще стоит делать компоненты значительно меньше, чем вы планируете изначально. В качестве примера приведу компонент, отображающий последнюю запись в моём блоге на главной странице сайта:

Сам компонент — это , с двумя


каждого элемента. Примерно такими должны быть ваши компоненты.

3. Пишите функциональные компоненты

Раньше было всего два способа определения React-компонентов, первый — это React.createClass() :

… а второй — классы ES6:

React 0.14 принёс новый синтаксис определения компонентов как функций от свойств:

Это мой самый любимый способ. Помимо более понятного синтаксиса этот подход даёт ясно понять, когда компонент стоит разделить. Рассмотрим предыдущий пример и представим, что мы его ещё не разделили:

Этот класс не так уж и плох. Мы уже вынесли пару методов из метода отрисовки и неплохо инкапсулировали саму идею рендеринга последних постов. Перепишем этот код, используя функциональный синтаксис:

В будущем React будет оптимизирован так, чтобы функциональные компоненты были более эффективными, но пока что их производительность находится под большим вопросом; я рекомендую вам ознакомиться с этим материалом для прояснения картины.

Важно отметить, что у функциональных компонент есть несколько ограничений, которые я считаю их сильными сторонами. Первое — к функциональному компоненту нельзя привязать ref . Хотя ref и является удобным способом для общения компонента со своими потомками, я считаю, что это не для функционального React, а скорее для императивного jQuery.

21 ноября, Москва, беcплатно

Второе ограничение — к функциональным компонентам нельзя прикрепить состояние, и это тоже является преиммуществом, поскольку я советую: …

4. Пишите компоненты без состояний

Стоит сказать, что больше всего боли при написании React-приложений я ощутил от компонент с обширным использованием состояния.

Состояния затрудняют тестирование

Проще всего тестировать чистые функции, так зачем портить их, добавляя состояния? После добавления состояний нам нужно привести все компоненты в нужное состояние, а также перебрать все комбинации состояний и свойств, что очень неудобно.

Состояния затрудняют понимание компонентов

Читая код компонента, насыщенного состояниями, возникает очень много вопросов: “Это состояние уже было инициализировано?”, “Что произойдёт, если я изменю это состояние здесь?”, “Где ещё изменяется это состояние?”, “Есть ли здесь состояние гонки (race condition)?” и подобных — а это лишняя головная боль.

Состояния слишком упрощают добавление бизнес-логики в компоненты

Мы не должны заниматься определением поведения компонента. Помните, React — это библиотека для работы с представлениями, и поэтому, когда в компоненте есть доступ к состоянию приложения, придётся сдерживаться от соблазна добавления в него вычислений или валидации, ведь им там не место. Кроме того, смешение логики отрисовки и бизнес-логики ещё больше усложнит тестирование.

Состояния затрудняют обмен информацией между частями приложения

Когда компонент обладает состоянием, его можно передать ниже по иерархии компонентов, но не в других направлениях.

Конечно, иногда в том, что у конкретного компонента есть полный доступ к конкретному состоянию, есть смысл, и тогда можно использовать this.setState — это вполне законная часть API React-компонентов. Например, если пользователь вводит информацию в поле, нет смысла делать каждое нажатие клавиш доступным всему приложению, поэтому достаточно будет отслеживать состояние поля самому полю, а по окончании ввода передать дальше введённое значение.

Короче говоря, будьте крайне осторожны при добавлении состояний. Когда начнёте, будет очень сложно удержаться от добавления очередной “маленькой фичи”.

5. Используйте Redux.js

В первом пункте я сказал, что React нужен лишь для работы с представлениями. Но куда же поместить все состояния и логику?

Вы наверняка слышали про Flux — SPA (style/pattern/architecture) для разработки веб-приложений, зачастую используемых с React. Существуют несколько фреймворков, реализующих идеи Flux, но я однозначно рекомендую Redux.js.

Вот краткое описание принципов работы Redux:

  1. Компоненты принимают коллбэки как свойства и вызывают их, когда происходит UI-событие;
  2. Эти коллбэки создают и отправляют действия в зависимости от события;
  3. Редюсеры обрабатывают действия, вычисляя новое состояние;
  4. Новое состояние всего приложения помещается в одно хранилище;
  5. Компоненты получают новое состояние как свойство и переотрисовывают себя при необходимости.

Большая часть вышеобозначенных признаков встречаются не только в Redux, но он предоставляет очень простую их реализацию и крошечный API. Перенеся немаленький проект с Alt.js на Redux, я выделил несколько преимуществ:

  • Редюсеры — это чистые функции, которые просто делают следующее: oldState + action = newState . Каждый редюсер вычисляет отдельную часть состояния, которые затем объединяются. Это заметно упрощает тестирование бизнес-логики и состояний.
  • API меньше, проще и лучше задокументирован.
  • Если вы используете Redux как положено, полагаться на него будет совсем небольшое количество компонентов; остальные будут лишь получать состояния и коллбэки как свойства.

Есть ещё несколько библиотек, которые прекрасно дополняют Redux:

  • Immutable.js — неизменяемые структуры данных в JavaScript! В них стоит хранить состояния, чтобы они случайно не изменились.
  • redux-thunk — она используется, когда помимо изменения состояния должен возникнуть ещё какой-то “побочный эффект”.
  • reselect — используйте её для создания компонуемых представлений.

6. Всегда используйте propTypes

propTypes предоставляют нам очень простой способ повышения безопасности наших компонентов. Они выглядят так:

В процессе разработки, если какому-то компоненту не будет передано нужное свойство или свойство иного типа, React создаст лог ошибки. Преимущества:


  • Можно заранее ловить баги;
  • Если вы используете isRequired , вам не нужно проверять на undefined или null ;
  • Решается вопрос документирования.

Хотя это и выглядит как агитация за статическую типизацию, это не так. Я предпочитаю динамические типы за их простоту, но propTypes дополнительно повышают безопасность компонентов, поэтому я не вижу причин их не использовать.

Также стоит настроить тесты на провал при столкновении с ошибками propType. Это просто и работает:

7. Используйте неглубокий рендеринг

Тестирование React-компонентов может быть непростым, поскольку эта тема всё ещё развивается, и нет однозначно лучшего подхода. На данный момент я предпочитаю использовать неглубокий рендеринг (shallow rendering) и подтверждение свойств (prop assertions).

Неглубокий рендеринг удобен тем, что он позволяет полностью выводить один компонент, не затрагивая никаких потомков. Вместо этого возвращаемый объект сообщит типы и свойства потомков.

Чаще всего я пишу три типа юнит-тестов компонентов:

Логика отрисовки

Представьте компонент, который должен по условию отрисовывать изображение или иконку загрузки:

Мы можем протестировать его так:

Элементарно! Стоит отметить, что API для неглубокого рендеринга более сложен, чем в моём примере. Функция shallowRender написана нами как обёртка API для его упрощения.

Возвращаясь к компоненту ListOfNumbers , вот как можно протестировать его корректность:

Преобразование свойств

В прошлом примере мы залезли в потомков используемого компонента, чтобы проверить, корректно ли отрисованы. Это можно расширить, если подтвердить, что потомки не только корректны, но и получили нужные свойства. Это особенно полезно, когда компонент как-то преобразовывает свойства перед их передачей. Например, рассмотрим этот компонент, который берёт имена CSS-классов в виде массива строк и передаёт их как одну строку:

Часто такой подход критикуют за props.children.props.children … Хотя такой код и не очень красив, он полезен тем, что даёт понять: если в одном тесте слишком много props.children , компонент стоит уменьшить.

Ещё одним замечанием является то, что такие тесты очень зависимы от внешней реализации компонента в том плане, что даже малейшее изменение структуры DOM ломает все тесты. С этим я согласен, но бороться с этим можно, — да-да — уменьшая размер компонентов, что снизит количество потенциально неустойчивых тестов.

Взаимодействие с пользователем

Конечно, компоненты ещё и интерактивны:

Вот мой любимый способ тестирования:

Пример тривиален, но я думаю, что вы уловили суть.

Цукерберг рекомендует:  Тест по PHP. Тест «PHP. Уровень 1»

Интеграционное тестирование

Пока что мы рассмотрели лишь юнит-тестирование, но нужны какие-то тесты более высокого уровня для тестирования всего приложения целиком. Не буду вдаваться в детали:

  1. Отрисовывайте всё дерево компонентов (вместо неглубокого рендеринга).
  2. Углубитесь в DOM (используя React TestUtils, jQuery и т.д.) для поиска самых важных элементов, и:
    • подтвердите их HTML-атрибуты или содержимое, или
    • симулируйте DOM-события и подтвердите побочные эффекты (изменения DOM или путей, AJAX-вызовы и т.д.).

8. Используйте JSX, ES6, Babel, Webpack и NPM

Единственной вещью, специфичной для react, является JSX. Его единственным недостатком является небольшое увеличение времени сборки, но это решается при помощи Babel.

Если уж мы начали использовать Babel, нет причин отказываться от использования всех функций ES6. Чувствуется, что JavaScript начинает расти как язык, учитывая, сколько времени требуется для подготовки всех инструментов.

Закончим мы использованием Webpack для бандлинга нашего кода и NPM для управления пакетами.

9. Используйте инструменты разработчиков React и Redux

Говоря об инструментах, React и Redux в этом плане очень хороши. Инструменты для React позволяют проверить отрисованное дерево элементов React, что очень удобно. Инструменты для Redux впечатляют ещё больше. Добавить их можно в виде зависимости или расширения браузера.

Создание сайта на HTML, CSS

Внимательно изучив этот раздел, вы научитесь самостоятельно создавать сайты с нуля, без всяких конструкторов и CMS, а с помощью исключительно HTML 5 и CSS 3. В дальнейшем, когда уже будете делать проекты с использованием популярных CMS, применяя полученные знания, вы сможете вмешаться в исходный код сайта, переделав оформление и структуру под свои нужды.

Курс состоит из 25 уроков. Первая его часть научит понимать и писать код HTML, вторая познакомит с каскадными таблицами стилей (CSS). Именно с этих материалов и рекомендую начать изучать сайтостроение.

Сделайте свою первую HTML-страницу, не прибегая ни к чему, кроме известного всем простейшего текстового редактора, встроенного в любую Windows — Блокнота. Но не просто сделайте, а поймите, как это работает.

Вы познакомитесь с одним из самых популярных и многофункциональных средств, призванных упростить рабочие будни верстальщикам и веб-дизайнерам — программой Adobe Dreamweaver.

Основные вопросы, мучающие новичков. Что такое HTML? Зачем он нужен? Что позволяет делать? Что лучше — HTML4 или HTML5? Все ответы — в статье.

Теги — основная единица языка HTML. Без них не обходится ни одна веб-страница. Статья познакомит вас с основными контейнерами HTML. Из неё вы узнаете, как правильно записываются теги, научитесь частично понимать HTML-код.

У тегов есть не только содержимое, но также атрибуты, которые, в свою очередь, наделены значениями. Обо всём этом и пойдёт речь в статье. Где искать атрибуты? Как правильно записывать? Какие атрибуты можно присвоить любому без исключения тегу? А ещё вы узнаете, как разрешить пользователю редактировать любой элемент страницы, как задать для каждого объекта уникальное контекстное меню и как скрыть содержимое элемента, чтобы оно не отображалось в браузере.


Всё, что связано с оформлением текста: как сделать заголовки, назначить полужирный шрифт или курсив, уменьшить/увеличить размер текста или что-нибудь процитировать. В статье вас ждёт ещё много интересных секретов форматирования текста средствами HTML. А главное — всё это показано на наглядных примерах.

Маркированные, нумерованные, вложенные — какие хотите. Также вы узнаете, как нумеровать список большими латинскими буквами или римскими цифрами, да ещё и в обратную сторону, как начинать нумерацию не с единицы и тому подобные вещи. А ещё вас ждёт знакомство с мало кому известным списком определений.

Ссылки — чуть ли не основной элемент Интернета, без которого никакой связности страниц бы и не было. Научитесь создавать ссылки на примерах, узнайте, чем относительные пути отличаются от абсолютных, познакомьтесь с внутренними и графическими ссылками, научитесь ставить их на e-mail и Skype.

Картинки украшают страницу, поэтому уметь добавлять их — навык очень полезный. А если превратить изображение в навигационную карту, то оно становится не только симпатичным, но и очень полезным элементом. Научитесь создавать такие объекты на наглядных примерах, которые есть в статье.

Внимательно изучив этот раздел, вы научитесь самостоятельно работать с таблиц. На основе таблиц когда-то создавались целые структуры сайтов, но об этом будет идти речь в следующем уроке.

Как вообще можно сверстать целый сайт? Способов есть много, один из них — делать его с помощью таблиц. О том, что представляет собой такой метод, вы и узнаете. Наглядные примеры, как всегда, присутствуют, и помогут без труда освоить табличный подход.

Статья для тех, кто хочет научиться отображать в одном HTML документе совершенно другую страницу. Вы узнаете, что такое фреймы, как они создавались раньше и как создаются сейчас, а также познакомитесь с доступными им атрибутами.

Какие основные операторы и элементы присутствуют в документе каскадных таблиц стилей, что вообще такое этот CSS, зачем он нужен и чем отличается от HTML, а главное — как связать каскадную таблицу стилей с HTML-элементом.

На примерах показано, как выровнять текст по горизонтали и вертикали, изменить отступ и междустрочный интервал, добавить подчёркивание или надчёркивание, увеличить расстояние между символами и сменить регистр.

Прочтя статью, вы поймёте принципы группировки шрифтов в CSS, узнаете, какие из них поддерживает любой браузер, научитесь менять их размер и стиль, цвет и насыщенность. Разберётесь с аббревиатурами RGB и HSL, а также узнаете, зачем к ним иногда добавляют букву A.

Читать стоит после того, как освоили ссылки в HTML, потому что эта статья научит их не создавать, а оформлять, причём задать внешний вид вы можете не только для разных ссылок, но и для одной и той же, находящейся в разных состояниях. Пусть если по ней ещё не переходили, она будет синей, если навели указатель — зелёной с подчёркнутым текстом, щёлкнули — жёлтой и полужирной, а перешли — курсивной и фиолетовой.

Всё о правильном оформлении таблиц: ширина и высота, расположение заголовка, удаление двойных границ, определение расстояний, скрытие фона и многое другое, подкреплённое живыми примерами.

А вы знали, что в качестве маркера списку можно задавать не только круг, но и окружность или даже квадрат? Да хоть произвольную картинку. А знали, что помимо стандартных нумераций можно установить, например, традиционную армянскую? А как превратить маркер из вынесенного в обтекаемый? Нет? Тогда загляните в статью, там ждёт не только теория, но и примеры.

Всё о фоне. Цвет, на фоне которого пишется текст. Картинка, на фоне которой отображается вся страница: повторяющаяся по горизонтали, по вертикали, по всем направлениям одновременно, позиционированная, масштабируемая и т. д.

Ширина границ, их стиль, цвет. Вы узнаете, как сделать вместо внутренней границы внешнюю, как её раскрасить, как добавить рамки только с двух или трёх сторон и как сделать так, чтобы слева она была пунктирной, а справа — сплошной.

Статья объяснит, в чём смысл блочной вёрстки, чем она отличается от табличной и лучше ли она. По каким принципам создаётся и в чём её суть. Но самое главное — большой пример блочной вёрстки, благодаря которому вы сможете окончательно в ней разобраться и запомните метод навсегда.

Почему нельзя обойтись только HTML/CSS? Что даёт язык PHP современным сайтам? Какие страницы называют статическими, а какие — динамическими, и что это означает? А самое основное — описание функции include() и пример её использования.

Делаем PSD-макет настоящего сайта в программе Photoshop.

В предыдущей статье мы создали макет сайта, в этой будем делать из картинки работающий шаблон с помощью изученных ранее HTML и CSS.

Хотя сайт «голыми руками» сделать можно, всё чаще для этой цели сейчас используются системы управления содержимым — CMS. О том, что это такое, как классифицируются и какие дают преимущества, какими бывают и какую CMS лучше выбрать расскажет статья.

Если вы прошли все уроки, то можете легко создать с нуля даже достаточно сложный сайт, а также разобраться в чужом коде, отрисовать и сверстать шаблон, вмешаться в тему оформления любой CMS и отредактировать её под свои нужды. С полученными знаниями вы всегда будете на шаг впереди любого веб-мастера, сразу начавшего работать с CMS и не освоившего основных инструментов веб-разработки.

Полезные ссылки:

  • Основы HTML — бесплатный 2-х часовой видеокурс по основам HTML;
  • Бесплатный курс по верстке сайта — пример блочной вёрстки с чистого листа;
  • Вёрстка сайта с нуля 2.0 — полноценный платный курс.

Стилизация и CSS

Как добавить CSS-классы в компоненты?

Передайте в проп className строку:

Обычно CSS-классы зависят от пропсов или состояния:

Если вы часто пишете похожий код, то пакет classnames поможет упростить его.

Как можно использовать встроенные стили?

Встроенные стили — это плохо?

CSS-классы, как правило, лучше для производительности, чем встроенные стили.

Что такое CSS-in-JS?

«CSS-in-JS» — это паттерн, в котором CSS-код создаётся при помощи JavaScript, вместо того, чтобы писать его во внешних файлах. Ознакомьтесь со сравнением библиотек по работе с «CSS-in-JS» в этом репозитории.

Обратите внимание, что данная функциональность не входит в React из коробки, а предоставляется сторонними библиотеками. React ничего не знает про то, как определяются стили. Если вы сомневаетесь, использовать указанный выше способ, то хорошим началом станет определение стилей в отдельном файле с расширением *.css , как вы ранее привыкли это делать, а затем указать нужные классы с помощью className .

Можно создавать анимации в React?

React может использоваться для создания крутых анимаций! В качестве примера посмотрите библиотеки React Transition Group, React Motion или React Spring.

9 принципов, которые должен знать новичок в React.js


Автор статьи: Cam Jackson . Оригинал статьи здесь . От переводчика: статья не лишена спорных или субъективных моментов, но, все же, большинство изложенных принципов достаточно полезны.

Я использую React.js с 2015 года. По большому счету, это не такой уж и большой срок, но в постоянно меняющемся мире JavaScript, этого достаточно, чтобы мнить себя умудренным старцем. Недавно я помог нескольким людям советами по началу работы с React, поэтому я подумал, что было бы неплохо опубликовать некоторые из них здесь, чтобы больше людей их увидели. Это все — принципы, которые я хотел бы знать, когда я начинал изучать React, или принципы, которые действительно помогли мне разобраться в React’e.

Я предполагаю, что вы уже знаете самые основы. Но если слова component , props , или state вам не знакомы, то вам лучше бы сначала прочитать официальные Hello World или Руководство. Также, я буду использовать JSX, потому что он предоставляет гораздо более краткий и выразительный синтаксис для написания компонентов.

1. Это просто библиотека отображения

Давайте сначала разберемся с основами. React это не очередной MVC-фреймворк или какой-либо другой фреймворк. Это всего лишь библиотека для рендеринга ваших отображений (views). Если вы пришли из мира MVC, то вам нужно осознать, что React это буква ‘V’ в этой аббревиатуре, и вы должны поискать где-нибудь в другом месте, когда дело доходит до ‘M’ и ‘C’, иначе в результате вы получите кучу дурно пахнущего React-кода. Подробнее об этом далее.

2. Делайте небольшие компоненты

Это может показаться очевидным, но это стоит того, чтобы быть упомянутым. Каждый хороший разработчик знает, что маленькие классы/модули/что угодно — легче для понимания, тестирования и поддержки. То же самое справедливо и для React-компонентов. Когда я начинал, моей ошибкой было непонимание насколько маленькими должны быть компоненты. Конечно, точный размер будет зависеть от множества факторов (в том числе личных предпочтений вас и вашей команды), но в общем, мой совет такой — делайте компоненты значительно меньше, чем они должны быть по вашему мнению. Как пример, ниже представлен компонент, который выводит последние посты блога на главной странице моего сайта:

Компонент представляет собой с двумя

для каждого элемента массива. Эта последняя часть, выдающая

как отдельный компонент — очень важна. Я считаю, что это и есть подходящий размер для компонента.

3. Пишите функциональные компоненты

Ранее было два способа объявления React-компонента, первым был — React.createClass() :

Затем появился способ, использующий классы ES6:

React 0.14 представил новый синтаксис — объявление компонентов как функций от props:

На данный момент, это мой любимый метод объявления компонентов React. Помимо более лаконичного синтаксиса, этот подход может помочь понять когда компонент нужно разделить на более мелкие. Давайте вернемся к раннему примеру с записями блога и представим, что мы еще не разделили этот компонент:

Этот класс не такой плохой, как вообще могут быть классы. Мы уже выделили пару методов из метода render() , разделив его на небольшие блоки с понятными названиями. Задача вывода кратких версий последних записей блога решена. Теперь давайте перепишем тот же самый код, используя функциональный синтаксис:

Большая часть кода не изменилась, только теперь у нас голые функции вместо методов класса. Тем не менее, для меня это большая разница. Когда компонент разбит на функции, мне субъективно проще поймать тот момент, когда этот компонент уже пора разбить на более мелкие компоненты. Таким образом, “функциональный” синтаксис помогает мне следовать пункту №2.

В будущем, также, планируются оптимизации в React, которые сделают функциональные компоненты более эффективными, чем классовые. ( Update: оказалось что изменения в производительности функциональных компонентов сложнее, чем я думал. Я все еще рекомендую использовать функциональные компоненты, но если вас сильно тревожит производительность, то вам следует прочитать и понять это и это, и решить что работает лучше в вашем случае.)

Важно отметить, что функциональные компоненты имеют несколько “ограничений”, которые я бы, скорее, назвал их сильными сторонами. Во-первых, функциональному компоненту нельзя присвоить атрибут ref (подробнее о нем здесь). Хотя он и является удобным способом для взаимодействия с дочерними компонентами из родительского, но, по моим ощущениям, это Неправильный Способ Разработки на React. ref -атрибуты поощряют очень императивный и почти jquery-подобный подход к написанию компонентов, уводя нас в сторону от философии функциональности и однонаправленности потока данных, ради которой мы и выбираем React.

Другое большое отличие заключается в том, что функциональные компоненты не могут иметь связанное с ними состояние, что также является большим преимуществом, о чем мой следующий совет…

4. Создавайте компоненты, не имеющие состояние (stateless)

Должен сказать, что на данный момент самая большая боль, которую я ощутил создавая приложения на React, была вызвана компонентами, у которых было слишком много состояния (state).

Цукерберг рекомендует:  Карьера - путь web-разработчика после обучения в

Наличие состояния затрудняет тестирование компонентов

Нет ничего проще для тестирования, чем чистые функции. Так зачем же нам лишать себя возможности делать компоненты в виде чистых функций, добавляя к ним состояние? Во время тестирования компонентов с состоянием, нам приходится приводить компоненты к определенному состоянию, чтобы затем протестировать их поведение. Нам, также, приходится возиться со всем разнообразием комбинаций состояния (которое компонент может изменить в любой момент) и входных атрибутов ( props , которые компонент вообще не контролирует), и выяснять которые из них тестировать и как. А когда компоненты выполнены в виде простых функций от входных данных — тестировать намного легче. (Подробнее о тестировании ниже).

Наличие состояния затрудняет понимание работы компонента

Когда читаешь код компонента со сложным и развесистым состоянием, то приходится сильнее напрягать голову, чтобы уследить за всем что происходит. Постоянно возникают вопросы из разряда: “Это состояние уже инициализировано?”, “Что будет, если я поменяю состояние в этом месте?”, “Возникает ли здесь race condition?”. Просмотр компонентов, имеющих состояние, с целью понять их поведение, становится очень болезненным.

Наличие состояния слишком легко позволяет вставить в компонент бизнес-логику

На самом деле, просмотр компонентов с целью выявления логики поведения это не то, что мы должны делать. Вспомните, React это библиотека отображения, таким образом логика рендеринга в компоненте это ОК, но бизнес-логика в компоненте — это очень плохо. И когда большая часть состояния приложения уже находится прямо здесь в компоненте и легко доступна с помощью this.state , то возникает большой соблазн добавить сюда же логику вроде подсчетов чего-либо или валидацию, чего не должно быть в компоненте. Возвращаясь к одному из предыдущих пунктов, это сильно затрудняет тестирование — вы не можете протестировать логику рендеринга, без путающейся под ногами бизнес-логики, и наоборот!

Наличие состояния затрудняет обмен информацией с другими частями приложения

Когда у компонента есть свой кусочек состояния, то довольно легко передать его дальше вниз по иерархии компонентов, но любое другое направление уже проблематично.

Конечно, иногда имеет смысл оставлять определенную часть состояния приложения “на совести” конкретного компонента. В таком случае, вполне можно использовать this.setState . Это допустимая и легальная возможность API React-компонентов, и я не хочу чтобы сложилось впечатление, что это нужно запретить. Например, когда пользователь вводит текст в поле, то, скорее всего, всему приложению не нужно знать о каждом нажатии клавиши. Во время этого, компонент input может менять свое промежуточное состояние до тех пор, пока не потеряет фокус, после чего итоговый текст отправится наружу и станет частью состояния, хранящегося где-нибудь в другом месте. Этот сценарий недавно упомянул мой коллега, и я считаю, что это хороший пример.

Каждый раз, добавляя компоненту состояние, убедитесь, что это действительно нужно. Иначе, однажды начав, будет сложно перестать добавлять все новые и новые вещи, и все выйдет из под контроля раньше, чем вы это обнаружите!

5. Используйте Redux.js

В первом пункте я сказал, что React это только отображение. Тогда возникает очевидный вопрос “Где должны храниться состояние и логика?”. Я рад, что вы спросили!

Возможно вы уже слышали о Flux, который представляет собой стиль/шаблон/архитектуру для создания web-приложений, в основном использующих для рендеринга React. Существует несколько фреймворков, воплощающих идеи Flux, но я без сомнения могу порекомендовать Redux.js *.

Я планирую написать целый отдельный пост о функциях и преимуществах Redux, но пока просто порекомендую прочитать официальное руководство по ссылке выше. Вот очень краткое описание того, как работает Redux:

  1. Компоненты получают функции обратного вызова, как props , которые они вызывают, когда возникают события UI
  2. Эти функции обратного вызова создают и возвращают действия, основываясь на информации о событии
  3. Редьюсеры обрабатывают действия, вычисляя новое состояние
  4. Новое состояние всего приложения отправляется в единое хранилище
  5. Компоненты получают новое состояние через props и перерисовывают себя там, где это необходимо


Большая часть перечисленных концепций не является уникальной для Redux, но Redux реализует их просто и без излишеств, с помощью минимального API. Перенося приличного размера проект с Alt.js на Redux, я обнаружил несколько преимуществ последнего. Вот самые значительные из них:

  • Редьюсеры это чистые функции, все что они делают это oldState + action = newState . Каждый редьюсер вычисляет отдельный кусок состояния. Все эти куски, впоследствии, объединяются вместе, формируя целое приложение. Это значительно упрощает тестирование бизнес-логики и логики изменения состояния.
  • API меньше, проще и лучше документирован. Я обнаружил, что его концепции гораздо проще и легче изучать, и, следовательно, намного легче разобраться в потоках действий и информации в приложении.
  • Если его использовать так, как рекомендовано, то лишь незначительное число компонентов будет напрямую зависеть от Redux. Все остальные компоненты просто получают состояние и функции обратного вызова через props . Таким образом, компоненты остаются очень простыми и уменьшается завязанность на конкретном фреймворке.

Есть несколько библиотек, которые очень хорошо дополняют Redux, советую их тоже использовать:

  • Immutable.js — немутабельные структуры данных для JavaScript! Используйте их для хранения состояния, чтобы быть уверенным, что оно не меняется там, где не должно, а также чтобы сохранить функциональную чистоту редьюсеров
  • redux-thunk — используется когда нужно, чтобы действия (actions) имели какой-либо побочный эффект в дополнение к обновлению состояния приложения. Например, вызов REST API, или установка маршрутов (routes), или даже вызов других действий.
  • reselect — используется для создания составных, лениво исполняемых отображений. Например для конкретного компонента вам может потребоваться:
  • 1. вставить только определенную часть глобального состояния, а не полностью
  • 2. вставить дополнительные производные данные, например итого или результаты валидации данных, не сохраняя все это в состоянии

Не обязательно использовать все это с первого дня. Я советую применить Redux и Immutable.js как только у вас появится какое-нибудь состояние, reselect — когда у вас появятся производные данные, и redux-thunk — когда у вас появится маршрутизация или асинхронные действия. Лучше начать их использовать раньше, чем позже — это избавит вас от лишней работы для внедрения их в дальнейшем.

*В зависимости от того, кого вы спросите, Redux может быть или не быть “настоящей” реализацией Flux. Лично я считаю, что он достаточно хорошо соответствует ключевым идеям, чтобы называться Flux-фреймворком, но, как бы то ни было, это все вопрос терминологии.

6. Всегда используйте propTypes

propTypes предлагают нам действительно легкий способ добавить немного типобезопасности нашим компонентам. Вот как они выглядят:

В разработческом окружении (не на боевом сервере) React будет писать в лог информацию об ошибках, если какой-либо компонент не получил требуемый prop , или получил, но данные оказались не того типа, который ожидался. В этом есть следующие преимущества:

  • это может отловить ошибку на ранней стадии, предотвращая глупые ошибки
  • если вы воспользуетесь isRequired , то вам не придется так часто делать проверку на undefined или null
  • это также выполняет роль документации, освобождая читателя от необходимости поиска по всему компоненту, с целью понять какие props ему нужны

Этот список выглядит так, будто составлен апологетом языков со статической типизацией. Лично я предпочитаю динамическую типизацию, потому что она делает разработку более легкой и быстрой. Но я пришел к тому, что propTypes дает типобезопасность, не добавляя излишнюю сложность. Честно говоря, я не вижу причины не использовать propTypes всегда, когда это возможно.

Еще один совет — сделайте так, чтобы тесты падали при любых ошибках, связанных с propTypes . Вот грубоватое, но рабочее решение:

7. Используйте поверхностный рендеринг

Тестирование React-компонентов все еще коварная тема. Не потому что это сложно, а потому что это все еще развивающаяся область, и ни один отдельный подход еще не признан однозначно лучшим. На данный момент, моя палочка-выручалочка это использование поверхностного рендеринга (shallow rendering) и проверка props .

Поверхностный рендеринг позволяет отрисовать отдельный компонент , но не углубляясь и не отрисовывая его дочерние компоненты. Вместо этого, объект, получаемый в результате такого рендеринга, предоставляет вам информацию о таких вещах, как тип и входные параметры ( props ) дочерних элементов. Это дает нам изоляцию, позволяющую тестировать отдельные компоненты без их дочерних.

Когда я тестирую компоненты, чаще всего я пишу следующие виды юнит-тестов:

Логика рендеринга

Представим компонент, который должен отображать изображение или иконку, в зависимости от условий:

Мы можем протестировать его следующим образом:

Проще простого! Стоит обратить внимание, что API для поверхностного рендеринга немного сложнее, чем показано в этом примере. Функция shallowRender это наша самописная вспомогательная обертка вокруг реального API, облегчающая его использование.

Возвращаясь к нашему компоненту ListOfNumbers , вот так мы можем протестировать, что обход массива происходит корректно:

Преобразование свойств

В последнем примере, мы нырнули в дочерние элементы тестируемого компонента, чтобы убедиться, что они корректно рендерятся. Мы можем расширить его, добавив проверку не только наличия дочерних элементов, но и корректности передаваемых им свойств (props). Это особенно полезно, когда компонент делает некие преобразования свойств, перед тем как передать их дочерним элементам. Например, следующий компонент принимает имена CSS-классов в виде массива строк, и передает их дальше в виде одной строки, разделенной пробелами:

Наиболее частый аргумент против такого подхода к тестированию это излишнее повторение props.children.props.children. Хотя это и не самый аккуратный код, лично я заметил, что когда мне начинает надоедать часто писать props.children в одном тесте — это признак того, что компонент слишком большой, сложный или глубоко вложенный, и его нужно разделить на более мелкие.

Также я часто слышу, что такой подход, при котором тесты слишком зависимы от внутренней реализации компонента, ведет к поломке всех тестов даже при незначительном изменении структуры DOM. Это справедливое замечание, и набор хрупких тестов никому не нужен. Лучший способ преодолеть это — делать компоненты маленькими и простыми, что должно уменьшить число сломавшихся тестов при изменении любого отдельного компонента.

Взаимодействие с пользователем

Конечно, компоненты нужны не только для вывода информации, но и для взаимодействия:

Вот мой любимый способ тестирования взаимодействий:

Это достаточно упрощенный пример, но, надеюсь, вы поняли идею.

Интеграционное тестирование

До этого момента, я рассказал только о модульном тестировании изолированных компонентов, но вам также захочется делать более высокоуровневое тестирование, чтобы убедиться что компоненты приложения корректно соединены и оно действительно работает. Я не буду сильно углубляться в детали, но вот основные принципы:

  1. Рендерите все дерево компонентов (вместо поверхностного рендеринга)
  2. Работайте непосредственно с DOM (используя React TestUtils или jQuery), чтобы определить элементы, которые вас непосредственно интересуют, и затем:
  3. Проверяйте их HTML атрибуты, содержимое или…
  4. Эмулируйте события DOM и затем проверяйте побочные эффекты (изменения в DOM или в маршрутах, вызовы AJAX и т.п.)

По поводу TDD

Вообще, я не использую TDD при написании React-компонентов. Во время работы над компонентом, я часто “перетряхиваю” его структуру, пытаясь написать как можно более простые HTML и CSS, которые выглядят правильно в любом из поддерживаемых мной браузеров. А поскольку мой подход к модульному тестированию компонентов, как правило, завязан на их структуру, то мне придется постоянно чинить тесты, что будет пустой тратой времени.

Другая причина это необходимость в том, чтобы компоненты были очень простыми, что сведет на нет все преимущества подхода test-first. Вся сложная логика и преобразования выведены в редьюсеры и создатели действий, где я уже по полной пожинаю плоды TDD.


В этом разделе я говорил только о тестировании компонентов, поскольку для тестирования остальной части Redux-приложений не требуется какая-либо специфическая информация. Как у фреймворка, у Redux совсем немного “магии”, скрытой под капотом. И я считаю, это сокращает потребность в каком-либо чрезмерном подготовительном процессе к тестированию. Все что есть, это всего лишь давно знакомые, простые функции (много из них чистые), что является настоящим глотком свежего воздуха, когда дело доходит до тестирования.

8. Используйте JSX, ES6, Babel, Webpack и NPM (или Yarn)

Специфичная для React вещь здесь только одна — JSX. Для меня это просто более наглядная и понятная замена вызову React.createElement . Единственный недостаток здесь это небольшое усложнение в процессе сборки, что легко решается с помощью Babel.

Раз уж мы добавили Babel, то почему бы теперь не использовать все великолепие возможностей ES6, таких как константы, стрелочные функции, дефолтные аргументы, деструктурирование массивов и объектов, оператор расширения и оператор остальных аргументов, шаблонные строки, итераторы и генераторы, приличная система модулей и т.д. Реально ощущается, что в последнее время JavaScript растет как язык, конечно если вы готовы потратить немного времени на настройку соответствующих инструментов.

В довершение ко всему, мы используем Webpack для сборки нашего кода, и NPM для управления зависимостями. И теперь мы полностью соответствуем новомодным трендам в JavaScript :)

(Прим. пер.: сейчас рекомендуется использовать yarn вместо NPM, по ряду причин )

9. Используйте dev tools для React и Redux

Говоря о сопутствующем инструментарии, у React и Redux есть достаточно крутые инструменты разработчика. React dev tools дает возможность проинспектировать отрендеренное дерево компонентов, что чрезвычайно полезно, когда необходимо увидеть что же в конечном итоге получилось в браузере. Redux dev tools гораздо более выразительны и позволяют увидеть каждое произошедшее действие, изменение состояния, которое оно вызвало, и даже дает возможность перемещаться назад во времени! Вы можете добавить его как dev-зависимость, или как браузерное расширение.

Вы также можете настроить горячую замену модулей с помощью Webpack, и ваша страница будет обновляться сама, как только вы сохраняете файл с кодом. Это экономит много времени во время тонкой настройки компонентов и редьюсеров.

10. Бонус от переводчика. Используйте React Create App

react-create-app это утилита командной строки, которая дает возможность создать пустое приложение с базовой структурой директорий, встроенным и настроенным Webpack, Babel и Eslint, со всеми зависимостями. Вам остается только запустить его командой yarn start и сфокусироваться на коде и бизнес-логике вашего приложения, не погружаясь в дебри настройки окружения. Если же вдруг потребуется изменить стандартную конфигурацию, то и такая возможность есть (команда eject ).

Заключение

Надеюсь, эти советы дадут вам преимущество в изучении React, и помогут избежать некоторые наиболее распространенные ошибки. Если вам понравилась эта статься, то можете зафолловить меня в Твиттере, или подписаться на мой RSS feed.

HTML5, CSS3 и JavaScript. Исчерпывающее руководство

В этой книге вы найдете все, что необходимо знать для создания отличных веб-сайтов. Начав с изучения принципов функционирования Интернета и веб-страниц, к концу книги вы освоите приемы создания сложных сайтов, включая таблицы стилей CSS и графические файлы, и научитесь размещать страницы во Всемирной паутине. Книга включает упражнения, с помощью которых вы освоите разнообразные техники работы с современными веб-стандартами (включая HTML5 и CSS3).

Цукерберг рекомендует:  Android. Быстрый старт. Создаем игру для мобильного устройства

Вы научитесь:

  • создавать HTML-страницы и добавлять на них текст, ссылки, изображения, таблицы и формы;
  • работать с каскадными таблицами стилей — форматировать текст, устанавливать цвета и фон, компоновать макеты страниц и создавать простые анимационные эффекты;
  • использовать новые для HTML5 элементы, API-интерфейсы и свойства CSS3 при верстке веб-страниц;
  • подготавливать страницы для отображения на мобильных устройствах посредством применения техник адаптивного веб-дизайна;
  • работать с языком JavaScript, и разберетесь, почему он так важен для веб-дизайна;
  • создавать и оптимизировать графические изображения для веб.

Можете ее скачать с нашего Telegram-канала или оставить в комментариях свою электронную почту, и я вам ее вышлю.

Поделиться

Похожие посты

JavaScript на примерах, Никольский А.П

Отличная книга которая позволит изучить язык программирования JavaScript на примерах. В ходе изучения данной книги, вы научитесь создавать от самы.

jQuery в действии — Беэр Бибо, Иегуда Кац, Аурелио де Роза, год издания — 2020

Это динамичное и исчерпывающее руководство по библиотеке jQuery. В книге рассматриваются задачи, с которыми приходится сталкиваться при реализации пра.

Создаем динамический веб-сайт с помощью PHP, MySQL, JavaScript, CSS и HTML5. 2e издание

Для кого предназначена эта книга: Эта книга предназначена для тех, кто хочет изучить способы создания эффективных и динамичных сайтов. Сюда можно отн.

Разработка на React. Установка

Человека связанного с современным фронтендом, чаще всего, отпугивает не сложность фреймворка, а сложность его конфигурации. К счастью, в мире React все не так страшно, как кажется. В этой части рассмотрим несколько путей быстрой инициализации минимального React-приложения.

React-зависимости

React – является обычной js-библиотекой, которую возможно подключить через тег

Заменить <версия react>на нужную (либо новейшую) версию React. Нужно учесть, что библиотека была разбита на два файла после выхода 14 версии.


Учебник по фреймворку React

Учебник по React

  • Урок №
    Учебник по React
    для новичков по-русски
  • Урок №
    Работа с JSX
    в фреймворке React
  • Урок №
    Работа
    с состояниями и событиями
  • Урок №
    Работа
    с if и циклами
  • Урок №
    Продвинутая
    работа с циклами
  • Урок №
    Работа
    с формами
  • Урок №
    Продвинутая
    работа с формами
  • Урок №
    Практика
    по работе с формами
  • Урок №
    Работа
    с компонентами
  • Урок №
    Продвинутая
    работа с компонентами
  • Урок №
    Практика
    по фреймворку React
  • Тут будут еще уроки
    появятся в августе-сентябре.

React является одним из самых популярных JavaScript фреймворков. Фреймворк представляет собой заготовку, которая помогает вам писать код.

Как он это делает: фреймворк заставляет вас следовать определенным соглашениям по написанию кода, в результате этого все ваши проекты становится проще разрабатывать, а самое главное — проще поддерживать в дальнейшем.

Кроме того: так как все проекты на фреймворке следуют одному и тому же соглашению, то любой другой человек сможет с легкостью разобраться в вашем коде и допилить что-либо в сделанном вами проекте.

Фреймворки типа React используются для так называемых SPA (single page application — одностраничное приложение). Одностраничное приложение — это сайт, все действия в котором происходят на одной странице, без ее полного обновления.

Примером SPA может служить социальная сеть, работа с почтой и так далее.

Перед изучением React

Перед чтением данного учебника изучите уроки по работе с контекстом и учебник по ООП на классах в стиле ES6 в JavaScript. Это обязательно, без этого вы ничего не поймете.

Введение в React

Перед чтением также советую посмотреть вебинар по React, который является введением в этот фреймворк. Вебинар вы найдете по следующим ссылкам: 1, 2, 3, 4, 5, 6, 7, 8.

Подключение React

React работает на ES6, поддержки которого пока во всех браузерах нет. Поэтому для того, чтобы ваш код заработал, — следует использовать специальные программы-транспойлеры, которые преобразуют ваш код ES6 в код ES5.

Самым популярным транспойлером является Babel. Им мы и будем пользоваться.

На самом деле реальные проекты на React требуют некоторого знания nodejs и npm. Мы пока не будем с этим заморачиваться, потому что мне хотелось бы, чтобы вы сразу начали писать код.

Для самого простого запуска React нужно подключить такую кучку скриптов:

На продакшене (так называют рабочий сайт) так делать не стоит (так как здесь компиляция кода из новой версии в старую происходит в браузере, а это очень медленно). Мы так делаем для простоты — чтобы вы сразу начали писать код. Попозже мы разберем более сложный способ.

После подключения этих скриптов мы можем выполнять наш ES6 код в теге script с типом text/babel (это важно: не text/javascript, как мы привыкли):

Почему стоит использовать React JS при разработке приложений

В этой статье мы попытаемся выяснить, почему библиотека React JS становится все более популярной в последнее время и почему многие заказчики делают выбор в пользу React разработки. Мы коснемся наиболее существенных преимуществ, которые могут быть предоставлены разработчикам и заказчикам, которые выберут React JS в качестве одной из используемых технологий при создании мобильных и веб-приложений.

Библиотека React была впервые выпущена компанией Facebook в 2013 году. Для того, чтобы понять, насколько популярной эта технология стала за прошедшее время, давайте обратимся к опросу разработчиков, проведенному сайтом StackOverflow в этом году. Более 50 000 разработчиков поделились информацией о своей работе и профессиональных предпочтениях. Помимо более или менее предсказуемых результатов, которые обрисовывают состоянии IT-индустрии на сегодняшний день, есть также и кое-что любопытное относительно непосредственно React. Эта библиотека стала одной из самых любимых и востребованных технологий, а также самой трендовой технологией на StackOverflow:

Довольно веский аргумент для того, кто задумывается о том, не стать ли ему React разработчиком, не так ли? Но давайте не будем делать поспешных выводов. Вместо этого, рассмотрим основные возможности React, благодаря которым эта библиотека стала такой популярной. Более того, мы попытаемся выяснить, являются ли эти особенности важными только для разработчиков или могут также принести выгоду и заказчикам.

Что такое React JS. Краткий обзор

React это библиотека для создания пользовательских интерфейсов. Одной из ее отличительных особенностей является возможность использовать JSX, язык программирования с близким к HTML синтаксисом, который компилируется в JavaScript. Разработчики могут добиваться высокой производительности приложений с помощью Virtual DOM. C React вы можете создавать изоморфные приложения, которые помогут вам избавиться от неприятной ситуации, когда пользователь с нетерпением ожидает, когда же наконец завершится загрузка данных и на экране его компьютера наконец появится что-то помимо анимации загрузки. Созданные компоненты могут быть с легкостью изменены и использованы заново в новых проектах. Высокий процент переиспользования кода повышает покрываемость тестами, что, в свою очередь, приводит к более высокому уровню контроля качества. Используя React Native мобильные приложения для Android и iOS, используя опыт JavaScript и React разработки.

Это были технические особенности, которые могут послужить пищей для размышлений для разработчиков. Теперь давайте перейдем к следующему вопросу.

Какую пользу из React может извлечь заказчик?
Итак, давайте разбираться:

  • Virtual DOM может повысить производительность высоконагруженных приложений, что может снизить вероятность возникновения возможных неудобств и улучшает пользовательский опыт;
  • Использование изоморфного подхода помогает производить рендеринг страниц быстрее, тем самым позволяя пользователям чувствовать себя более комфортно во время работы с вашим приложением. Поисковые системы индексируют такие страницы лучше. Поскольку один и тот же код может быть использован как в клиентской, так и в серверной части приложения, нет необходимости в дублировании одного и того же функционала. В результате время разработки и затраты снижаются;
  • Благодаря переиспользованию кода стало гораздо проще создавать мобильные приложения. Код, который был написан во время создания сайта, может быть снова использован для создания мобильного приложения. Если вы планируете использовать не только сайт, но и мобильное приложение, нет необходимости нанимать две большие команды разработчиков.

Теперь давайте более подробно рассмотрим, за счет чего достигаются вышеописанные выгоды. Конечно, одной статьи будет недостаточно, чтобы описать все возможности данной библиотеки. Но мы сконцентрируемся на самых важных из них чтобы помочь вам понять, могут ли React разработчики решать проблемы с помощью:

  1. Улучшения пользовательского опыта ваших сайтов и приложений
  2. Увеличения скорости разработки
  3. Использования наиболее трендовых технологий разработки

Изоморфные приложения. Поймать двух зайцев

Когда мы говорим об изоморфных приложениях или об изоморфном JavaScript, мы имеем в виду, что мы можем использовать один и тот же код как в серверной, так и в клиентской части приложения. Когда пользователь открывает сайт в своем браузере, содержимое страницы должно быть загружено с сервера. В случае с SPA-приложениями (Single Page Application), это может занять некоторое время. Во время загрузки пользователи видят либо пустую страницу, либо анимацию загрузки. Учитывая, что по современным стандартам ожидание в течение более чем двух секунд может быть весьма заметным неудобством для пользователя, сокращение времени загрузки может оказаться крайне важным. А вот еще одна весомая проблема: поисковые машины не индексируют такие страницы так хорошо, как нам хотелось бы. Исполнение JavaScript кода на стороне сервера помогает исправить подобные проблемы. Если вы создаете изоморфные приложения, вы можете извлечь заметную выгоду, производя рендеринг на стороне сервера. После загрузки страницы вы все еще можете продолжать рендеринг компонентов. Такая возможность рендеринга страниц как на сервере, так и на клиенте приводит к заметным преимуществам, таким как возможность лучшего индексирования страниц поисковыми машинами и улучшение пользовательского опыта. Более того, такой подход позволяет снизить время, затрачиваемое на разработку. При использовании некоторых современных фреймворков, вы должны создавать компоненты, которые должны рендериться на стороне сервера, а также шаблоны для клиентской стороны приложения. React разработчики могут создавать компоненты, которые работают на обеих сторонах.

Virtual DOM. Просто потому, что так быстрее

Document Object Model, или DOM, — это способ представления и взаимодействия с объектами в HTML, XHTML и XML документах. Согласно этой модели, каждый такой документ представляет собой иерархическое дерево элементов, называемое DOM-деревом. Используя специальные методы, мы можем получит доступ к определенным элементам нашего документа и изменять их так, как мы хотим. Когда мы создаем динамичную интерактивную веб-страницу, мы хотим, чтобы DOM обновлялся так быстро, как это возможно после изменения состояния определенного элемента. Для данной задачи некоторые фреймворки используют прием, который называется «dirty checking» и заключается в регулярном опросе состояния документа и проверке изменений в структуре данных. Как вы можете догадаться, подобная задача может стать самой настоящей головной болью в случае высоконагруженных приложений. Virtual DOM, в свою очередь, хранится в памяти. Именно поэтому в момент, когда «настоящий» DOM меняется, React может изменять Virtual DOM в мгновение ока. React «собирает» такие изменения сравнивает их с состоянием DOM, а затем перерисовывает изменившиеся компоненты.

При данном подходе вы не производите регулярное обновление DOM. Именно поэтому может быть достигнута более высокая производительность React приложений. Второе следствие вытекает из изоморфной природы React: вы можете производить рендеринг на стороне сервера совсем как на стороне клиента.

Как переиспользование кода помогает разрабатывать и тестировать приложения более эффективно

Мобильные приложения имеют некоторые преимущества по сравнению с сайтами. Их можно использовать без соединения с Интернетом. Они имеют доступ к таким возможностям устройства, как всплывающие уведомления. Также они позволяют быть в контакте с вашими пользователями в режиме 24/7. React Native — это фреймворк, который позволяет вам создавать мобильные приложения, используя React. Логика приложения пишется на JavaScript, таким образом, программисту не нужно отказываться от привычных приемов веб-разработчика. Все что нужно — научиться писать специфичный для устройства код, который адаптирует компоненты, ранее созданные для веб-сайта к новой среде обитания.

Если мы сравним затраты на разработку разных видов мобильных приложений, мы получим примерно следующие результаты:

  • В случае с нативными приложениями вы можете надеяться на довольно высокую производительность, но стоимость разработки будет довольно высокой;
  • Если вы предпочтете фреймворки, которые позволяют использовать HTML5, CSS3 и JavaScript, например PhoneGap, вы можете снизить стоимость. Но в этом случае уровень производиетльности будет гораздо ниже;
  • В случае React вы можете достигнуть уровня производительности, сравнимого с нативными приложениями. При этом стоимость разработки сравнима с предыдущим примером.

Если вы планируете создать корпоративное веб-приложение и не вполне уверены, будет ли разработка мобильной версии этого же приложения хорошей идеей, вот что вы должны помнить. React Native позволяет использовать уже имеющуюся логику веб-приложения при создании мобильного приложения. Это значит, что команда разработчиков может использовать тот же код, который был использован в процессе создания сайта вместо того, чтобы начинать с чистого листа.

Помимо более быстрой разработки, переиспользование кода позволяет избежать большого количества ошибок. Если вы создаете хорошо спроектированные компоненты, которые затем используете снова, вам нужно будет писать меньше кода, когда вы решите создать с их помощью новый пользовательский интерфейс. Чем меньше нового кода вам нужно, тем меньше вероятность возникновения новых ошибок. К тому же, вы знаете ваши компоненты. Вы уже использовали и тестировали их при работе над реальным проектом, а значит при возникновении ошибок сможете предсказать причину их появления.

Заключение

Компонентно-ориентированный подход, возможность с легкостью изменять имеющиеся компоненты и переиспользовать код превращают React разработку в непрерывный процесс улучшения. Компоненты, которые были созданы во время работы над тем или иным проектом, не имеют дополнительных зависимостей. Таким образом, ничто не мешает использовать их снова и снова в проектах разного типа. Весь предыдущий опыт может быть с легкостью применен при работе над новым сайтом или даже при создании мобильного приложения. Используя передовые возможности, такие как Virtual DOM или изоморфный JavaScript, React разработчики могут с высокой скоростью создавать высокопроизводительные приложения, несмотря на уровень их сложности. Возможность с легкостью заново использовать уже имеющийся код повышает скорость разработки, упрощает процесс тестирования, и, как результат, понижает затраты. Тот факт, что эта библиотека разрабатывается и поддерживается высококвалифицированными разработчиками и набирает все большую популярность с каждым годом, дает основания надеяться, что тенденция к дальнейшим улучшениям продолжится.

Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих