Hello.

I am Paul Kinlan.

A Developer Advocate for Chrome and the Open Web at Google.

Object Detection and Augmentation

Paul Kinlan

He estado jugando mucho con Shape Detection API en Chrome y me gusta mucho el potencial que tiene, por ejemplo, un QRCode detector muy simple que escribí hace mucho tiempo tiene un polyfill JS, pero usa la API new BarcodeDetector() si está disponible.

Puede ver algunas de las otras demostraciones que he construido aquí utilizando las otras capacidades de la API de detección de formas: Face Detection , Barcode Detection y Text Detection .

Me sorprendió gratamente cuando me tropecé con Jeeliz el fin de semana y me impresionó mucho el rendimiento de su conjunto de herramientas, aunque estaba usando un Pixel3 XL, pero la detección de rostros parecía significativamente más rápida de lo que es posible con la API FaceDetector .

Checkout some of their demos .

Me hizo pensar mucho. Este kit de herramientas para la detección de objetos (y otros similares) utiliza API que están ampliamente disponibles en la web, específicamente el acceso a la cámara, WebGL y WASM, que a diferencia de la API de detección de formas de Chrome (que solo está en Chrome y no es consistente en todas las plataformas en las que Chrome está ) se puede utilizar para crear experiencias ricas fácilmente y llegar a miles de millones de usuarios con una experiencia consistente en todas las plataformas.

El aumento es donde se pone interesante (y realmente lo que quería mostrar en esta publicación) y donde necesita las bibliotecas de middleware que ahora están llegando a la plataforma, podemos crear las divertidas aplicaciones de filtro de caras de Snapchat sin que los usuarios instalen aplicaciones MASIVAS esa cosecha gran cantidad de datos del dispositivo de los usuarios (porque no hay acceso subyacente al sistema).

Fuera de las divertidas demostraciones, es posible resolver casos de uso muy avanzados de forma rápida y sencilla para el usuario, como:

  • Selección de texto directamente desde la cámara o foto del usuario.
  • Traducción en vivo de idiomas desde la cámara.
  • Detección de código QR en línea para que las personas no tengan que abrir WeChat todo el tiempo :)
  • Extraiga automáticamente las direcciones URL del sitio web o la dirección de una imagen
  • Detección de tarjeta de crédito y extracción de números (haga que los usuarios se registren más rápido en su sitio)
  • Búsqueda visual de productos en la aplicación web de tu tienda.
  • Búsqueda de códigos de barras para obtener más detalles del producto en la aplicación web de su tienda.
  • Recorte rápido de fotos de perfil en las caras de las personas.
  • Funciones simples de A11Y para que el usuario escuche el texto que se encuentra en las imágenes.

Acabo de pasar 5 minutos pensando en estos casos de uso, sé que hay muchos más, pero me parece que no vemos muchos sitios o aplicaciones web que utilizan la cámara, sino que vemos muchos sitios que preguntan a sus usuarios para descargar una aplicación, y no creo que tengamos que hacerlo más.

** Actualización ** Thomas Steiner en nuestro equipo mencionó en nuestro equipo Chat que parece que no me gusta la actual API ShapeDetection . Me encanta el hecho de que esta API nos da acceso a las implementaciones de envío nativas de cada uno de los sistemas respectivos. Sin embargo, como escribí en The Lumpy Web , los Desarrolladores Web anhelan consistencia en la plataforma y hay varios problemas con la API de Detección de Forma que pueden resumirse como:

  1. La API solo está en Chrome 2. La API en Chrome es muy diferente en cada plataforma porque sus implementaciones subyacentes son diferentes. Android solo tiene puntos para puntos de referencia como boca y ojos, donde macOS tiene contornos. En Android, TextDetector devuelve el texto detectado, mientras que en macOS devuelve un indicador de 'Presencia de texto' … Esto es para no mencionar todos los errores que encontró Surma.

La web como plataforma para la distribución tiene tanto sentido para experiencias como estas que creo que sería negligente que no lo hagamos, pero los dos grupos de problemas anteriores me llevan a cuestionar la necesidad a largo plazo de implementar cada característica en la plataforma web de forma nativa, cuando podríamos implementar buenas soluciones en un paquete que se envía con las características de la plataforma actual como WebGL, WASM y en la futura GPU web.

De todos modos, me encanta el hecho de que podamos hacer esto en la web y espero ver los sitios que se envían con ellos.

Paul Kinlan

