Сегодня поговорим о том, как наладить взаимодействие React-приложения с сервером, используя Socket.io, добившись при этом высокой скорости отклика приложения на события, которые генерирует сервер. Примеры кода рассчитаны на React или React Native. При этом концепции, изложенные здесь, универсальны, их можно применить и при разработке с использованием других фронтенд-фреймворков, таких, как Vue или Angular.



Итак, нам нужно, чтобы клиентское приложение реагировало на события, генерируемые на сервере. Обычно в подобных случаях речь идёт о приложениях реального времени. В таком сценарии сервер передаёт клиенту свежие данные по мере их появления. После того, как между клиентом и сервером будет установлено соединение, сервер, не полагаясь на запросы клиента, самостоятельно инициирует передачу данных.

Когда-то давно я много играл в компьютерные игры (в основном — соревновательные), но несколько лет назад открыл для себя жанр Survival Game (выживалки «в простонародье»). Поиграв в несколько разных игр (ARK, Conan Exiles и другие, менее находящиеся на слуху), я понял, что это все же не совсем то, чего бы мне хотелось.

Как и многие ребята, в детстве (прошедшем еще в большой и сильной стране из 4 букв) я зачитывался книгами пиратской тематики: Одиссея Капитана Блада, Остров Сокровищ, да даже Гулливер, в какой-то степени, повлиял на мое мировоззрение и отношение к теме дальних странствий и опасных морских приключений.

И вот примерно полгода назад звезды сошлись. Я решил объединить свои страсти к пиратской тематике и компьютерным играм из жанра «выживалок». Я начал делать свою игру в этом сеттинге, с преферансом и куртизанками.

Новые фичи восьмой редакции EcmaScript.



EcmaScript 8 или EcmaScript 2017 был официально выпущен комитетом TC39 в конце июня. Кажется, мы много говорили о EcmaScript в прошлом году и это было не просто так. На данный момент стандартом является выпуск новой спецификации раз в год. ES6 был опубликован в 2015, а ES7 в 2016, но кто-нибудь помнит, когда вышел ES5? Это было в 2009 году, до волшебного взлета JavaScript.

В апреле состоялась конференция для разработчиков мобильных приложений Mobius. На мероприятии Программу «Единая фронтальная система» представляли лидеры команды мобильной разработки Дмитрий Евстратов и Даниил Калинцев (Отдел развития платформы ЕФС АО СберТех) с рассказом о масштабируемом VIP архитектурном дизайне для компонентов с использованием React Native.
Для тех, кому интересна мобильная разработка Программы ЕФС, кто не присутствовал или не успел пообщаться с ребятами на конференции, мы подготовили короткое интервью. В комментариях к нему вы можете задать вопрос спикерам напрямую.
 

 

Я учусь пилотировать легкие самолеты. Это отвлекает меня от компьютеров. Недавно мне никак не удавалось удержать Сессну-150 на малой высоте, когда мы приближались к аэропорту Бристоля. Меня буквально засосало в облако восходящим потоком. Мой летный инструктор сказал: «Это не ваша вина, но ваша проблема». Он имел в виду, что я обязана была удерживать высоту, пусть даже что-то работало против меня. Мне нужно было узнать, что бывает такая ситуация, и научиться справляться с ней при пилотировании.

Уже после приземления я подумала, что фраза «это не ваша вина, но ваша проблема» отлично подходит практически к любым ситуациям. В этой статье я раскрываю тему поддержки старых браузеров при использовании новых технологий наподобие CSS Grid Layout. Мы, разработчики, часто робеем при обсуждении браузерной поддержки с заказчиками и коллегами, как будто это мы виноваты в том, что сайты не выглядят в IE9 в точности так же, как в новейших Firefox или Chrome. Пора нам уже принять, что это не наша вина. Но обязанность справиться с этим как следует, с пользой для каждого — во многом наша проблема.

