ReactJS *

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

Когда вышла версия 1.0 Redux, я решил потратить немного времени на серию рассказов о моем опыте работы с ним. Недавно я должен был выбрать “реализацию Flux” для клиентского приложения и до сих пор с удовольствием работаю с Redux.

Почему Redux?

Redux позиционирует себя как предсказуемый контейнер состояния (state) для JavaScript приложений. Редакс вдохновлен Flux и Elm. Если вы раньше использовали Flux, я советую прочитать, что Redux имеет с ним общего в разделе "Предшественники" новой (отличной!) документации.

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

С чего начать изучение новой библиотеки или фрейморка? Сразу же найти статью на Хабре и с головой погрузиться в пучину практических примеров? Или сначала тщательно изучить официальную и неофициальную документацию, прежде чем перейти к практике? Именно между этими вопросами будет метаться ваше сознание, когда вы решите узнать, что же такое ReactJS. Чтобы желание учиться не умерло, как знаменитый ослик, обязательно загляните под капот.

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

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

Мы используем React и Flux в своей браузерной среде разработки Hexlet IDE (она в опен-сорсе), в которой учащиеся выполняют практические задания. Flux одновременно очень популярен и очень непонятен для многих в мире веба. Сегодняшний перевод — попытка объяснить Flux на пальцах (ну, то есть картинках).

Проблема

Вначале нужно понять, какую проблему решает Flux.

Мы рады представить вам наш первый релиз-кандидат версии React 0.14! Мы опубликовали в июле анонс предстоящих изменениях, но сейчас мы еще больше стабилизировали релиз и нам бы хотелось, чтобы вы попробовали его до того, как мы выпустим финальную версию.

Сообщите нам, если у вас возникли любые проблемы, создав задачу в нашем GitHub репозитории

Не так давно Microsoft объявила о выпуске TypeScript 1.6 Beta, одним из интересных, на мой взгляд, нововведением является поддержка React/JSX, что в совокупности с особенностями TypeScript'а открывает новые возможности.



Я расскажу о личном опыте — как начал использовать связку TypeScript + React, с каким проблемами столкнулся и как их решал. А так же покажу примеры gulp-тасков для того, чтобы это все заработало и продемонстрирую код минимального todo приложения на TypeScript + React (ссылка на Github).

Если вам это интересно — пожалуйста, заходите под кат.

Делал перевод статьи The land of undocumented react.js: The Context, где сослался на статью Dan Abramov про умные и глупые компоненты, но почему-то думал что она есть на habrahabr. Думаю эта небольшая статья ни для кого лишней не будет.
Перевод статьи Smart and Dumb Components

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

Вы найдете, что Ваши компоненты намного проще в реиспользовании и обсуждении, если Вы поделите их на две категории. Я называю их Умные (Smart) и Глупые (Dumb), но я так же слышал Fat и Skinny, Stateful и Pure, Screens и Components и так далее. Все это не абсолютно тоже самое но идея похожа.

Мои глупые компоненты:

1. не зависят от остальной части приложения, например Flux actions или stores
2. часто содержатся в this.props.children
3. получают данные и колбэки исключительно через props
4. имеют свой css файл
5. изредка имеют свой state
6. могут использовать другие глупые компоненты
7. примеры: Page, Sidebar, Story, UserInfo, List

Мои умные компоненты:

1. оборачивает один или несколько глупых или умных компонентов
2. хранит состояние стора и пробрасывает его как объекты в глупые компоненты
3. вызывает Flux actions и обеспечивает ими глупые компоненты в виде колбэков
4. никогда не имеют собственных стилей
5. редко сами выдают DOM, используйте глупые компоненты для макета
6. примеры: UserPage, FollowersSidebar, StoryContainer, FollowedUserList

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

Предлагаю читателям «Хабрахабра» перевод статьи «The land of undocumented react.js: The Context».

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

State

Да, каждый React компонент имеет state. Это что-то внутри компонента. Только сам компонент может читать и писать в свой собственный state и как видно из названия — state используется для хранения состояния компонента (Привет, Кэп). Не интересно, давайте дальше.