Trying to make the web and developers better.

RSS Github Medium

Got web performance problems? Just wait...

Paul Kinlan

Vi un tweet de un buen amigo y colega, Mariko , acerca de las pruebas en una gama de dispositivos de gama baja que lo mantienen realmente conectado a tierra.

El contexto del tweet es que estamos analizando cómo es el desarrollo web cuando construimos para usuarios que viven diariamente en estas clases de dispositivos.

El equipo está haciendo mucho trabajo ahora en este espacio, pero pasé un día construyendo un sitio y fue increíblemente difícil hacer que algo funcionara a un nivel de rendimiento incluso ligeramente razonable. Estos son algunos de los problemas que encontré:

  • Las rarezas de la ventana gráfica, y la reintroducción misteriosa de 300 ms de retraso de clics (puede funcionar alrededor).
  • Grandes repintados de pantalla completa, y es lento.
  • La red es lenta
  • La memoria está restringida, y los GC subsiguientes bloquean el hilo principal por varios segundos
  • Ejecución increíblemente lenta de JS
  • La manipulación de DOM es lenta

Para muchas de las páginas que estaba creando, incluso en una conexión wifi rápida las páginas tardaron varios segundos en cargarse, y las interacciones posteriores fueron simplemente lentas. Fue difícil, involucró intentar alejarme lo más posible del hilo principal, pero también fue increíblemente gratificante a nivel técnico ver cambios en los algoritmos y la lógica que no habría hecho con todo mi desarrollo web tradicional. Grandes mejoras en el rendimiento.

No estoy seguro de qué hacer a largo plazo, sospecho que una gran cantidad de desarrolladores con los que trabajamos en los mercados más desarrollados tendrá una reacción "No estoy construyendo sitios para usuarios en [insertar país x]", y en un de alto nivel es difícil discutir esta afirmación, pero no puedo ignorar el hecho de que 10 de los millones de nuevos usuarios ingresan a la informática cada año y usarán estos dispositivos y queremos que la web sea * la * plataforma de elección para contenido y aplicaciones para que no estemos contentos con rise of the meta platform .

Vamos a tener que seguir presionando en el rendimiento durante un largo tiempo por venir. Seguiremos creando herramientas y guías para ayudar a los desarrolladores a cargar rápidamente y tener interfaces de usuario fluidas :)

Browser Bug Searcher

Paul Kinlan

Solo estaba reflexionando sobre algunos de los work our team has done y encontré un proyecto de 2017 que Robert Nyman y Eric Bidelman crearon. Browser Bug Searcher! .

Es increíble que con solo unas pocas pulsaciones de tecla tenga una gran visión general de sus funciones favoritas en todos los motores de navegación principales.

Source code available .

Esto realmente resalta uno de los problemas que tengo con los rastreadores de errores de crbug y webkit, no tienen una forma sencilla de recibir fuentes de datos en formatos como RSS. Me encantaría poder usar mi agregador topicdeck con categorías de errores, etc., así que tengo un panel de todas las cosas en las que estoy interesado en base a la información más reciente de cada uno de los rastreadores de errores.

Brexit: History will judge us all

Paul Kinlan

La historia nos juzgará a todos en este lío, y espero que sea un estudio de caso para todos sobre los efectos del nacionalismo, los intereses personales, la arrogancia colonial, la bafonía de las celebridades.

Putos

File Web Share Target

Paul Kinlan

Con frecuencia he dicho que para que las aplicaciones web puedan competir de manera efectiva en el mundo de las aplicaciones, deben integrarse en todos los lugares en los que los usuarios esperan que estén. La comunicación entre aplicaciones es una de las piezas faltantes más importantes de la plataforma web, y específicamente una de las últimas características faltantes más importantes es el uso compartido a nivel nativo: las aplicaciones web deben poder obtener data out of their silo y otros sitios web y aplicaciones; también deben poder recibir los datos de otras aplicaciones y sitios nativos.

Read More

Testing-file-share-target-from-camera

Paul Kinlan

Esto es probar compartir directamente desde la aplicación de la cámara. Parece que funcionó :)

Read More

testing-file-share-target

Paul Kinlan

Esta es una prueba de Share Target API en Android y su capacidad para compartir archivos. Si ves algo aquí, entonces todo está bien :)

Read More

Ricky Mondello: Adoption of Well-Known URL for Changing Passwords

Paul Kinlan

