В сегодняшней части перевода учебного курса по React вашему вниманию будет представлен обзор методов жизненного цикла компонентов.



→ Часть 1: обзор курса, причины популярности React, ReactDOM и JSX
→ Часть 2: функциональные компоненты
→ Часть 3: файлы компонентов, структура проектов
→ Часть 4: родительские и дочерние компоненты
→ Часть 5: начало работы над TODO-приложением, основы стилизации
→ Часть 6: о некоторых особенностях курса, JSX и JavaScript
→ Часть 7: встроенные стили
→ Часть 8: продолжение работы над TODO-приложением, знакомство со свойствами компонентов
→ Часть 9: свойства компонентов
→ Часть 10: практикум по работе со свойствами компонентов и стилизации
→ Часть 11: динамическое формирование разметки и метод массивов map
→ Часть 12: практикум, третий этап работы над TODO-приложением
→ Часть 13: компоненты, основанные на классах
→ Часть 14: практикум по компонентам, основанным на классах, состояние компонентов
→ Часть 15: практикумы по работе с состоянием компонентов
→ Часть 16: четвёртый этап работы над TODO-приложением, обработка событий
→ Часть 17: пятый этап работы над TODO-приложением, модификация состояния компонентов
→ Часть 18: шестой этап работы над TODO-приложением
→ Часть 19: методы жизненного цикла компонентов
→ Часть 20: первое занятие по условному рендерингу
→ Часть 21: второе занятие и практикум по условному рендерингу
→ Часть 22: седьмой этап работы над TODO-приложением, загрузка данных из внешних источников
→ Часть 23: первое занятие по работе с формами
→ Часть 24: второе занятие по работе с формами
→ Часть 25: практикум по работе с формами
→ Часть 26: архитектура приложений, паттерн Container/Component
→ Часть 27: курсовой проект

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



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

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



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

Недавно мы публиковали материал о методологии SOLID. Сегодня мы представляем вашему вниманию перевод статьи, которая посвящена применению принципов SOLID при разработке приложений с использованием популярной библиотеки React.



Автор статьи говорит, что здесь, ради краткости, он не показывает полную реализацию некоторых компонентов.

Автор материала, перевод которого мы сегодня публикуем, говорит, что входит в команду мессенджера Hike, которая занимается новыми возможностями приложения. Цель этой команды заключается в том, чтобы воплощать в реальность и исследовать идеи, которые могут понравиться пользователям. Это означает, что действовать разработчикам нужно оперативно, и что им приходится часто вносить изменения в исследуемые ими новшества, которые направлены на то, чтобы сделать работу пользователей как можно более удобной и приятной. Они предпочитают проводить свои эксперименты с применением React Native, так как эта библиотека ускоряет разработку и позволяет использовать один и тот же код на разных платформах. Кроме того, они пользуются библиотекой Redux.

Сегодня мы публикуем вторую часть перевода статьи, которая содержит набор рекомендаций для Angular-разработчиков. В предыдущей части были представлены 11 советов, в этой мы рассмотрим ещё столько же.

В последнее время микросервисные архитектуры пользуются определённой популярностью. От того, как взаимодействуют микросервисы, может зависеть производительность и масштабируемость решений, основанных на них. Это взаимодействие может быть синхронным или асинхронным. В материале, перевод которого мы представляем вашему вниманию сегодня, рассматриваются синхронные методы взаимодействия микросервисов. А именно, речь пойдёт об исследовании двух технологий: HTTP/1.1 и gRPC. Первая технология представлена стандартными HTTP-вызовами. Вторая основана на использовании высокопроизводительного RPC-фреймворка от Google. Автор материала предлагает взглянуть на код, необходимый для реализации взаимодействия микросервисов с использованием HTTP/1.1 и gRPC, провести замеры производительности, и выбрать технологию, которая позволяет организовать обмен данными между микросервисами наилучшим образом.

