Оптимизация и ускорение

Привет, Хабр! Раньше мы уже рассказывали о распознавании документов прямо в браузере и технологии WebAssembly (или WASM), которая позволяет это делать. Теперь давайте разберем, как и где это работает в реальной жизни.

В последнее время многим российским компаниям пришлось несладко. По мере того, как санкционные компании и банки получили стимул развивать новые продукты, все чаще начал подниматься вопрос разработки модных progressive web applications (PWA) для удобства клиентов. В разное время им уделяли внимание Apple, Firefox и другие компании, в частности — потому что постоянные усовершенствования HTML, CSS и JavaScript открывали перед пользователями таких приложений более высокий уровень интерактивности и делали нативный опыт возможным на обычном сайте.

Да, HTML5 позволяет создавать красивые и довольно функциональные веб-страницы, но на пути к упрощению жизни прогресс сделал несколько шагов вперед, а пользователи российских банковских приложений в свою очередь привыкли к более технологически продвинутым функциям. Среди таких, к примеру, распознавание документов, сканирование QR- и других баркодов для совершения ежедневных платежей. И никто не хочет возвращаться в прошлое, в котором вершиной прогресса считался обычный мобильный перевод средств со счета на счет. Но что делать, если мобильные браузеры, будь то стандартные Safari или Chrome, к примеру, изначально не запрограммированы распознавать видео?

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