Ricky Mondello en el equipo de Safari recientemente compartió una nota sobre cómo Twitter está utilizando la especificación ./well-known/change-password.

I just noticed that Twitter has adopted the Well-Known URL for Changing Passwords! Is anyone aware of other sites that have adopted it?

Twitter’s implementation: https://twitter.com/.well-known/change-password; Github’s: https://github.com/.well-known/change-password; Specification :https://github.com/WICG/change-password-url

Read full post .

La función me pasó por completo, pero es una buena idea: dado un archivo en una ubicación conocida, ¿puede el navegador ofrecer una IU al usuario que le permita restablecer rápidamente su contraseña sin tener que navegar por la IU compleja del sitio?

La especificación es aparentemente simple: el archivo conocido simplemente contiene la URL para dirigir al usuario cuando quiere realizar la acción. Esto me lleva a pensar, ¿podemos ofrecer más de estas características?

  • Una ubicación bien conocida para los modelos de consentimiento basados en GDPR (consentimiento de cookies): los propietarios del sitio podrían ofrecer un enlace a la página donde un usuario puede administrar y revocar potencialmente todas las cookies y otros elementos de consentimiento de datos.
  • Una ubicación bien conocida para la administración de permisos del navegador: los propietarios de sitios pueden ofrecer un lugar rápido para que los usuarios puedan revocar permisos para cosas como ubicación geográfica, notificaciones y otras primitivas.
  • Una ruta bien conocida para la eliminación de cuentas y cambios
  • Una ruta bien conocida para la gestión de suscripciones a listas de correo.

La lista continúa … Realmente me gusta la idea de que los archivos de redireccionamiento simples ayuden a los usuarios a descubrir acciones comunes de los usuarios, y una forma en que el navegador pueda resaltarlo.

pinch-zoom-element

Paul Kinlan

Jake y el equipo construyeron este elemento personalizado bastante impresionante para administrar el zoom de pellizco en cualquier conjunto de HTML fuera de la propia dinámica de zoom-pellizco del navegador (piense en el zoom de la vista desde una ventana móvil). El elemento fue uno de los componentes centrales que necesitábamos para la aplicación squoosh que creamos y lanzamos en Chrome Dev Summit (… digo 'lanzado en Chrome Dev Summit': Jake se lo mostró a todos en el China Developer Day de China aunque el resto del equipo estaba bajo embargo;) …)

install: npm install --save-dev pinch-zoom-element

<pinch-zoom>
  <h1>Hello!</h1>
</pinch-zoom>

Read full post .

Acabo de agregarlo a mi blog (me tomó solo un par de minutos), puedes verlo en mi sección ' life ' donde comparto las fotos que tomé. Si se encuentra en un dispositivo táctil, puede hacer un zoom rápido en el elemento, si está utilizando un trackpad que puede manejar múltiples entradas de dedo que también funcionan.

Este elemento es un gran ejemplo de por qué me encantan los componentes web como modelo para crear componentes de interfaz de usuario. El elemento pinch-zoom tiene poco menos de 3kb en el cable (sin comprimir) y dependencias mínimas para la construcción y simplemente hace un trabajo excepcionalmente bien, sin vincular ninguna lógica personalizada de nivel de aplicación que haga que sea difícil de usar (tengo algunas ideas sobre la lógica de UI componentes de la lógica de la aplicación vs que compartiré en base a mis aprendizajes de la aplicación Squoosh).

Me encantaría ver que elementos como estos adquieran mayor conciencia y uso, por ejemplo, podría imaginar que este elemento podría reemplazar o estandarizar la funcionalidad de zoom de imagen que se ve en muchos sitios de comercio y quitarle el dolor a los desarrolladores.

Registering as a Share Target with the Web Share Target API

Paul Kinlan

Pete LePage presenta la API Web Share Target y la disponibilidad en Chrome a través de una prueba de origen.

Until now, only native apps could register as a share target. The Web Share Target API allows installed web apps to register with the underlying OS as a share target to receive shared content from either the Web Share API or system events, like the OS-level share button.

Read full post .

Esta API es un cambio de juego en la web, abre la web a algo que solo estaba disponible una vez para las aplicaciones nativas: Native Sharing. Las aplicaciones son silos, absorben todos los datos y dificultan el acceso a todas las plataformas. Share Target comienza a nivelar el campo de juego para que la web pueda jugar en el mismo juego.