Мы, программисты, иногда почему-то сходим с ума. Причём по каким-то совершенно нелепым причинам. Нам нравится думать о себе, как о супер-рациональных людях, но когда дело доходит до выбора ключевой технологии нового продукта, мы погружаемся в какое-то безумие. Вдруг оказывается, что кто-то слышал что-то об одной классной вещи, а его коллега читал комментарий о другой на Хабре, а третий человек видел пост в блоге о ещё чём-то похожем… и вот мы уже пребываем в полнейшем ступоре, беспомощно барахтаясь в попытках выбора между совершенно противоположными по своей сути системами, уже и забыв, что мы вообще пытаемся выбрать и почему.

Рациональные люди не принимают решения таким образом. Но именно так программисты часто решают использовать что-то вроде MapReduce.

Вот как комментировал этот выбор Joe Hellerstein своим студентам (на 54-той минуте):

Дело в том, что в мире сейчас есть где-то 5 компаний, обрабатывающие данные подобных объёмов. Все остальные гоняют все эти данные туда-сюда, добиваясь отказоустойчивости, которая им на самом деле не нужна. Люди страдают гигантоманией и гугломанией где-то с середины 2000-ых годов: «мы сделаем всё так, как делает Google, ведь мы же строим один из крупнейших (в будущем) сервисов по обработке данных в мире!»

Сколько этажей в вашем датацентре? Google сейчас строит четырёхэтажные, как вот этот в Оклахоме.

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

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

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

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

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

Возникла задача попробовать таки сделанное небольшое приложение протестировать. Ну, всякие сервисы вполне в привычном стиле можно тестировать каким-нибудь jasmine. С компонентами сложнее, если хочется тоже остаться в рамках концепции юнит-тестирования. По идее тестировать принято контракты, а не реализацию, то есть тесты должны иметь вид «ткнули кнопку — приложение попыталось сделать то-то».

Ну все, завязываю со вступлением.

Предыстория

Привет, Хабр. В начале зимы 2016 года я снова стал одинок. Спустя какое-то время я решил завести себе профиль в Tinder. Всё бы ничего, но постепенно стала накапливаться усталость из-за невозможности нормально печатать на физической клавиатуре. Мне виделось несколько решений этой проблемы:

• Смириться и продолжать использовать официальное приложение для смартфона
• Использовать BlueStacks с официальным приложением на Android
• Использовать существующие клиенты для десктопа (Tinder++)
• Написать свой

Первый вариант меня не устраивал из-за принципиального превосходства реальной клавиатуры над экранной. Второй вариант не подходил из-за того, что всё-таки это было бы приложение, не оптимизированное под десктоп. Третий вариант был всем хорош кроме дизайна, багов, и малой активности в репозитории. Позже Tinder++ получил письмо от юристов Tinder и проект был и вовсе свёрнут. Таким образом, лично для меня выбор был очевиден.

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

Если есть время, и заказчик хочет чуть большего, то гуглят реализацию наиболее популярного алгоритма (коим является «расстояние Левенштейна») и вписывают его.

В данной статье, я опишу сильно доработанный алгоритм, основанный, правда, на расстояния Левенштейна, и приведу примеры кода на C# нечеткого поиска по названиям, например: кафе, ресторанов или неких сервисов… В общем всё, что можно перечислить и имеет от одного до нескольких слов в своем составе:

«Яндекс», «Mail», «ProjectArmata», «world of tanks», «world of warships», «world of warplanes» и т.д.

Возможно, вы уже слышали об идущем сейчас ICO «Полибиуса». Возможно, вы даже знаете, что такое ICO — модель краудфандинга, при которой проект выпускает в продажу токены, дающие их покупателям некоторые привилегии. Не будем далеко ходить за примерами: токены «Полибиуса» гарантируют долю прибыли компании, 20% которых будут идти их владельцам.



По сути, токен — это смарт-контракт. В случае «Полибиуса» — смарт-контракт на блокчейне Ethereum. Конечно, смарт-контракты можно писать не только на «Эфире», но он — самый популярный, известный и пользующийся наибольшим доверием. Поэтому выбором сильно мучиться не пришлось.

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

Введение

Я потратил много времени, обсуждая онлайн паттерны использования Redux, была ли это помощь тем, кто изучает Redux в Reactiflux каналах, дискуссии о возможных изменениях в API библиотеки Redux на Github'е, или обсуждение различных аспектов Redux'а в комментариях к тредам на Reddit'е или HN (HackerNews). С течением времени, я выработал свое собственное мнение о том, что представляет собой хороший, идиоматичный Redux код, и я хотел бы поделиться некоторыми из этих мыслей. Несмотря на мой статус мейнтейнера Redux'а, это всего лишь мнения, но я предпочитаю думать, что они являются достаточно хорошими подходами.

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

Несмотря на эту простоту, или, возможно, вследствие ее, существует широкий спектр походов, мнений и взглядов о том, как использовать Redux. Многие из этих подходов широко расходятся с концепциями и примерами из документации.

В то же время, продолжаются жалобы на то, как Redux «заставляет» вас делать вещи определенными способами. Многие из этих жалоб на самом деле включают концепции связанные с тем, как Redux обычно используется, а не фактическими ограничениями наложенными самой библиотекой Redux. (Например, только в одном недавнем HN треде я видел жалобы: «слишком много шаблонного кода», «константы action'ов и action creator'ы не нужны», «я вынужден редактировать слишком много файлов чтобы добавить одну фичу», «почему я должен переключаться между файлами чтобы добраться до своей логики?», «термины и названия слишком сложны для изучения или запутанны», и слишком много других.)

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

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

Мы хотим создать пакет, который позволит нам избавиться от постоянного создания однотипных reducer'ов и action creator'ов для каждой модели, получаемой по API.

Первая часть — вот эта вот статья. В ней мы создали конфиг для нашего будущего пакета и выяснили, что он должен содержать action creator, middleware и reducer. Приступим к разработке!

В этой статье мы расскажем какие инфраструктурные решения реализуют наши клиенты с применением серверных платформ Dell R730xd и почему цена на аренду этой платформы в европейском дата-центре TierIII+ уровня с отличными каналами связи в Украину и Россию, а также в 9 локациях в США, уже с размещением и коннективностью по цене от $249 / месяц за 2 х Intel Dodeca-Core Xeon E5-2650 v4 128GB DDR4 6x480 SSD 1Gbps стала реальностью. Поделимся возможными вариантами решений на основе этих платформ с применением частных vlan, 10G локальной сети и аппаратных Firewall от СISCO, которые доступны нашим клиентам по запросу. А также, в лучших традициях, предложим бонус в виде бесплатного периода пользования серверами Dell R730xd для читателей Habrahabr.



В последнее время мы получаем всë больше и больше запросов на построение различных корпоративных инфраструктур, и связано это, к сожалению, не столько с тем, что мы предоставляем решения очень высокого качества, сколько с ценой на эти решения и тем уровнем безопасности и верховенства права, который обеспечивается в Нидерландах и США, но увы, зачастую недоступен в Украине и России. Где, к сожалению, подобные решения стоят просто «космических» денег, так как понятие «длинные деньги» чуждо для постсоветских стран в принципе, на фоне других рисков или во все отсутствия необходимой инфраструктуры и уровня сертификации.

И в чем же проблема?

Я начал изучать React и Redux не так давно, но он уже успел изрядно потрепать мне нервы. Буквально над каждым действием приходится задумываться — почти никакие изменения в коде невозможны без того, чтоб что-то оторвать. Чтоб просто получить список постов по API и вывести их, надо, пожалуй, написать не меньше сотни строк кода — создать корневой контейнер, создать store, добавить action для запроса к API, для успешного результата запроса, для неудачного результата запроса, создать action-creators, сматчить action-creators и props, сматчить dispatch и props, написать reducer на каждый action… Ух, продолжать не хочется. И все это мы должны делать заново для каждого веб-приложения — крайне нерациональная трата сил программиста.

Да, можно сказать новичку: "Смотри, тут десяток пакетов, которые могут сделать каждое действие из этого списка вместо тебя. Выбирай и пользуйся!" Но проблема в том, что надо разобраться в настройке и воспользоваться десятком пакетов, позаботившись о том, чтоб они совпадали с версией, которая описана в документации и не вступали друг с другом в конфликты… Слишком сложно. Хочется чего-то проще, такого же простого, как в мире Django, из которого я пришел. Какой-то один пакет, после установки которого в store сами по волшебству складываются все нужные данные — бери и пользуйся.

Ну, я и решил — если такого решения нет, напишу-ка я его сам.

Постановка задачи

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

1. Делать асинхронный GET-запрос к REST API.
2. Анализировать полученные данные и данные, лежащие в store, и, если там не хватает связанных по foreign key данных, делать еще запросы.
3. Складывать полученные данные в store и следить за актуальностью хранящихся данных.

По описанию выходит, что состоять пакет будет из action creator'а, middleware и reducer'а.

Введение

Всем привет! Не так давно мне поступила задача встроить визуальный редактор email в наш сервис внутренней рассылки, ибо людям надоело набирать html руками и компоновать валидные шаблоны для писем. Побродив по интернету, я нашёл 2 редактора, которые, как мне тогда казалось, прекрасно подойдут для этих целей. Ссылки на них приведу в конце топика. Изучив их более внимательно (EmailEditor написан с использованием jQuery, который я в своё время неплохо изучил, а Mosaico был на KnockoutJS, с ним я знаком лишь поверхностно), я остановился на EmailEditor, и снова окунулся в то дерьмо из которого год назад так успешно выбрался с помощью Angular и Ionic, а именно — файлы по 2-3к строк, повсеместное и рандомное изменение DOM различными способами из различных мест и т.д., ну вы меня понимаете).

Потратив больше месяца на попытки пофиксить все баги, запилить нужные нам для рассылки строительные блоки и прочее, я сдался… Решил попробовать Mosaico и даже начал активно изучать Knockout, но проблема в том, что этот монстр (я про Mosaico) был настолько сложно написан, что EmailEditor показался не таким уж и плохим. Плюс ко всему, а точнее минус, у Mosaico практически нет вменяемой документации и если в первом я интуитивно понимал как всё работает и как создать свои блоки, то тут никакая интуиция мне не помогла. Возможно, просто не хватило мозга, терпения и желания разбираться, не знаю, просто гляньте на досуге исходники этих редакторов… А сроки поджимали...

Что же делать?!

Всем привет! Недавно Дэн Абрамов, создатель Redux, оставил довольно массивный комментарий к статье на Medium Things nobody will tell you about React.js, который очень быстро разошёлся популярностью и довольно скоро набрал раза в 3 больше рекомендаций, чем сама статья :)
Собственно, текущая статья является моим переводом его комментария, так как последняя содержит ценные замечания по поводу актуального и будущего состояния React / React Router.
Надеюсь, кому-то это будет полезным.

---

Привет, спасибо за обратную связь! :)

Я ценю, что вы поделились своим неприятным опытом работы с React.

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

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

Введение

Динамические веб приложения (SPA, Single Page Applications) становятся все более популярными. Их использование позволяет упростить и ускорить разработку и поддержку за счет следующий преимуществ:

• не требуется server-side рендеринг;
• сайт — это набор статических файлов (html, js, css, images, fonts), которые лежат на CDN;
• нет затрат на масштабирование frontend;
• код frontend локализован в одном проекте. (Раньше часть кода была на server-side, часть в frontend.);
• уменьшение затрат на разработку backend (только API);
• уменьшение нагрузки на backend (только API запросы);
• возможность вместо собственного backend использовать сервисы типа (https://scaphold.io), микросервисы, lambda.

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

Большой нерешенной проблемой SPA является их полная несовместимость с веб краулерами поисковых систем (индексация сайтов) и социальных сетей (sharing в соц. сетях). На текущий момент краулеры не выполняют на своей стороне javascript и поэтому не могут получить содержимое SPA в виде html кода. В 2015 году Google официально отказался от поддержки выполнения javascript кода на своей стороне.

Twitter Lite и высокопроизводительные прогрессивные веб-приложения на React

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

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