ReactJS для глупых людей

Пытаясь разобраться с библиотекой от Facebook ReactJS и продвигаемой той же компанией архитектурой «Flux», наткнулся на просторах интернета на две занимательные статьи: «ReactJS For Stupid People» и «Flux For Stupid People». Решил поделиться с хабравчанами переводом первой (а чуть позже и второй) статьи. Итак, поехали.

ReactJS для глупых людей


TL;DR В течении долгого времени я пытался понять, что такое React и как он вписывается в структуру приложения. Это статья, которой мне в свое время не хватало.

Что такое React?


Чем отличается React от Angular, Ember, Backbone и других? Как управлять данными? Как взаимодействовать с сервером? Что, черт возьми, такое JSX? Что такое «component»?

СТОП.

Остановитесь прямо сейчас.

React — это ТОЛЬКО УРОВЕНЬ ПРЕДСТАВЛЕНИЯ.

React часто упоминают в одном ряду с другими javascript фреймворками, но споры «React vs Angular» не имеют смысла, потому что это не сопоставимые вещи. Angular — это полноценный фреймворк (включающий и уровень представления). React — нет. Вот почему React вызывает столько непонимания в развивающемся мире полноценных фреймворков — это только представление.

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

Разумеется, вы не можете построить полно функционирующее динамическое приложение только с React. Почему, мы рассмотрим позже.

Плюсы


После работы с React, я увидел три очень важных преимущества.

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

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

<header>  
   <div class="name"></div>
</header> 


$.post('/login', credentials, function( user ) {
   // Modify the DOM here
    $('header .name').show().text( user.name );
});


По опыту могу сказать, что этот код испортит жизнь вам и вашим коллегам. Как производить отладку? Кто изменяет заголовок? Кто имеет доступ к заголовку? Кто определяет видимость? Манипуляция с DOM так же плоха, как оператор GOTO в логике вашей программы.

Вот как вы могли бы сделать это с React:

render: function() {  
    return <header>
        { this.state.name ? <div>this.state.name</div> : null }
    </header>;
}


Мы можем тут же сказать, как компонент будет отрисован. Если вы знаете состояние — вы знаете результат отрисовки. Вам не нужно прослеживать ход выполнения программы. Когда разрабатывается сложное приложение, особенно в команде, это очень важно.

2. Связывание JavaScript и HTML в JSX делает компоненты простыми для понимания.
Странное сочетание HTML/JavaScript может вас смутить. Нас учили не вставлять JavaScript в DOM (например: обработчики OnClick), еще в то время, когда мы были «крошечными» разработчиками (ор: since we were wee developers). Но вы можете мне верить, работать с JSX компонентами это на самом деле замечательно.

Обычно вы разделяете представления (HTML) и функциональность (JavsScript). Это приводит к монолитному JavaScript файлу, содержащему всю функциональность для одной страницы, и вы должны следить за сложным потоком JS->HTML->JS->неприятная ситуация.

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

3. Вы можете рендерить React на сервере.
Если вы разрабатывает публичный сайт или приложение, и вы рендерите все на клиенте, то вы выбрали неправильный путь. Клиентский рендеринг — это причина, почему SoundCloud работает медленно, и почему Stack Overflow (используя только серверный рендеринг) работает так быстро. Вы можете рендерить React на сервере, и вы должны этого делать.

Angular и другие поощряют использование PhantomJS для рендеринга страницы и предоставления ее поисковым движкам (основываясь на user-агенте) или использование платных сервисов. ТЬФУ!

Минусы


Не забывайте, что React — это только представление.

1. Вы не получите следующее:
  1. Систему событий (отличную от нативных DOM событий);
  2. Работу с AJAX;
  3. Какой либо слой данных;
  4. Promises;
  5. Фреймворк на все случаи жизни;
  6. Какие либо мысли о том, как реализовать все вышеуказанное.


В реальном мире React сам по себе бесполезен. Хуже того, как мы видим, это приводит к тому, что каждый изобретает свой велосипед.

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

image

Здесь три отдельных, конкурирующие туториала для начинающих. Это удивляет. Боковая панель ниже, словно из моих ночных кошмаров, с разделами, которые точно не должны быть здесь, такие как «More About Refs» и «PureRenderMixin» (прим. переводчика: плагин для React).

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

image

35 KB gzipped
Это без библиотеки в reacat-with-addons, которая будет вам нужна для разработки реального приложения!
Это без библиотеки ES5-shim, необходимой для поддержки IE8!
Это без какой-либо другой библиотеки!

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

Хватит говорить «FLUX»


Пожалуй, самая раздражающая часть при разработке на React — это «Flux». Запутывающий еще больше, чем React. Раздутое понятие «Flux» сильно мешает пониманию. Нет такой вещи, как Flux. Flux — это концепция, но не библиотека. Окей, есть Flux библиотека с чем-то вроде:
Flux скорее паттерн, чем фреймворк


Тьфу. Хуже всего то, что React не переосмысляет последние 40 лет знаний в области UI-архитектуры и не придумывает какой-то новой концепции управления данными.

