При разработке модульных тестов для react компонента, обернутого в вызов withRouter(Component) столкнулся с сообщением об ошибке, что такой компонент может существовать только в контексте роутера. Решение этой проблемы очень простое и не должно по идее вызывать вопрсов. Хотя почему-то ссылки на документацию https://reacttraining.com/react-router/web/guides/testing Google упорно отказывался выдавать. Меня это совсем не удивляет, т.к. документация написано как чистое SPA-приложение без всякого там SSR и с точки зрения поисковой машины выглядит вот так:


Кому достаточно документации может на этом закончить чтение. А для себя я сделаю несколько заметок под катом.

TL;DR: в этих сериях вы узнаете, как заставить React и Redux управлять SVG элементами для создания игры. Полученные в этой серии знания позволят вам создавать анимацию не только для игр. Вы можете найти окончательный вариант исходного кода, разработанного в этой части, на GitHub.

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

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

Для реализации был выбран Javascript, а конкретно — связка в виде NodeJS, React+Redux, React-Native (с обменом между ними через GraphQL). Это позволило использовать один язык для сервера, клиента и мобильного приложения. Прежде с перечисленными технологиями (кроме Javascript) я вплотную не сталкивался, поэтому статья во многом отражает опыт знакомства с ними.

Я люблю Redux

Именно благодаря Redux для меня началось путешествие в мир удивительного функционального программирования. И это первое из функциональщины, что я попробовал в production. Прошли те времена, когда я использовал DOM для хранения состояния и неуверенно манипулировал им с помощью jQuery.

Redux — это инструмент для управления состоянием приложения (state), который позволяет полностью отделить его от представления (view). Представление (view) становится производным состояния (state), которое предоставляет пользователю интерфейс для его изменения. Действия пользователя (actions) не изменяют состояние (state) напрямую. Вместо этого они попадают в редюсер (reducer). Это такая чистая функция, которая на основе предыдущего состояния (state) и действия (action) генерирует следующее состояние (state). Такой подход к обновлению данных во многом был вдохновлен архитектурой языка программирования Elm и концепцией однонаправленного потока данных Flux. Это, возможно, самая популярная JavaScript-библиотека для иммутабельного изменения состояния из тех, что существуют сегодня. Авторы Redux сфокусировались на решении одной единственной проблемы — управление состоянием приложения (state), и сделали это хорошо. Redux получился достаточно модульным, чтобы работать с различными библиотеками для отображения представления (view).

React использует аналогичный сфокусированный подход для представления (view), имеет эффективный виртуальный DOM, который можно подключить к DOM браузера, нативным мобильным приложениям, VR и прочим платформам.

Что бы создавать надежные, функциональные и легко отлаживаемые web-приложения, можно использовать React и Redux. Правда, потребуются вспомогательные библиотеки вроде react-redux и куча boilerplate-кода. А можно попробовать Hyperapp.

Шаблоны проектирования, которые возникли и развились в экосистеме React за время её существования, улучшают читабельность и чистоту кода, облегчают повторное использование компонентов.

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

Сообществу React понадобилось около двух лет для того, чтобы выработать несколько идей, которые теперь стали популярными. Тут можно отметить переход с React.createClass к классам ES6 и к чистым функциональным компонентам, отказ от миксинов и упрощение API. Теперь, учитывая то, что число React-разработчиков постоянно растёт, то, что в развитие этого проекта вкладываются серьёзные силы, можно наблюдать эволюцию нескольких интересных шаблонов проектирования. Этим шаблонам и посвящён данный материал.

Кент С. Доддс, автор материала, перевод которого мы публикуем сегодня, говорит, что недавно группа программистов, с которыми он должен был провести тренинг по React, заинтересовалась шаблоном «render props», который ещё называют шаблоном «функция как потомок» (в разных публикациях его упоминают как «children as a function» или «function as child»). Документация по React определяет «render prop» как простую технику передачи кода между компонентами React с использованием свойства, значением которого является функция. Компонент, использующий render prop, принимает функцию, которая возвращает элемент React. Этот компонент вызывает данную функцию вместо реализации собственной логики рендеринга. Кент рекомендует тем, кто не знаком с шаблоном render prop, почитать этот материал и посмотреть это видео, а потом уже читать дальше.