Области видимости в JavaScript всегда были непростой темой, особенно в сравнении с более строго организованными языками, такими, как C и Java. В течение многих лет области видимости в JS особенно широко не обсуждались, так как в языке попросту не было средств, которые позволяли бы существенно повлиять на сложившуюся ситуацию. Но в ECMAScript 6 появились некоторые новые возможности, которые позволяют разработчикам лучше контролировать области видимости переменных. Эти возможности в наши дни уже очень хорошо поддерживают браузеры, они вполне доступны для большинства разработчиков. Однако новые ключевые слова для объявления переменных, учитывая ещё и то, что старое ключевое слово var никуда не делось, означают не только новые возможности, но и появление новых вопросов. Когда использовать ключевые слова let и const? Как они себя ведут? В каких ситуациях всё ещё актуально ключевое слово var? Материал, перевод которого мы сегодня публикуем, направлен на исследование проблемы областей видимости переменных в JavaScript.

«Я думаю, что компиляторы — это очень интересно», — говорит Ури Шейкед, автор материала, перевод которого мы сегодня публикуем. В прошлом году он написал статью, в которой шла речь о реверс-инжиниринге компилятора Angular и об имитации некоторых этапов процесса компиляции, помогающей понять особенности внутреннего устройства этого механизма. Надо отметить, что обычно то, о чём автор этого материала говорит как о «компиляторе», называют «движком рендеринга».

Когда Ури услышал о том, что вышла новая версия компилятора Angular, названная Ivy, он тут же захотел рассмотреть её поближе и узнать, что в ней изменилось по сравнению со старой версией. Тут, так же, как и раньше, на вход компилятора поступают шаблоны и компоненты, созданные средствами Angular, которые преобразуются в обычный код на HTML и JavaScript, понятный Chrome и другим браузерам.



Если сравнить новую версию компилятора с предыдущей, то окажется, что Ivy использует алгоритм tree-shaking. Это означает, что компилятор автоматически удаляет неиспользуемые фрагменты кода (это относится и к коду Angular), уменьшая размер бандлов проектов. Ещё одно улучшение касается того, что теперь каждый файл компилируется самостоятельно, что уменьшает время повторной компиляции. Если в двух словах, то, благодаря новому компилятору мы получаем сборки меньших размеров, ускоренную повторную компиляцию проектов более простой готовый код.

Понимание того, как работает компилятор, интересно и само по себе (по крайней мере, автор материала на это надеется), но это, кроме того, помогает лучше понять внутренние механизмы Angular. Это ведёт к совершенствованию навыков «Angular-мышления», что, в свою очередь, позволяет более эффективно использовать этот фреймворк для веб-разработки.

Кстати, знаете, почему новый компилятор назвали Ivy? Дело в том, что это слово звучит как сочетание букв «IV», прочитанное вслух, которое представляет число 4, записанное римскими цифрами. «4» — это четвёртое поколение компиляторов Angular.

Совсем недавно вышла версия 10.5.0 платформы Node.js. Одной из её главных возможностей стала впервые добавленная в Node.js поддержка работы с потоками, пока носящая статус экспериментальной. Этот факт особенно интересен в свете того, что данная возможность теперь есть у платформы, адепты которой всегда гордились тем, что потоки ей, благодаря фантастической асинхронной подсистеме ввода-вывода, не нужны. Однако, поддержка потоков в Node.js всё же появилась. С чего бы это? Кому и зачем они могут пригодиться?



Если в двух словах, то нужно это для того, чтобы платформа Node.js могла бы достигнуть новых высот в тех областях, в которых раньше она показывала не самые замечательные результаты. Речь идёт о выполнении вычислений, интенсивно использующих ресурсы процессора. Это, в основном, является причиной того, что Node.js не отличается сильными позициями в таких сферах, как искусственный интеллект, машинное обучение, обработка больших объёмов данных. На то, чтобы позволить Node.js хорошо показать себя в решении подобных задач, направлено немало усилий, но тут эта платформа пока выглядит куда скромнее, чем, например, в деле разработки микросервисов.

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

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

Фреймворк Bootstrap — это свободный набор инструментов для создания интерфейсов сайтов и веб-приложений. Его возможности ориентированы исключительно на фронтенд-разработку. Bootstrap — проект весьма популярный, о чём, например, говорит то, что он занимает (по состоянию на начало марта 2018-го года) второе место по количеству звёзд на GitHub.

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