Гибкость + мобильность + производительность = WASM
(источник: https://medium.com/globant/step-up-your-game-with-web-assembly-3f787fe6e95)

Сама технология достаточно новая и была анонсирована в 2015 году, а спустя всего 4 года — была признана официальным веб-стандартом и четвертым языком веб-программирования после HTML, CSS и JavaScript.

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

Мы создали технологии распознавания, основанные на собственных разработках в сфере искусственного интеллекта и способные считывать разные данные с камеры смартфона непосредственно в браузере с помощью WebAssembly (WASM). Именно он предлагает исключительную для веб-задач производительность, открывает возможности легкого интегрирования нативно исполняемых функций в веб-версии приложений и позволяет значительно упростить решение технически сложных задач — к примеру, распознавание данных с камеры прямо в браузере. Стандартные же веб-приложения без дополнений в виде модулей WASM не умеют получать и обрабатывать такие данные с камеры смартфона.

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

Посмотрите как легко распознаются любые виды баркодов в нашем приложении:

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

Сегодня «прокачанное» веб-приложение (PWA), которое дает клиентам возможность использовать версию, более близкую к нативной в обход привычных магазинов для пользователей iOS и Android, активно использует Альфа-Банк. Недавно наша команда благодаря внедрению WASM сделала возможным запуск сканера QR-кодов в Альфа-Онлайн, а Альфа-Банк вышел на новый уровень обслуживания клиентов и стал первым российским банком, запустившим сервис с широким функционалом, включающий оплату товаров и услуг по QR через систему быстрых платежей (СБП) в интернет-банке.

Для совершения оплаты клиенту банка достаточно открыть веб-страницу Альфа-Онлайн, нажать на значок QR-кода в правом верхнем углу и отсканировать имеющийся баркод с помощью камеры на устройстве. После этого остается только проверить появившиеся на экране данные и подтвердить платёж. QR-код можно также «сканировать из файла» — с фотографии или же платежки, имеющейся в электронном виде. Все процессы выполняются непосредственно в браузере на веб-странице банка. Это максимально безопасно, так как изображения с устройства клиента вообще никуда не передаются.

При нажатии на значок QR-кода пользователю становится доступна функция распознавания. Сканирование можно проводить на любом современном устройстве во всех основных браузерах: Mozilla Firefox, Google Chrome, Chromium, Microsoft Edge и Apple Safari. Технология также может работать на умных телевизорах и приставках без разработки специальных приложений или установки отдельных плагинов. Мы разработали алгоритмы, устойчивые к перепаду освещения и ракурсу съемки. Они обеспечивают высокое качество чтения даже поврежденных QR-кодов, в том числе, у пользователей бюджетных моделей телефонов.

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

Спасибо, что читаете блог Smart Engines! Подпишитесь, чтобы получать новые заметки!

У HTML-элементов на HTML-странице может быть необязательный глобальный атрибут class. Например:

Здесь у HTML-элемента div есть интересующий нас атрибут class.

С точки зрения стандарта языка HTML

По действующему стандарту языка HTML атрибут class HTML-элементов должен содержать значение, состоящее из набора (множества) названий (токенов) классов CSS, разделенных пробельными символами (символ пробела, символ горизонтальной табуляции, символы новой строки). В примере выше атрибут class содержит значение-строку имя-класса1 имя-класса2 имя-класса3, представляющее собой набор из трех названий классов CSS, разделенных символом пробела.

Понятие, о котором тут идет речь — набор из слов (токенов), разделенных пробельными символами (по-английски «set of space-separated tokens»). Само это понятие определено в стандарте языка HTML отдельно от определения атрибута class.

В определении понятия «set of space-separated tokens» сказано, что это строка, содержащая ноль или более слов (токенов), разделенных пробельными символами. Из этого я сделал вывод, что атрибут class по действующему стандарту HTML может не содержать ничего (содержать пустую строку). Также не будет нарушением действующего стандарта HTML, если этот атрибут будет содержать только пробельные символы (символ пробела, символ горизонтальной табуляции, символы новой строки).

Действующий стандарт HTML вообще практически не накладывает на набор названий классов CSS в атрибуте class HTML-элементов каких-либо ограничений. Не накладывается ограничение на дублирование названий классов CSS внутри атрибута class. Не накладывается каких-либо ограничений, касающихся порядка перечисления названий классов CSS внутри атрибута class.

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

В примере выше с точки зрения действующего стандарта HTML названия классов имя-класса1, имя-класса2 и имя-класса3 в наборе названий имя-класса1 имя-класса2 имя-класса3 полностью равноправны, несмотря на то, что, к примеру, название имя-класса1 перечислено раньше (левее), чем имя-класса2 или имя-класса3. То же самое касается названия имя-класса2 по сравнению с названием имя-класса3.

Во что это выливается на практике?

Рассмотрим такой код на языке HTML (многоточием заменен неинтересный для предмета этой статьи код):

…

…

Какой-то текст1.

Какой-то текст2.

…

В теле этой HTML-страницы есть два параграфа (HTML-элемент p). Каждый из этих параграфов содержит атрибут class с набором из одних и тех же трех названий классов CSS, только перечисленных в разном порядке.

Описание стилей в классе имя-класса3 не конфликтует с другими классами. А вот описания стилей в классах имя-класса1 и имя-класса2 конфликтуют друг с другом (приписывают разные значения одному и тому же свойству HTML-элемента).

В итоге при любой перестановке названий классов CSS в атрибуте class HTML-элементов p браузер отобразит параграфы одинаково, в данном случае — с синей границей и текстом красного цвета. Это подтверждает наши выводы, сделанные выше из определений действующего стандарта HTML.

Почему же в данном случае в конфликте описаний стилей в классах имя-класса1 и имя-класса2 «победил» класс имя-класса2 (текст в параграфах отразился красным цветом)? Потому что при определении классов CSS внутри HTML-элемента style класс имя-класса2 описан позже (ниже), чем класс имя-класса1. Внутри HTML-элемента style действуют правила (стандарт) языка CSS. Это действие того самого «каскада», давшего первую букву аббревиатуре CSS (Cascading Style Sheets). Если менять местами определения классов CSS внутри HTML-элемента style (или внутри файла с кодом на языке CSS, если определения стилей вынесены в отдельный файл или файлы), то отображение HTML-страницы в браузере будет изменяться.

Влияние правил языка CSS

Всегда ли порядок названий классов в атрибуте «class» HTML-элемента не влияет на отображение HTML-страницы?

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

Дело в том, что в языке CSS можно определить селектор (отборщик) HTML-элементов так, что отбор HTML-элементов селектором будет зависеть от порядка перечисления названий классов CSS в атрибуте class HTML-элементов. Это сделает порядок перечисления названий классов в атрибуте class HTML-элементов значимым для отображения HTML-страницы в браузере.

Это не будет противоречить вышеописанным выводам, сделанным из определений в стандарте языка HTML, потому что в данном случае это будет действие стандарта CSS.

В качестве примера рассмотрим такой код на языке HTML:

…

…

Какой-то текст1.

Какой-то текст2.

…

Это тот же код HTML, что и в первом примере, только здесь изменены два первых селектора внутри HTML-элемента style. Даже описания стилей остались нетронутыми. Однако, теперь браузер отображает в первом параграфе текст зеленым цветом, а во втором параграфе — красным цветом.

В этом примере порядок названий классов внутри атрибута class HTML-элементов стал значимым для отображения HTML-страницы в браузере, но это действие не правил языка HTML, а правил языка CSS.

Заключение

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

Порядок названий классов CSS в атрибуте class HTML-элементов на HTML-странице может влиять (может быть важным) на отображение этой HTML-страницы в браузере. Но следует понимать, что это влияние определяется не правилами (стандартом) языка HTML, а тем, как описаны стили для данной HTML-страницы с помощью языка CSS (они могут быть описаны в разных местах — внутри HTML-элемента style, внутри внешнего файла (нескольких файлов) и так далее).

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

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

T, K и V в дженериках

T называется параметром общего типа (generic type parameter). Это заменитель (placeholder) настоящего (actual) типа, передаваемого функции.

Суть такая: берем тип, определенный пользователем, и привязываем (chain) его к типу параметра функции и типу возвращаемого функцией значения.

Так что все-таки означает T? T означает тип (type). На самом деле, вместо T можно использовать любое валидное название. Часто в сочетании с T используются такие общие переменные, как K, V, E и др.

• K представляет тип ключа объекта;
• V представляет тип значения объекта;
• E представляет тип элемента.

Разумеется, мы не ограничены одним параметром типа — их может быть сколько угодно:

При вызове функции identity можно явно определить действительный тип параметра типа. Или можно позволить TypeScript самостоятельно сделать вывод относительного него:

Условные типы

Приходилось ли вам использовать утилиты типов Exclude, Extract, NonNullable, Parameters и ReturnType?

Все эти утилиты основаны на условных типах (conditional types):

Здесь представлена лишь часть процесса

Краткая справка:

Названные утилиты используются для следующих целей:

• Exclude — генерирует новый тип посредством исключения из UnionType всех членов объединения, указанных в ExcludedMembers;
• Extract — генерирует новый тип посредством извлечения из Type всех членов объединения, указанных в Union;
• NonNullable — генерирует новый тип посредством исключения null и undefined из Type;
• Parameters — генерирует новый кортеж (tuple) из типов параметров функции Type;
• ReturnType — генерирует новый тип, содержащий тип значения, возвращаемого функцией Type.

Примеры использования этих утилит:

Синтаксис условных типов:

T extends U ? X : Y

T, U, X и Y — заменители типов (см. выше). Сигнатуру можно понимать следующим образом: если T может быть присвоен U, возвращается тип X, иначе возвращается тип Y. Это чем-то напоминает тернарный оператор в JavaScript.

Как условные типы используются? Рассмотрим пример:

type IsString = T extends string ? true : false;
​
type I0 = IsString; // false
type I1 = IsString<"abc">; // true
type I2 = IsString; // boolean
type I3 = IsString; // never

Утилита IsString позволяет определять, является ли действительный тип, переданный в качестве параметра типа, строковым типом. В дополнение к этому, с помощью условных типов и условных цепочек (conditional chain) можно определять несколько типов за один раз:

Условная цепочка похожа на тернарные выражения в JS:

Вопрос: что будет, если передать TypeName объединение (union)?

// “string” | “function”
type T10 = TypeName void)>;
// “string” | “object” | “undefined”
type T11 = TypeName;

Почему типы T10 и T11 возвращают объединения? Это объясняется тем, что TypeName — это распределенный (distributed) условный тип. Условный тип называется распределенным, если проверяемый тип является “голым” (naked), т. е. не обернут в массив, кортеж, промис и т. д.

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

T extends U ? X : Y
T => A | B | C
A | B | C extends U ? X : Y =>
(A extends U ? X : Y) | (B extends U ? X : Y) | (C extends U ? X : Y)

Рассмотрим пример:

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

Рассмотрим поток выполнения (execution flow) встроенной утилиты Exclude:

type Exclude = T extends U ? never : T;
type T4 = Exclude<"a" | "b" | "c", "a" | "b">
​
(“a” extends “a” | “b” ? never : “a”) // => never
| (“b” extends “a” | “b” ? never : “b”) // => never
| (“c” extends “a” | “b” ? never : “c”) // => “c”
​
never | never | “c” // => “c”

Пример реализации утилиты с помощью условных и связанных (mapped, см. Заметка о Mapped Types и других полезных возможностях современного TypeScript) типов:

type FunctionPropertyNames = {
: T extends Function ? K : never;
};
type FunctionProperties = Pick>;
​
type NonFunctionPropertyNames = {
: T extends Function ? never : K;
};
type NonFunctionProperties = Pick>;
​
interface User {
id: number;
name: string;
age: number;
updateName(newName: string): void;
}
​
type T5 = FunctionPropertyNames; // “updateName”
type T6 = FunctionProperties; // { updateName: (newName: string) => void; }
type T7 = NonFunctionPropertyNames; // “id” | “name” | “age”
type T8 = NonFunctionProperties; // { id: number; name: string; age: number; }