В предыдущей статье был рассмотрен простой проект универсального приложения на React.js, в котором используются только стандартные средства и фрагменты кода из официальной документации React.js. Но этого недостаточно для удобной разработки. Нужно сформировать окружение так, чтобы были стандартные возможности (например «горячая» перегрузка компонентов) в равной степени как для серверной, так и для клиентской части фронтенда.

Сегодня мы публикуем перевод материала Нейта Ванга, создателя Rekit. Здесь он рассказывает о новом стабильном релизе системы, Rekit Studio. Это — полноценная IDE для разработки приложений, созданных с использованием технологий React, Redux и React Router. Он говорит, что его команда создаёт с помощью Rekit сложные веб-приложения уже больше года.

Предыдущая версия Rekit Studio называлась Rekit Portal. Она не поддерживала возможностей по редактированию кода. Теперь, благодаря редактору Monaco Editor, того, который используется в VS Code, и благодаря замечательному средству для форматирования кода prettier, Rekit Studio позволяет удобно работать с кодом. Именно поэтому в названии системы появилось слово «studio».

Rekit Studio

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

По традиции было три спикера — фрилансер, контуровец и злой марсианин. Вот что мы обсуждали:

В прошлой статье рассматривалась библиотека Next.js, которая позволяет разрабатывать универсальные приложения «из коробки». В обсуждении статьи были озвучены существенные недостатки этой библиотеки. Судя по тому, что https://github.com/zeit/next.js/issues/88 бурно обсуждается с октября 2016 года, решения проблемы в ближайшее время не будет.

Поэтому, предлагаю ознакомится с современным состоянием «экосистемы» React.js, т.к. на сегодняшний день все, что делает Next.js, и даже больше, можно сделать при помощи сравнительно простых приемов. Есть, конечно, и готовые заготовки проектов. Например, мне очень нравится проект, который, к сожалению, базируется на неактульной версии роутера. И очень актуальный, хотя не такой «заслуженный» проект.

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

Итак продолжаем развивать observer-паттерн. В предыдущей статье от старого и очень простого паттерна "observer" маленькими шагами мы пришли к mobx и написали его мини-версию. В этой статье мы напишем полноценную версию mobx которая реализует алгоритм обновления зависимостей в правильном порядке для избежания ненужных вычислений. Надо сказать что попытки описать этот алгоритм на хабре предпринимались и раньше в статьях товарища vintage про атомы тут, тут, и тут но там не описан в полной мере последний "правильный" порядок обновления о чем и будет речь в этой статье.

О производительности react

React не зря считается очень производительным фреймворком. Он позволяет создавать быстрые динамические страницы с большим количеством элементов.

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

Паттерн "observer" известен наверное с момента появления самого ооп. Упрощенно можно представить что есть объект который хранит список слушателей и имеет метод "добавить", "удалить" и "оповестить", а внешний код либо подписывается либо оповещает подписчиков

class Observable {
  listeners = new Set();
  subscribe(listener){
    this.listeners.add(listener)
  }
  unsubscribe(listener){
    this.listeners.delete(listener)
  }
  notify(){
    for(const listener of this.listeners){
       listener();
    }
  }
}

В redux-е этот паттерн применяется без всяких изменений  — пакет "react-redux" предоставляет функцию connect которая оборачивает компонент и при вызове componentDidMount вызовет subscribe() метод у Observable, при вызове componentWillUnmount()  вызовет  unsubscribе() а dispatch() просто вызовет метод trigger() который в цикле вызовет всех слушателей где каждый в свою очередь вызовет mapStateToProps() и потом в зависимости от того изменилось ли значение  —  вызовет setState() на самом компоненте. Все очень просто, но платой за такую простоту реализации является необходимость работать с состоянием иммутабельно и нормализировать данные а при изменении отдельного объекта или даже одного свойства оповещать абсолютно всех подписчиков-компонентов даже если они никак не зависят от той измененной части состояния и при этом в компоненте-подписчике необходимо явно указывать от каких частей стора он зависит внутри mapStateToProps()

