ReactJS *

Привет всем жителям и гостям хабра и с новым годом! :)
В этой статье я хочу рассказать о том, с какими фичами Jii вступил в 2016-й год и что его в ждет в новом году.

Итак, начнем по порядку.

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

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



В качестве таковых рассмотрим следующие:

• Реализуем пакет доступа к API ВКонтакте.
  Код будет работать как в «native» приложениях, так и в приложениях JavaScript через GHCJS, компилятор Haskell в JavaScript
  
• Напишем одностраничное браузерное приложение, используя наше API
  

Привет! Я хочу рассказать об очередной реализации Flux. А точнее о минимальной реализации, которую мы успешно используем в рабочих проектах. И о том, как мы пришли к этому. На самом деле многие так или иначе сами приходят к подобному решению. Описанное здесь решение является лишь вариацией ему подобных.

В Redradix мы уже около года разрабатываем веб-приложения на React и в течении этого времени у каждого из членов команды возникали идеи, которые мы постепенно выносили в свое, домашнее решение. Мы сразу же отказались от хранилищ в классическом Flux в пользу единого глобального состояния. Хранилища всего лишь выполняют роль сеттеров/геттеров в состояние приложения. Чем хорошо глобальное состояние? Одно состояние — это один конфиг всего приложения. Его без труда можно заменить другим, сохранить или передать по сети. Больше нету зависимостей между хранилищами.

Привет!

Мы в taaasty.ru уже полтора года живем на react-е и почти год без sprockets. Это так здорово, хочу поделиться. За одно расскажу как работает react с рельсами в режиме prerender.

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

• Хуижн — сервис для демонстрации заказчикам макетов с хранилищем в Google Docs. Это было прикольно.
• Planing Poker — старый, но все еще довольно посещаемый проект.
• KeyRights — корпоративный парольник. Пожалуй, единственный проект с хакатона, который решили сделать платным.

В этот раз мы решили покуситься на святое — написать HelpDesk. Абсолютно бесплатный, опенсорсный, безумно простой, ставится на раз-два. Рисуем дизайн, верстаем. Все это за неделю до. Собираемся в воскресенье в 10 утра в офисе. Закупаемся энергетиками, и понеслась!

Расскажу об еще одной интерпретации 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) или «Опыте разработки», а если конкретнее — об обновлении кода в режиме реального времени с сохранением состояния системы. Если тема для вас в новинку, то перед прочтением советую ознакомиться со следующими видео:

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

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