JavaScript *

Представим, что у нас есть приложение на React, в котором можно читать и писать отзывы. Пользователь открыл список отзывов, пролистал его, нажал кнопку «Написать отзыв». Форма написания отзыва открывается в попапе. Пользователь начинает вводить текст, свой email. Вдруг валидация почты срабатывает с ошибкой, которую разработчики забыли обработать. Результат — белый экран. React просто не смог ничего отрендерить из-за этой ошибки в каком-то попапе.

Первая же мысль — не надо было всё уничтожать, список же был не при делах. Чтобы обработать ошибку в render-фазе в React, необходимо использовать Error Boundaries. Почему именно так нужно обрабатывать ошибки — расскажу под катом.

• Заполни заявку на сайте;
• Получи подтверждение от рекрутера;
• Пройди техническое собеседование;
• Прими оффер в течение 48 часов и получи welcome-бонус!

По данным Росстта в среднем житель России имеет доход 35 700 ₽ в месяц. Эта цифра мало что говорит о благосостоянии населения. Если взять двух человек — одного с доходом 70 000 ₽ и 1400 ₽, их средний ежемесячный доход будет равен ровно 35 700 ₽. Чтобы лучше продемонстрировать распределение доходов, я смастерил калькулятор, который позволяет посчитать количество людей с заданным диапазоном дохода и наглядно продемонстрировать их вклад в общий уровень доходов.

В этом посте я расскажу как от довольно скупых данных, которые доступны на сайте Росстата сгенерировать датасет для подробной инфографики.

От переводчика: Этот пост является продолжением поста о реализация паттернов React-компонентов в Ember.js. Автор рассматривает концепцию React-хуков для абстракции логики состояния (stateful logic) и сравнивает ее реализацию с реализацией в Ember. И хотя в экосистеме React эта концепция признана весьма полезной, в Ember.js попытки предложить похожую не нашли особенного отклика. Причина этому - наличие в фреймворке достаточных инструментов для решения этой задачи без использования хуков. О каких инструментах идет речь, вы узнаете из этого материала.

В этом руководстве я объясню необходимые шаги для интеграции веб-компонентов в Angular.

В этой статье мы расскажем, что такое UI KIT, для чего он нужен, и как он сэкономит время и деньги.

В статье мы подойдем к китам, которые сделаны не только дизайнерами, но также переведены в компоненты фронтенд-разработчиками.

Всем привет! Пару месяцев назад у нас возникла задача запилить лендос для нашего онлайн сервиса. Наш стек - Create React App + .Net Core. Погугля немного, мы решили, что хотим запилить лендос на Next JS, но возник вопрос - как это все вместе подружить.
Мы хотели, что бы приложение открывалось по ссылке: yourdomain.com/app, а все остальные ссылки вели бы на лендос.

До HolyJS осталось меньше месяца — пора поведать Хабру, какие именно доклады там будут. Под катом их описания, а тут отметим пару вещей:

— В этот раз шире обычного раскрыта тема производительности. Когда React.memo не ускорит, а замедлит? Почему Solid.JS такой быстрый? Что нужно знать JS-разработчику в современном многоядерном мире?

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

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

Я уже публиковал свою точку зрения, что Progressive Web Applications - это, прежде всего, технология для мобильных устройств. Основная особенность классических web-приложений - это клиент-серверная архитектура, а основная особенность "прогрессивных" web-приложений - возможность работы в offline. Понятно, что это очень сильно разные подходы в архитектуре - "всегда на связи" и "всё своё с собой". Совместить два таких разных подхода в одном приложении "это очень дорого и ни к чему".

Отталкиваясь от этой своей точки зрения, я решил посмотреть текущую статистику по браузерами - какие на данный момент у PWA-приложения возможности стать популярным и на какие браузеры оно должно ориентироваться. Данные для публикации взяты с сайта gs.statcounter.com

Привет, друзья!

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

Основной функционал нашего приложения будет следующим:

• админка с возможностью добавления данных (далее — проекты) путем их набора (ввода) или копирования/вставки, либо путем загрузки файла;
• сохранение проектов на сервере;
• безопасная запись, чтение и удаление файлов на любом уровне вложенности;
• получение названий существующих проектов и их отображение в админке;
• возможность редактирования и удаления проектов;
• унифицированная обработка GET, POST, PUT и DELETE запросов к любому существующему проекту, включая GET-запросы, содержащие параметры и строки запроса;
• обработка специальных параметров строки запроса sort, order, limit и offset;
• и многое другое.

Наша админка будет выглядеть так:

Для быстрой стилизации приложения будет использоваться Bootstrap.

Исходный код проекта.

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

При разработке приложения мы будет придерживаться 2 важных условий:

• формат данных — JSON;
• основная форма данных — массив.

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

Вы готовы? Тогда вперед.

Всем привет! Меня зовут Петр Солопов, я руководитель отдела фронтенд-разработки в SuperJob. Думаю, многие из вас видели популярную серию картинок в интернете про фронтенд и бэкенд: на бекенде всегда какой-то монстр, а на фронте — все мило, летают бабочки. На мой взгляд, это не соответствует действительности и все не так радужно и безоблачно: чего только стоят настройка Webpack, тона зависимостей, особенности фреймворков и многое другое. За подробностями под кат.

От переводчика: Я прототипирую интерфейсы на Ember.js. И всегда испытываю трудности, когда нужно переключиться на React и написать что-нибудь используя этот de facto выбор по-умолчанию в современной фронт-энд разработке. Каждый раз сталкиваешься с трудностями на ровном месте и вынужден думать о том, о чем привык не думать, писать велосипеды. Мне всегда хотелось это как-то выразить и на днях я нашел статью, где автор очень наглядно показывает разницу на кодовых примерах. Представляю вашему вниманию ее перевод.

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

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

Около десяти лет назад сообщество веб-разработчиков впервые начало обсуждать концепцию "Single-Page Application" и искать способы ее реализации. К тому моменту разработка графических интерфейсов уже не являлась чем-то новым и поэтому многие вещи заимствовались у существующих решений и немного адаптировались под специфику браузеров.

Наиболее успешным результатом подобной работы оказался Backbone.js — объектно-ориентированный MVC-фреймворк, который в свое время использовался в BitBucket, Basecamp, Stripe, Airbnb и Trello. Со временем он был полностью вытеснен следующим поколением фреймворков, но...

Что если бы этого не случилось? Как бы тогда выглядела современная разработка веб-интерфейсов?

Развитие языка javascript переносит выполнение кодов на распределенную сеть пользователей и снимает нагрузку с сервера. Это разумный подход. Введение в js ключевых слов class, extends и static дало возможность легко моделировать классами и объектами предметную область проекта. Это замечательно. Следующий вопрос, который необходимо рассмотреть при возрастании сложности js-проекта - это пространство имен. Именно оно позволяет избежать конфликтов с ворохом разнородных js-скриптов. Как показывает практика с этим вопросом почему-то возникли большие сложности.

Даниил Шилов из DINS расскажет, как избежать уязвимостей в web-приложениях еще на этапе написания кода, а Никита Нягу из МойОфис поделится опытом использования Firebase — инструмента, помогающего содержать архитектуру всего проекта в одном месте и облегчающего работу с DevOps.

Регистрация по ссылке. Подробная программа и информация о спикерах — под катом.

Благодаря Paint API из состава Houdini можно не ждать выхода новых возможностей CSS. Шаг за шагом автор этого материала показывает, как написать новое свойство CSS для анимации с фрагментацией. Делимся материалом, пока у нас начинается курс по Frontend-разработке.

У Google появилась замечательная reCAPTCHA v3. Замечательна она тем, что освобождает пользователя от необходимости тыкать по картинкам в поисках светофоров и пожарных гидрантов, при этом вполне успешно анализирует его действия на сайте и оценивает их по шкале от 0 до 1. Чем выше балл, тем качественней наш бот выше вероятность, что пользователь реальный. Обычно выставляют порог равным 0.5.

А что делать, если хочется добра пользователям сайта, но есть у его владельца некая обеспокоенность, что не пропустит невидимая столь ценного реального пользователя, который может и ведет себя странно и подозрительно, но совсем не бот?

Ответ - последовательно использовать капчу обоих версий - не прошел невидимую проверку - появилась видимая капча!