Автор материала, перевод которого мы публикуем сегодня, Билл Соро, говорит, что написал первые строки кода на JavaScript вскоре после появления этого языка. По его словам, если тогда ему сказали бы, что однажды он выпустит серию статей об элегантных шаблонах проектирования в JavaScript, он умер бы со смеху. Тогда он воспринимал JS как странный маленький язык, писанину на котором можно было с большой натяжкой называть «программированием».

Но за 20 лет многое изменилось. Теперь Билл воспринимает JavaScript таким, каким видел его Дуглас Крокфорд, когда работал над книгой «JavaScript. Сильные стороны»: красивым, элегантным и выразительным динамическим языком программирования.



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

Иммутабельные структуры данных, реализующие методику совместного использования неизменяемых фрагментов информации (structural sharing), выглядят как отличная технология для хранения состояния приложения. Особенно — в комбинации с архитектурой, основанной на событиях. Однако за всё надо платить. В языке вроде JavaScript, где возможности по обеспечению иммутабельности не являются стандартными, создание нового состояния из предыдущего — это скучная, шаблонная задача. Для того чтобы осознать масштаб проблемы, и силы, брошенные на её решение, взгляните на эту страницу, где имеется список из 67 пакетов, предназначенных для упрощения работы с иммутабельными структурами данных в Redux.



К сожалению, все эти библиотеки не решают основную проблему: отсутствие поддержки иммутабельности языком. Например, в то время как update-in — это красивая конструкция языка ClojureScript, любые аналогичные идеи, реализованные на JavaScript, будут, в основном, полагаться на неудобные строковые пути. Такой подход подвержен ошибкам, он усложняет проверку типов и требует изучения особого API.

Как решить проблему иммутабельности в JavaScript? Пожалуй, стоит прекратить сражаться с языком, воспользовавшись вместо этого его возможностями. Такой подход позволит не терять удобство и простоту, которые дают стандартные структуры данных. Собственно говоря, библиотека immer, о которой мы сегодня поговорим, направлена то, чтобы использовать стандартные средства JS при работе с иммутабельными состояниями.

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


Мощная картинка для привлечения внимания :) Осторожно, может засосать!

Но, на самом деле, регулярные выражения — это мощный инструмент, который может помочь вам сэкономить уйму времени. В этом материале мы рассмотрим основы регулярных выражений в JavaScript.

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

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


Картинка по запросу «области видимости». Извините, если вызвали приступ ностальгии )

Элементарное определение области видимости выглядит так: это область, где компилятор ищет переменные и функции, когда они ему нужны. Думаете, что звучит это слишком просто? Предлагаем разобраться вместе.

Bash-скрипты: начало
Bash-скрипты, часть 2: циклы
Bash-скрипты, часть 3: параметры и ключи командной строки
Bash-скрипты, часть 4: ввод и вывод
Bash-скрипты, часть 5: сигналы, фоновые задачи, управление сценариями
Bash-скрипты, часть 6: функции и разработка библиотек
Bash-скрипты, часть 7: sed и обработка текстов
Bash-скрипты, часть 8: язык обработки данных awk
Bash-скрипты, часть 9: регулярные выражения
Bash-скрипты, часть 10: практические примеры
Bash-скрипты, часть 11: expect и автоматизация интерактивных утилит

В прошлый раз, в третьей части этой серии материалов по bash-скриптам, мы говорили о параметрах командной строки и ключах. Наша сегодняшняя тема — ввод, вывод, и всё, что с этим связано.

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

Когда анимация способна улучшить впечатления пользователя от работы со страницами? Что именно стоит «оживить» для того, чтобы взаимодействие с ресурсом стало бы более удобным, понятным, увлекательным?

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



Мне довелось поучаствовать в работе над этим проектом в качестве консультанта. Посещаемость ресурса составляет порядка 200 миллионов уникальных пользователей в месяц. Такая популярность означает и высокий уровень рисков в сфере информационной безопасности, в частности, это риск подвергнуться различным видам атак, самые распространённые среди которых – DDoS. Организация, которую называть не буду, внедрила широкий спектр решений для предотвращения воздействия подобных атак на работоспособность сервиса.