Props

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

Context

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

Перевод статьи «Stop Using React for EVERYTHING!», опубликованной на сайте medium.com.

Итак, вы освоили React. А еще добавили интеграцию с ES6. Окей, вы хороши в разбиении вашего кода на компоненты. К тому же вы… стоп. Нам пофиг.

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

ReactJS — это Чариза́рд (покемон такой). Это огнедышащий дракон в мире джаваскрипта. Он мощный, он быстрый, он ослепительный, и умные программисты тащятся от него.

Если вы еще не знакомы с ReactJS или React Native, то очень рекомендуем ознакомиться, эти фреймворки уже сейчас оказывают значительное влияние на то, куда движется мир разработки мобильных и веб-приложений. Наша же статья о том, как дать возможность веб-разработчику делать приложения для iOS с аудио/видео звонками и другими прелестями платформы voximplant. Создание нативных модулей для React Native — это настолько обширная тема, что про нее можно писать бесконечно и материалов про нее в сети пока еще катастрофически мало. Мы при создании модуля опирались на ряд готовых примеров с github, которые очень помогли не закопаться с этим на века.

В начале был Netscape. И возжелал Netscape выполнять Scheme-код в браузере Netscape Navigator. И наняли они Брендана Айка (Brendan Eich), чтобы он в поте лица своего работал над этим. Но потом они передумали и решили, что Java хотят они. И вот, рождён был JavaScript. И было это (достаточно) хорошо.

Безумная идея овладела Райаном Далом (Ryan Dahl) годы спустя: подружить движок V8 с библиотекой libev, дабы могли программисты выполнять свой JavaScript-код за пределами браузера. И возник Node.js. И npm. И люди возрадовались.

И стали люди писать веб-сервера на JavaScript, и запускать вертолёты с JavaScript на борту, и водружать его на планшеты и смартфоны, и встраивать его в термостаты и холодильники, да и во всё, во что их душа желала. И распространился JavaScript весьма и весьма широко. И презирали Нормальные Программисты™ (Serious Developers) простых людей, пишущих на JavaScript, но простые люди продолжали писать на JavaScript всё больше и больше.

И ждали люди Слово, способное вместить в себя всю широту проникновения JavaScript, ибо слово «JavaScript», как оно есть, более не вмещало той широты. И изрёк Чарли Роббинс (Charlie Robbins) мысль, что термином «Isomorphic JavaScript» можно назвать JavaScript-код, выполняющийся и в браузере, и на сервере. И никто нафиг не понимал значения сего, но, вместо просто программирования на JavaScript, люди стали программировать на изоморфном JavaScript.

Секундочку, что?

Итак, я знаю что ты любишь Todo списки, то есть, что тебе очень нравится писать Todo списки, поэтому мне хочется, чтобы ты создал один из них, используя новый, восхитительный и питательный («nutritious» прим. пер.) Flux фреймворк, Redux! Я желаю тебе только лучшего.

В этой статье ты научишься как сконструировать свое собственное Redux приложение, не ограничиваясь, но так же включая.

• Цельнозерновой рендеринг на сервере
• Расширенный роутинг, богатый Omega-3
• Маслянистая асинхронная загрузка данных
• Гладкое функциональное послевкусие

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

Хочу представить вашему вниманию boilerplate (skeleton) на базе React.js + Backbone для быстрого старта разработки приложения любой сложности. Эта связка помогла нашей команде в срок сделать сложное приложение с минимальным количеством проблем а простота позволила быстро подключать новых разработчиков в процесс.

Всем доброго времени суток!
Давайте немного поговорим о DX (Developer Experience) или «Опыте разработки», а если конкретнее — об обновлении кода в режиме реального времени с сохранением состояния системы. Если тема для вас в новинку, то перед прочтением советую ознакомиться со следующими видео:

Введение: Как это работает?

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