React 16.3-alpha опубликован в npm, его уже можно загружать и использовать. Сегодня мы поговорим о самых крупных и интересных нововведениях этого релиза. В частности, речь пойдёт об API Context, о новых методах жизненного цикла, о статическом методе getDerivedStateFromProps, о компонентах StrictMode и AsyncMode, а также об обновлённых инструментах разработчика React.

Привет.

У многих frontend-разработчиков бытует мнение, что технология VDOM, которая, в частности, используется в React.js, работает как черный ящик. Так же на просторах npm есть куча библиотек, реализующих эту технологию, однако вот как по мне — так в них черт ногу сломит. Сама тема VDOM-а меня заинтересовала некоторое время назад и я начал экспериментировать наощупь, сам. В конечном итоге все кончилось тем, что я сделал свою реализацию VDOM-а и встроил в свой фрейморк для датагридов (о нём я как-нибудь напишу). Это оказалось не просто, а очень просто и в этой статье я детально объясню что к чему, зачем и почему. И как оно работает тоже расскажу. Ныряйте под кат и мы предадимся интересному опыту.

Всем привет! Вы читаете перевод статьи Donavon West “Conditional Rendering in React using Ternaries and Logical AND”



Существуют несколько способов заставить React рендерить то, что вам нужно. Вы можете использовать традиционный оператор if или switch. В этой статье мы рассмотрим этим способам альтернативу. Будьте осторожны: она несет некоторые сюрпризами, с которыми стоит быть поаккуратнее.

В четверг 8 февраля в 19:00 в коворкинге «Соль» пройдет первая в 2018 году встреча UralJS. Разберемся, почему в Контуре TypeScript победил Flow, послушаем рецепты оптимизации от Лёши Иванова — злого марсианина и члена программного комитета Fronttalks, и поспорим, что круче: функциональщина или ООП.

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

За 2017 год мы провели 5 митапов. Обсуждали, что делать, если маленький пет-проект привлечет миллион пользователей, рассказывали, какой классный Vue и тут же бомбили по этому поводу, разбирались с интернационализацией и восхищались потокам в JS. Летом мы попробовали другие форматы. Андрей Старовойт из JetBrains сделал большой доклад о том, как разработчики WebStorm выбирают технологии для поддержки. Вместе кодили на выходных — щупали Ангуляр и решали одну и ту же задачу пять раз с разными партнерами и ограничениями.

Что будет на этот раз:

Привет, Хабр! Представляю вашему вниманию перевод статьи Samer Buna «React.js Frequently Faced Problems».

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

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

На самом деле, если вы сконцентрируетесь на одной вещи, например на создании сайта на простейшем HTML/CSS/JavaScript без библиотек, а потом добавите фреймворк по типу React’а, ваш путь от новичка до профессионала пройдет гораздо удобнее и приятнее.

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

Когда разработчик проводит code review, ему редко хватает времени вникнуть в каждую строку: приходится быстро продумывать различные ситуации, в которых этот код может не работать. При анализе существует несколько моментов, на которые стоит обращать внимание, чтобы быстро понять, как именно код работает. Подсмотрели у Nirmalya Ghosh несколько приемов, как сделать javascript-код изящнее при создании компонентов с помощью библиотеки React. Хотя у нас есть свои особенности разработки в ЕФС, о которых вы можете прочитать в этой статье, некоторые из описанных под катом приемов мы находим интересными. Читаем и обсуждаем в комментариях!

В прошлом году мы рассказывали, как устроен фронтенд в Программе «Единая фронтальная система», о библиотеке элементов и нашем подходе к переиспользованию UI компонентов. Сегодня предлагаем сравнить несколько подходов к разработке React-компонентов, спасибо Cory House за отличный материал!