La experiencia de Twitter Mobile tiene Share Target already enabled . Esta publicación se creó utilizando el Objetivo de Compartir que he definido en el 'administrador de' ' manifest.json mis sitios - funciona bastante bien, y en el momento en que manifest.json soporte para archivos, podré publicar cualquier imagen o blob en mi dispositivo en mi blog.

Tiempos muy emocionantes.

Lea la publicación vinculada para obtener más información sobre los plazos en los que se publicará esta API y cómo utilizarla.

Why Build Progressive Web Apps: Push, but Don't be Pushy! Video Write-Up

Paul Kinlan

Un gran artículo, video y muestra de Thomas Steiner sobre buenas notificaciones push en la web.

A particularly bad practice is to pop up the permission dialog on page load, without any context at all. Several high traffic sites have been caught doing this. To subscribe people to push notifications, you use the the PushManager interface. Now to be fair, this does not allow the developer to specify the context or the to-be-expected frequency of notifications. So where does this leave us?

Read full post .

Web Push es una API increíblemente poderosa, pero es fácil abusar y molestar a sus usuarios. Lo malo de su sitio es que si un usuario bloquea las notificaciones porque usted las solicita sin previo aviso, no tendrá la oportunidad de volver a preguntar.

Trate a sus usuarios con respeto, el contexto es el rey para las notificaciones Web Push.

Maybe Our Documentation "Best Practices" Aren''t Really Best Practices

Paul Kinlan

Kayce Basques, un asombroso escritor de tecnología de nuestro equipo, escribió un artículo bastante sorprendente sobre sus experiencias en la medición de cómo funcionan las mejores prácticas de documentación existentes para explicar material técnico. Las mejores prácticas en este sentido pueden ser los estándares conocidos de la industria para la redacción técnica o la guía de estilo de redacción de sus propias empresas. ¡Echale un vistazo!

Recently I discovered that a supposed documentation “best practice” may not actually stand up to scrutiny when measured in the wild. I’m now on a mission to get a “was this page helpful?” feedback widget on every documentation page on the web. It’s not the end-all be-all solution, but it’s a start towards a more rigorous understanding of what actually makes our docs more helpful.

Read full post .

Aunque no soy un escritor de tecnología, mi función implica una gran cantidad de compromiso con nuestro equipo de redacción de tecnología, así como la publicación de muchas "mejores prácticas" para los desarrolladores. Me sorprendió la profundidad y la investigación que Kayce ha hecho sobre el arte de escribir documentos modernos a través de la lente del contenido de nuestros equipos. Te animo a que leas el artículo de Kayce en profundidad; aprendí mucho. ¡Gracias Kayce!

Grep your git commit log

Paul Kinlan

Finding code that was changed in a commit

Read More

Performance and Resilience: Stress-Testing Third Parties by CSS Wizardry

Paul Kinlan

Hace un par de semanas estuve en China para el Día del desarrollador de Google y les mostré a todos mi QRCode scanner, estaba funcionando muy bien hasta que me desconecté. Cuando el usuario estaba fuera de línea (o parcialmente conectado), la cámara no se iniciaría, lo que significaba que no podía ajustar los códigos QR. Me tomó una edad para averiguar qué estaba pasando, y resultó que estaba arrancando la cámara por error en mi evento onload y la solicitud de Google Analytics se bloqueó y no se resolvió de manera oportuna. Fue este compromiso el que lo arregló.

Because these types of assets block rendering, the browser will not paint anything to the screen until they have been downloaded (and executed/parsed). If the service that provides the file is offline, then that’s a lot of time that the browser has to spend trying to access the file, and during that period the user is left potentially looking at a blank screen. After a certain period has elapsed, the browser will eventually timeout and display the page without the asset(s) in question. How long is that certain period of time?

It’s 1 minute and 20 seconds.

If you have any render-blocking, critical, third party assets hosted on an external domain, you run the risk of showing users a blank page for 1.3 minutes.

Below, you’ll see the DOMContentLoaded and Load events on a site that has a render-blocking script hosted elsewhere. The browser was completely held up for 78 seconds, showing nothing at all until it ended up timing out.

Leer publicación completa.

Te animo a leer el post porque hay mucha información excelente.

Chrome Bug 897727 - MediaRecorder using Canvas.captureStream() fails for large canvas elements on Android

Paul Kinlan

El fin de semana que estuve jugando con un codificador de video de efecto Boomerang, puedes hacerlo funcionar casi en tiempo real (lo explicaré más adelante). Lo tengo funcionando en Chrome on Desktop, pero nunca funcionaría correctamente en Chrome en Android. Ver el código aquí.

Parece que cuando usas captureStream () en un <canvas>que tiene una resolución relativamente grande (1280x720 en mi caso), la API de MediaRecorder no podrá codificar los videos y no se producirá un error y no se puede detectar que no puede codificar el video con anticipación.

(1) Capture a large res video (from getUM 1280x720) to a buffer for later processing. (2) Create a MediaRecorder with a stream from a canvas element (via captureStream) sized to 1280x720 (3) For each frame captured putImageData on the canvas (4) For each frame call canvasTrack.requestFrame() at 60fps

context.putImageData(frame, 0, 0); canvasStreamTrack.requestFrame();

Demo: https://boomerang-video-chrome-on-android-bug.glitch.me/ Code: https://glitch.com/edit/#!/boomerang-video-chrome-on-android-bug?path=script.js:21:42

What is the expected result?

For the exact demo, I buffer the frames and then reverse them so you would see the video play forwards and backwards (it works on desktop). In generall I would expect all frames sent to the canvas to be processed by the MediaRecorder API - yet they are not.

What happens instead?

It only captures the stream from the canvas for a partial part of the video and then stops. It’s not predicatable where it will stop.

I suspect there is a limit with the MediaRecorder API and what resolution it can encode depending on the device, and there is no way to know about these limits ahead of time.

As far as I can tell this has never worked on Android. If you use https://boomerang-video-chrome-on-android-bug.glitch.me which has a 640x480 video frame it records just fine. The demo works at higher-resolution just fine on desktop.

Leer publicación completa.

Si quieres jugar con la demo que funciona en ambos, haz clic aquí (0)

Why Microsoft and Google love progressive web apps | Computerworld

Paul Kinlan

Un buen post sobre PWA de Mike Elgan. No estoy seguro de cuál es el objetivo de Microsoft con PWA, pero creo que el nuestro es bastante simple: queremos que los usuarios tengan acceso al contenido y la funcionalidad de manera instantánea y de la forma en que esperan poder interactuar con ellos en sus dispositivos. La web debe llegar a todos los dispositivos conectados y el usuario debe poder acceder a su modalidad preferida, como una aplicación si así lo esperan (móvil, tal vez) o voz en un asistente, etc.

Todavía estamos lejos de la web sin cabeza, sin embargo, una cosa realmente me impresionó en el artículo:

Another downside is that PWAs are highly isolated. So it’s hard and unlikely for different PWAs to share resources or data directly.

Leer publicación completa.

Los sitios y las aplicaciones en la web no deben estar aislados, la web es vinculable, indexable, efímera, pero cada vez que creamos un sitio más en silos. Estamos creando silos no deseados porque la plataforma no permite fácilmente a los usuarios ingresar * sus * datos dentro y fuera de los sitios fácilmente. No estoy hablando de RDF ni nada de eso, las operaciones básicas como copiar y pegar, arrastrar y soltar, compartir en el sitio y compartir desde el sitio se rompen en la web de hoy, y eso es antes de que lleguemos al IPC entre marcos, trabajadores y ventanas.

Building a video editor on the web. Part 0.1 - Screencast

Paul Kinlan

Debería poder crear y editar videos usando solo la web en el navegador. Debería ser posible proporcionar una interfaz de usuario similar a Screenflow que le permita crear un video de salida que combine múltiples videos, imágenes y audio en un video que se puede cargar a servicios como YouTube. Siguiendo con la mi publicación anterior que describe brevemente los requisitos del editor de video, en esta publicación solo quería mostrar rápidamente cómo construí la grabadora de cámara web y también cómo crear una presentación de pantalla.

Read More

894556 - Multiple video tracks in a MediaStream are not reflected on the videoTracks object on the video element

Paul Kinlan

El primer problema que encontré al intentar construir un editor de video en la web.

Tengo varias secuencias de video (computadora de escritorio y cámara web) y quería poder alternar entre las secuencias de video en un elemento de video para poder cambiar rápidamente entre la cámara web y la computadora de escritorio y no interrumpir el MediaRecorder.

Parece que deberías poder hacerlo alternando la propiedad selected en el objetovideoTracks en el <video> Elementopero no puede, la matriz de pistas contiene solo 1 elemento (la primera pista de video en MediaStream).