Концепция Flux проста: ваше представление вызывает событие (например: пользователь вводит имя в текстовое поле), событие изменяет модель, затем модель вызывает событие, представление реагирует на событие модели и перерисовывается с новыми данными. Вот и все.

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

Плохой стороной Flux является то, что каждый заново изобретает его. Так и нет договоренности о библиотеки событий, слое модели, AJAX слое и остального, есть много разных реализаций «Flux» и все они конкурируют между собой.

Должен ли я использовать React?


Короткий ответ: да.

Развернутый ответ: к сожалению, да, для многих вещей.

Почему вы должны использовать React:
  • Отлично подходит для командной разработки, строгое соблюдение UI, и шаблона рабочего процесса;
  • UI код читабельный и прост в сопровождении;
  • Разработка UI на основе отдельных компонентов — это будущее web-разработки и вы должны начать делать это уже сейчас.


Почему вы должны дважды подумать перед выбором:
  • На начальном этапе React замедляет работу. Понять, как работают props, state и как взаимодействуют компоненты непросто, а документация — это «лабиринт из информации». В теории это может быть решено быстро, если над этим будет работать целая команда;
  • React не поддерживает браузеры от IE8 и младше, и никогда не будет;
  • Если ваше приложение/веб-сайт не насыщены большим кол-вом динамических страниц, вам придется писать очень много кода, решая маленькие задачи;
  • Вы будете заново изобретать велосипеды. React молод, поэтому нет выработанных практик. Вашему приложению нужен дропдаун, ресайз окна или лайтбокс? Вам придется писать все это с нуля.


Итог:

Читайте следующий пост: «Flux For Stupid People» (на хабре).

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

Ну. И что?
Реклама
Комментарии 17
  • 0
    1. Вы не получите следующее:
    Систему событий (отличную от нативных DOM событий);

    Это неправда — вы получите систему отличную нативных — вот facebook.github.io/react/docs/events.html
    • +5
      скорее полуправда.
      События React — удобные обёртки нативных событий. Однако, нельзя создать своё событие, вызываемое внутри React-компонента. Думаю, речь идёт именно об этом.
    • НЛО прилетело и опубликовало эту надпись здесь
      • +2
        Аргумент против: синтетические примеры типа тудушек, в которых разметка умещается в три строки, смотрятся еще нормально. Но что делать, если из-за буйной фантазии дизигнера и поддержки старых браузеров разметки становится очень много?

        Вопросы:
        Как относятся к JSX синтаксису jshint/jslint/eslint/jscs и прочие тулзы проверки качества кода?
        • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            > Количество разметки никак не влияет на сложность.
            А я не про сложность. Бывает так сверстано, что куча всяких там дивов-спанов накручено, чисто для оформления. А внутри там какой-нить один несчастный инпут, который тебе и нужен. В результате разметки больше JS, и работать с ней неудобно.

            > Костя, попробуй :) и сам все поймешь.
            А я пробовал. И исплевался. В реальной жизни такую кучу HTML разметки в скриптах таскать, да еще не дай бог туда верстальщика пускать — ну его нафиг.

            Оно, конечно, заманчиво рендерить на серваке, но я уж лучше возьму Ractive.
            • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            Для тех, кто не жалует JSX существует библиотека-фасад JSnoX для конструирования virtual dom с помощью только JS.
            • 0
              Она, вроде бы, не одна такая. Но это, имхо, еще хуже.
          • +1
            Медленный рендеринг на клиенте — весьма спорное утверждение на мой взгляд.

            Virtual DOM — это ведь одна из ключевых фич в React, которая должна решать проблемы производительности. Поэтому я разделяю ваш взгляд :-)

            P.S. Как в TM вы используете React?
            • НЛО прилетело и опубликовало эту надпись здесь
              • 0
                У вас там фронтенд сильно задумчивый. При переключении табов «интересное -> лучшее -> итд» он еще думает над первым, потом по 2 раза переключает на других табах.
          • 0
            Скажите, как себя чувствуют мобильные приложения созданные с использованием react?
            Мне иногда приходится разрабатывать мобильные приложения и я использую angular, в целом меня устраивает, за исключением местами плохой производительности (не стоит мне говорить про оптимизации приложений на ангуляре, я все это знаю и использую). Проблема в основном в том, что, к примеру для приложений под firefox os, требуется соблюдение CSP, и ангуляр это делать позволяет с помощью аналогичной директивы, только вот скорость работы приложения при этом снижается раза в полтора. И потребление оперативной памяти могло быть лучше. В общем ищу альтернативы, которые поддерживают CSP.
            • НЛО прилетело и опубликовало эту надпись здесь
              • 0
                Как раз вчера анонсировали, думаю вам будет интересно:

                www.progville.com/javascript/react-native-apps-react-js/
                • НЛО прилетело и опубликовало эту надпись здесь
              • 0
                То как описано использование ReactJS в этой статье кажется настолько запутанным и сложным, после того как уже попробовал в деле RactiveJS. Единственный минус — он ещё «жирнее»))))

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

                Самое читаемое