JavaScript *

Эта документация поможет найти компромиссы между различными шаблонами (patterns) React, а также определить, когда использование каждого из них будет наиболее целесообразным. Нижеприведенные шаблоны позволят получить более практичный и многократно используемый код, придерживаясь принципов проектирования, таких как разделение ответственности, DRY (Don’t repeat yourself — не повторяй себя) и повторное использование кода. Некоторые из этих шаблонов помогут решить проблемы, которые возникают в больших React приложениях, таких как пробрасывание (prop drilling) или управление состоянием. Каждый основной шаблон включает пример, размещенный на CodeSandBox.

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

Нормализация. От нее мы или страдаем или пишем собственное решение с множеством проверок на существование сущности в общем хранилище. Попробуем разобраться и решить эту проблему!

Angular Universal — это опенсорсный проект, который расширяет функциональность @angular/platform-server. Он делает возможным Server Side Rendering в Angular. В этой статье мы обсудим проблемы и возможные решения, с которыми мы столкнулись при разработке реального приложения с Angular Universal.

Какие характеристики должны быть у web-приложения, чтобы соответствовать критерию "прогрессивное"? Понятно, что, как и обычные web-приложения, прогрессивные строятся на базе "большой тройки" web-технологий - HTML/CSS/JS. Но что именно делает web-приложения прогрессивными?

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

Интерактивное демо PS5.js

Подготовка

Если вы следите за отчетами исследователей, которые участвуют в bug bounty программах, то наверняка знаете про категорию уязвимостей JavaScript prototype pollution. А если не следите и встречаете это словосочетание впервые, то предлагаю вам закрыть этот пробел, ведь эта уязвимость может привести к полной компрометации сервера и клиента. Наверняка хотя бы один продуктов вашей (или не вашей) компании работает на JavaScript: клиентская часть веб-приложения, десктоп (Electron), сервер (NodeJS) или мобильное приложение.

Эта статья поможет вам погрузиться в тему prototype pollution. В разделах Особенности JavaScript и Что такое prototype pollution? вы узнаете как работают объекты и прототипы JavaScript и как особенности их функционирования могут привести к уязвимостям. В разделах Prototype pollution на сервере и Prototype pollution на клиенте вы научитесь искать и эксплуатировать эту уязвимость на кейсах из реального мира. Наконец вы изучите способы защиты и почему самый распространенный способ защиты можно легко обойти.

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

Привет. С выходом Chrome 89 (а так же в Deno 1.8) появилась возможность использовать Карты импортов (Import maps) – механизма, позволяющего получить контроль над поведением JavaScript-импортов.

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

Если кратко, то теперь можно будет совершенно законно и без всяких сборщиков писать, скажем, так:

import React from 'react';

Под катом разберём как это всё работает.

Реактивность

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

Поначалу звучит очень логично. Где то на краю экрана пробежал вражеский персонаж, и только ту часть CANVAS мы и хотим перерисовать, сэкономив ресурсы. Это было настолько правдоподобно, что я за ночь изрисовал лист A4 в поисках оптимального решения этой задачи. И вот что получилось.

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

Ниже вы увидите однострочную функцию, которая возвращает свойство lastName переданного аргумента. Просто добавив одно свойство к каждому объекту, мы получим падение производительности более чем на 700%!

Объясню подробнее почему так происходит. Отсутствие статической типизации в JavaScript приводит к такому поведению. Если рассматривать это как преимущество перед другими языками, такими как C# или Java, то в данном случае получается скорее "Faustian bargain" ("Фаустовская сделка". Жертвование духовных ценностей ради материальных выгод; происхождение выражения связано с именем Дж. Фауста).

Эта статья - часть серии статей "Составляя ПО" про функциональное программирование и различные техники создания программ на JavaScript ES6+, начиная с азов. Оставайтесь на связи, много нового впереди!

Композиция: "Действие, заключающееся в составлении единого целого из частей или элементов."

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

Я больше всего в своей жизни сожалею о том, что не понял всей важности этого урока в самом начале. Суть разработки ПО стала мне понятна слишком поздно.

Каждый разработчик JavaScript должен знать, что такое замыкание (closure). Во время собеседования по кодированию JavaScript есть большая вероятность, что вас спросят о концепции замыкания.