Это перевод поста Steven Luscher опубликованного в блоге Babel. Steven работает в Facebook над Relay – JavaScript фрэймворком для создания приложений с использованием React и GraphQL.

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

Привет, Хабр!

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

• Мы открыли публичный чат сообщества Хекслет в Слаке! Там можно общаться с другими юзерами и с преподавателями. Есть специальные каналы по отдельным курсам и темам, есть даже канал для изучения английского языка.
• Оповещения о выходе новых уроков в ваших курсах теперь приходят на почту и появляются в уведомлениях на сайте.
• На сайте теперь появляются запланированные курсы, которые находятся сейчас в разработке (подробнее о них ниже). На эти курсы можно подписаться заранее.
• В разделе «Песочница» находятся бесплатные курсы в свободном формате от других пользователей Хекслета. Вы тоже можете создать свой практический курс!
• За прохождения уроков начисляются баллы, а на главной странице можно видеть свою позицию в топе пользователей.

А теперь — новые курсы:

Основы Ansible

Системы управления конфигурацией и оркестрации – важные инструменты в арсенале современного разработчика и системного администратора. Цель этого курса – научиться работать с Ansible, популярным инструментом управления конфигурацией. Как мы писали ранее, Ansible активно используется при разработке и деплое Хекслета.

Предлагаю читателям «Хабрахабра» перевод публикации «Is ReactJS really fast?» из блога компании 500Tech.

tl;dr; Нет.

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

И даже публикация фэйковых результатов не вызывает подозрений, а ведь если копнуть глубже и проанализировать код тестов, то вы будете сильно удивлены.

Оригинал: React To The Future With Isomorphic Apps

Изоморфные приложения. Взгляд в будущее с React

В разработке программного обеспечения все часто возвращается на круги своя. Так, например, на заре развития Интернета серверы подгружали контент сразу же на сторону клиента. В последнее же время, с разработкой современных веб-фреймворков, таких как AngularJS и Ember, мы видим тенденцию к обработке запросов на стороне клиента и использованию сервера только для API. Однако, это далеко не единственная тенденция. Сейчас происходит медленное возвращение или, скорее, слияние этих двух архитектур.

Предлагаю читателям «Хабрахабра» перевод статьи «How I learned to stop worrying and love React».

Если вы спросите меня, что я думал о React два месяца назад, я бы сказал…

Где мои шаблоны? Что этот сумасшедший HTML делает в моем JavaScript? JSX выглядит странно! Скорее! Сжечь это!

Это потому, что я его не понял.

Но я уверяю, React — это определенно правильный путь. Пожалуйста, выслушайте меня.

В наше время для разработки фронтенда существует много фреймворков и библиотек. Есть хорошие, есть не очень. Часто нам нравится только какая-то концепция, модуль или синтакс. Универсальных инструментов не существует. В статье я описываю фреймворк будущего – такой, которого ещё нет. Я собрал достоинства и недостатки известных фреймворков и мечтаю об идеальном решении.

Абстракция опасна

Всем нравится простота. Сложность убивает. Она усложняет работу и приводит к крутой кривой обучения. Программистом нужно понимать, что как работает – иначе они чувствуют себя неуверенно. При работе со сложной системой есть большое расстояние между «я её использую» и «я знаю, как это работает». К примеру, следующий код прячет сложность:

var page = Framework.createPage({
	'type': 'home',
	'visible': true
});

Допустим, это реальный фреймворк. createPage где-то создаёт новый класс Вида, загружающий html-шаблон home. Основываясь на параметре visible мы добавляем созданный DOM-элемент к дереву. С точки зрения разработчика мы не знаем, как это всё работает в деталях, потому, что это – абстракция.

У некоторых фреймворков есть не один, а много уровней абстракции. Иногда нам нужно знать детали его работы. Абстракция – инструмент мощный, поскольку она делает обёртки для функциональностей, инкапсулирует решения по поводу дизайна. Но её надо использовать с умом, потому что она приводит к процессам, которые трудно отслеживать.

Если мы поменяем пример на следующий: