Привет Хабр! Предлагаю вашему вниманию свободный перевод статьи «React Patterns» Майкла Чана, с некоторыми моими примечаниями и дополнениями.

Прежде всего хотел бы поблагодарить автора оригинального текста. В переводе я использовал понятие «Простой компонент» как обозначение Stateless Component aka Dump Component aka Component vs Container
Конструктивная критика, а так же альтернативные паттерны и фичи React приветствуются в комментах.

Оглавление

• Простые компоненты — Stateless function
• JSX распределение атрибутов — JSX Spread Attributes
• Деструктуризация аргументов — Destructuring Arguments
• Условный рендеринг — Conditional Rendering
• Типы потомков — Children Types
• Массив как потомок — Array as children
• Функция как потомок — Function as children
• Функция в render — Render callback
• Проход по потомкам — Children pass-through
• Перенаправление компонента — Proxy component
• Стилизация компонентов — Style component
• Переключатель событий — Event switch
• Компонент-макет — Layout component
• Компонент-контейнер — Container component
• Компоненты высшего порядка — Higher-order component

Поехали!

Введение

Вот не люблю я изобретать велосипед и статью я бы эту не написал, но пришлось. Про REST сказано уже довольно много. Многие поставщики веб служб готовы клясться, что их службы являются RESTful. Во время собеседования вы точно услышите хотя бы несколько вопросов про REST, независимо от того это собеседования для бэкенд, мобайл или фронтенд разработчика. Я вот помню как-то во время одного собеседования меня задали такой вопрос: «Вот вы написали в своем резюме, что знайте REST․ Ответьте пожалуйста, какой HTTP код вы получите, если при запросе к RESTful сервису ресурс не найден?». Ответ 404 был принят единогласно. Если честно, я так и не понял, как этот вопрос помог понять знаю ли я REST или нет, но одно могу уверенно сказать: REST понимают далеко не все. Вот некоторые вопросы, которые мучали меня долгое время:

1. Зачем REST стал таким трендовым? Это архитектура была же предложена еще в 2000 году?
2. Что я получу если моя служба будет RESTful?
3. Как определить является ли служба RESTful или нет?
4. Как правильно должны создаваться URL REST служб?
5. Какие http методы и коды должны быть использованы в RESTful службе?

Если вы не можете дать исчерпывающего ответа хотя бы на один из этих вопросов, то продолжайте чтение. Если вы можете однозначно ответить на все эти вопросы, можете привести формат правильного URL, считайте, что GET, POST, PUT, DELETE обязательно должны соответствовать CRUD операциям с ресурсами, то вам обязательно надо продолжать чтение.

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

Если вы — активный пользователь Интернета (а это, скорее всего, именно так), вы постоянно используете кэширование, но можете и не знать «закулисье»: когда и как оно работает.

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

При кэшировании время загрузки страницы снижается с 2 секунд до 1 секунды… что не очень впечатляет, верно? Но без него не обойтись, когда приходится обрабатывать запросы от большого числа пользователей.

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

Чтобы понять мое объяснение, нужно немного знать об основах работы веб-серверов. Приступим!

Переведено в Alconost

Что это такое?

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

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



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

Сегодня, в переводе одиннадцатой части серии материалов, посвящённых JavaScript, мы поговорим о подсистемах браузера, ответственных за рендеринг веб-страниц. Они играют ключевую роль в деле преобразования описаний документов, выполненных с помощью HTML и CSS, в то, что мы видим на экране.



Автор материала говорит, что в компании SessionStack приходится уделять рендерингу огромное внимание. В этой статье он поделится советами, касающимися оптимизации веб-страниц с учётом особенностей их визуализации.

Здесь вы не увидите ни строчки кода. Мы поговорим об обычных людях — о наших пользователях, точнее о том, как сообщать им, если в системе возникла какая-то непредвиденная ситуация.


В основе статьи доклад Антонины Хисаметдиновой с Heisenbug 2017 Moscow, которая занимается проектировкой пользовательских интерфейсов в компании Собака Павлова.

Кроме того, на Медиуме есть цикл статей «Руководство по проектированию ошибок». Цикл еще не дописан до конца, но дает более полную и цельную картину по теме статьи.

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

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

Данный пост — это третья часть серии статей о функциональном программировании под названием «Мышление в стиле Ramda».

1. Первые шаги
2. Сочетаем функции
3. Частичное применение (каррирование)
4. Декларативное программирование
5. Бесточечная нотация
6. Неизменяемость и объекты
7. Неизменяемость и массивы
8. Линзы
9. Заключение

Во второй части мы говорили о сочетании функций различным образом, закончив на функциях compose и pipe, которые позволяют использовать серию функций в режиме конвеера.

В том посте мы рассмотрели простые конвееры функций, которые принимают лишь один аргумент. Но что если мы хотим использовать такие функции, которые принимают больше одного аргумента?

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

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

Даже существует мнение, что сложно тестируемый код — претендент на переписывание.

Цель данной статьи — помочь в написании unit тестов для Angular 5+ приложения. Пусть это будет увлекательный процесс, а не головная боль.

Пост содержит перевод статьи «Why Ramda?», которую подготовил один из контрибьютеров Скот Сайет. Статья была опубликована 10 Июня 2014 года на сайте и рассказывает о том почему стоит обратить своё внимание на библиотеку Ramda и функциональное программирование в целом.

Примечание переводчика

В связи с тем, что статья была написана в 2014 году, некоторые примеры устарели и не работали с последней версией библиотеки. Поэтому они были адаптированы под последнюю версию Ramda@0.25.0.

Почему Ramda?

Когда-то давно buzzdecafe представил миру Ramda, в тот же момент сообщество поделилось на два лагеря.

Ведущий разработчик Яндекс.Деньги Андрей Мелихов (также редактор/переводчик сообщества devSchacht) на примере движка V8 рассказывает о том, как и через какие стадии проходит программа, прежде чем превращается в машинный код, и зачем на самом деле нужен новый компилятор.



Материал подготовлен на основе доклада автора на конференции HolyJS 2017, которая проходила в Санкт-Петербурге 2-3 июня. Презентацию в pdf можно найти по этой ссылке.

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

Веб в наши дни двигается очень быстро и мы все это знаем. Сегодня Реактивное Программирование является одной из самых горячих тем в веб-разработке и с такими фреймворками, как Angular или React, она стала гораздо более популярной, особенно в современном мире JavaScript. В сообществе произошел массовый переход от императивных парадигм программирования к функциональным реактивным парадигмам. Тем не менее, многие разработчики пытаются с этим бороться и часто перегружены его сложностью (большой API), фундаментальным сдвигом в мышлении (от императивного к декларативному) и множеством понятий.

Хотя это не самая простая тема, но как только мы сумеем ее понять, мы спросим себя, как мы могли без нее жить?

Представляю вашему вниманию типичные варианты использования Observable объектов в компонентах и сервисах Angular 4.

Подписка на параметр роутера и мапинг на другой Observable

Задача: При открытии страницы example.com/#/users/42, по userId получить данные пользователя.

Решение: При инициализации компоненты UserDetailsComponent мы подписываемся на параметры роутера. То есть если userId будет меняться — будер срабатывать наша подписка. Используя полученный userId, мы из сервиса userService получаем Observable с данными пользователя.

// UserDetailsComponent

ngOnInit() {
  this.route.params
    .pluck('userId') // получаем userId из параметров
    .switchMap(userId => this.userService.getData(userId))
    .subscribe(user => this.user = user);
}