Данные утилиты позволяют легко извлекать атрибуты функциональных и нефункциональных типов, а также связанные с ними объектные типы из типа User.

Оператор keyof

Приходилось ли вам использовать утилиты типов Partial, Required, Pick и Record?

Внутри всех этих утилит используется оператор keyof.

В JS ключи объекта извлекаются с помощью метода Object.keys:

const user = {
id: 666,
name: “bytefer”,
}
const keys = Object.keys(user); //

В TS это делается с помощью keyof:

type User = {
id: number;
name: string;
}
type UserKeys = keyof User; // “id” | “name”

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

type U1 = User // number
type U2 = User // string | number
type U3 = User // string | number

В приведенном примере используется тип индексированного доступа (indexed access type) для получения типа определенного свойства типа User.

Как keyof используется на практике? Рассмотрим пример:

function getProperty(obj, key) {
return obj;
}
const user = {
id: 666,
name: “bytefer”,
}
const userName = getProperty(user, “name”);

Функция getProperty принимает 2 параметра: объект (obj) и ключ (key), и возвращает значение объекта по ключу.

Перенесем данную функцию в TS:

В сообщениях об ошибках говорится о том, что obj и key имеют неявные типы any. Для решения проблемы можно явно определить типы параметров:

Получаем другую ошибку. Для правильного решения следует использовать параметр общего типа (generic) и keyof:

function getProperty(
obj: T, key: K
) {
return obj;
}

Определяем 2 параметра типа: T и K. extends применяется, во-первых, для ограничения (constraint) типа, передаваемого T, подтипом объекта, во-вторых, для ограничения типа, передаваемого K, подтипом объединения ключей объекта.

При отсутствии ключа TS генерирует следующее сообщение об ошибке:

Оператор keyof может применяться не только к объектам, но также к примитивам, типу any, классам и перечислениям.

Рассмотрим поток выполнения (execution flow) утилиты Partial:

/**
* Делает все свойства T опциональными.
* typescript/lib/lib.es5.d.ts
*/
type Partial = {
?: T;
};

Оператор typeof

Рассмотрим несколько полезных примеров использования оператора typeof.

1. Получение типа объекта

Объект man — это обычный объект JS. Для определения его типа в TS можно использовать type или interface. Тип объекта позволяет применять встроенные утилиты типов, такие как Partial, Required, Pick или Readonly, для генерации производных типов.

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

type Person = typeof man;

type Address = Person;

Person — это тип индексированного доступа (indexed access type), позволяющий извлекать тип определенного свойства (address) из другого типа (Person).

2. Получение типа, представляющего все ключи перечисления в виде строк

В TS перечисление (enum) — это специальный тип, компилирующийся в обычный JS-объект:

Поэтому к перечислениям также можно применять оператор typeof. Однако в случае с перечислениями, typeof обычно комбинируется с оператором keyof:

3. Получение типа функции

Другим примером использования typeof является получение типа функции (функция в JS — это тоже объект). После получения типа функции можно воспользоваться встроенными утилитами типов ReturnType и Parameters для получения типа возвращаемого функцией значение и типа ее параметров:

4. Получение типа класса

В приведенном примере createPoint — это фабричная функция, создающая экземпляры класса Point. С помощью typeof можно получить сигнатуру конструктора класса Point для реализации проверки соответствующего типа. При отсутствии typeof в определении типа конструктора возникнет ошибка:

6. Получение более точного типа

Использование typeof в сочетании с утверждением const (const assertion), представленным в TS 3.4, позволяет получать более точные (precise) типы:

Надеюсь, что вы, как и я, нашли для себя что-то интересное. Благодарю за внимание и happy coding!