Я составил список из 7 интересных и наиболее сложных вопросов по замыканиям в JavaScript.

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

Развлекайтесь!

Если вам нужно освежить свои знания о замыкании, я рекомендую ознакомится с публикацией A Simple Explanation of JavaScript Closures (Простое объяснение замыканиям в JavaScript).

Содержание

Вопрос 1: Замыкания развязывают твои руки 

Вопрос 2: Утерянные параметры

Вопрос 3: Кто есть кто

Вопрос 4: Хитроумное замыкание

Вопрос 5: Правильное или неправильное сообщение

Вопрос 6: Восстановление инкапсуляции (Restore encapsulation)

Вопрос 7: Умное перемножение

Резюме

Основная цель - обнаружение лица и маски в браузере, не используя бэкенд на Python. Это простое приложение WebApp / SPA, которое содержит только JS-код и может отправлять некоторые данные на серверную часть для следующей обработки. Но начальное обнаружение лица и маски выполняется на стороне браузера и никакой реализации Python для этого не требуется.

На данный момент приложение работает только в браузере Chrome.

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

Я много раз читал, как кто-то попробовал MobX, у него код получился запутанным с не контролируемыми изменениями, после чего он продолжил писать на Redux. Для MobX нет рекомендованной архитектуры. Но при использовании и соблюдении в MobX строгой и однообразной (имеется ввиду одинаковой в различных участках проекта) архитектуры, можно получить понятный код с контролируемыми изменениями в сколь угодно большом проекте. Я опишу один из вариантов, как этого добиться.

Когда я приходил на конференции и видел презентации на тему веб-компонентов, я всегда думал, что это не только изящно, но и довольно сложно. Тысяча строк JavaScript, чтобы сохранить всего 4 строки HTML. Докладчик или неизбежно скрывал за простыми вещами огромное количество JS кода, или погружался в сложные детали, тогда мои глаза начинали закрываться от скуки, и я начинал думать о том, покрывают ли мои суточные выплаты расходы на закуски.

Однако в недавнем проекте, созданном для легкого изучения HTML (Конечно, путем добавления зомби и глупых шуток), я решил, что необходимо описать каждый элемент HTML в спецификации. Не считая той конференции, я впервые начинал знакомство с <slot> и <template> элементами, и, когда я захотел написать что-то интересное о них в проекте, мне пришлось углубиться в тему.

И в процессе углубления я понял: веб-компоненты проще, чем я думал.

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

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

Учитывая насколько hype-driven является разработка софта в наше время, можно быть уверенным в том что через несколько лет будут существовать новые модные фреймворки для фронтенд разработки. В момент когда фреймворк на базе которого построено приложение выходит из моды — вы вынуждены либо поддерживать устаревшую (legacy) кодовую базу либо стартовать процесс перевода приложения на новый фреймворк.

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

Данная статья является примером построения SPA с использованием высокоуровневых принципов дизайна архитектуры. При этом конкретные библиотеки и фреймворки выбираются для удовлетворения ответственностей, определённых желаемой архитектурой.

Одни умные люди говорят: "эксепшены - это зло, используйте монады!", другие кричат: "коды ошибок ещё никто не отменял!", а третьи включают механизм исключений в языки программирования.. Однако, у большинства статей, который попадались мне на глаза есть две относительные проблемы (при всём уважении к авторам!):

Некоторая... академичность. Разобрано множество идей и концепций, но заканчивается всё стандартным: "ваш выбор зависит от вашей ситуации".

Абсолютно отсутствуют упоминания о бюджете. Никто же не будет спорить, что теоретически мерседес лучше, чем восьмёрка по всем показателям... если не считать цены.

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

Кому интересно, прошу под кат.

Существует довольно популярный сайт https://custom-elements-everywhere.com где показывается как работают веб-компоненты в разных фреймворках. Почти у всех фреймворков там красивый 100% результат, но у React там очень настораживающие 71%.

Многие пользователи смотрят на эту страничку и делают вывод, что React плохо поддерживает не только веб-компоненты, но и DOM API в принципе. Так ли это? Действительно ли все плохо?

Давайте разбираться!