What steps will reproduce the problem? (1) Get two MediaStreams with video tracks (2) Add them to a new MediaStream and attach as srcObject on a videoElement (3) Check the videoElement.videoTracks object and see there is only one track

Demo at https://multiple-tracks-bug.glitch.me/

What is the expected result? I would expect videoElement.videoTracks to have two elements.

What happens instead? It only has the first videoTrack that was added to the MediaStream.

Leer publicación completa.

Caso de repro.

window.onload = () => {
  if('getDisplayMedia' in navigator) warning.style.display = 'none';

  let blobs;
  let blob;
  let rec;
  let stream;
  let webcamStream;
  let desktopStream;

  captureBtn.onclick = async () => {

       
    desktopStream = await navigator.getDisplayMedia({video:true});
    webcamStream = await navigator.mediaDevices.getUserMedia({video: { height: 1080, width: 1920 }, audio: true});
    
    // Always 
    let tracks = [...desktopStream.getTracks(), ... webcamStream.getTracks()]
    console.log('Tracks to add to stream', tracks);
    stream = new MediaStream(tracks);
    
    console.log('Tracks on stream', stream.getTracks());
    
    videoElement.srcObject = stream;
    
    console.log('Tracks on video element that has stream', videoElement.videoTracks)
    
    // I would expect the length to be 2 and not 1
  };

};

Building a video editor on the web. Part 0.

Paul Kinlan

Debería poder crear y editar videos usando solo la web en el navegador. Debería ser posible proporcionar una interfaz de usuario similar a Screenflow que le permita crear un video de salida que combine múltiples videos, imágenes y audio en un video que se puede cargar a servicios como YouTube. Este post es realmente solo una declaración de intenciones. Voy a comenzar el largo proceso de averiguar qué está y qué no está disponible en la plataforma y ver qué tan lejos podemos llegar hoy.

Read More

Barcode detection in a Web Worker using Comlink

Paul Kinlan

Soy un gran fan de los códigos QR, son una forma muy simple y ordenada de intercambiar datos entre el mundo real y el mundo digital. Desde hace unos años he tenido un pequeño proyecto paralelo llamado QRSnapper & mdash; bueno, ha tenido algunos nombres, pero este es el que me he fijado en & mdash; que utiliza la API getUserMedia para tomar datos en vivo de la cámara del usuario para que pueda escanear los códigos QR casi en tiempo real.

El objetivo de la aplicación era mantener 60 fps en la interfaz de usuario y la detección casi instantánea del código QR, lo que significaba que tenía que colocar el código de detección en un trabajador web (cosas bastante estándar). En este post solo quería compartir rápidamente cómo usé comlink para simplificar enormemente la lógica en el Worker.

qrclient.js

import * as Comlink from './comlink.js';

const proxy = Comlink.proxy(new Worker('/scripts/qrworker.js')); 

export const decode = async function (context) {
  try {
    let canvas = context.canvas;
    let width = canvas.width;
    let height = canvas.height;
    let imageData = context.getImageData(0, 0, width, height);
    return await proxy.detectUrl(width, height, imageData);
  } catch (err) {
    console.log(err);
  }
};

qrworker.js (trabajador web)

import * as Comlink from './comlink.js';
import {qrcode} from './qrcode.js';

// Use the native API's
let nativeDetector = async (width, height, imageData) => {
  try {
    let barcodeDetector = new BarcodeDetector();
    let barcodes = await barcodeDetector.detect(imageData);
    // return the first barcode.
    if (barcodes.length > 0) {
      return barcodes[0].rawValue;
    }
  } catch(err) {
    detector = workerDetector;
  }
};

// Use the polyfil
let workerDetector = async (width, height, imageData) => {
  try {
    return qrcode.decode(width, height, imageData);
  } catch (err) {
    // the library throws an excpetion when there are no qrcodes.
    return;
  }
}

let detectUrl = async (width, height, imageData) => {
  return detector(width, height, imageData);
};

let detector = ('BarcodeDetector' in self) ? nativeDetector : workerDetector;
// Expose the API to the client pages.
Comlink.expose({detectUrl}, self);

Realmente amo a Comlink, creo que es un cambio de juego de una biblioteca, especialmente cuando se trata de crear JavaScript idiomático que funciona a través de hilos. Finalmente, lo bueno aquí es que la API de detección de código de barras nativa se puede ejecutar dentro de un trabajador, por lo que toda la lógica está encapsulada fuera de la interfaz de usuario.

Leer publicación completa.