GrCodeScanner

The native BarcodeDetector exists in Chrome and Edge, but it is in neither Safari nor Firefox — that is, on an iPhone it does not exist at all, while scanning is most often done precisely with a phone. Embedding a decoder into the package is not possible: it has not a single dependency, and for the sake of one component the heaviest one would appear — and for everyone, including those who took only the cropper.

The component therefore handles the native path itself, and the other browsers are covered by a detector the application passes in:

import { BrowserMultiFormatReader } from '@zxing/browser'

const reader = new BrowserMultiFormatReader()

async function detector(source) {
  const canvas = Object.assign(document.createElement('canvas'), {
    width: source.videoWidth,
    height: source.videoHeight,
  })
  canvas.getContext('2d')?.drawImage(source, 0, 0)

  const result = reader.decodeFromCanvas(canvas)

  return result ? [{ value: result.getText(), format: String(result.getBarcodeFormat()) }] : []
}

<GrCodeScanner :detector="detector" />

The prop is deliberately stronger than the native path: an application that has connected a library of its own usually does so for the sake of a format the native detector does not know.

There being nothing to read with is a separate state: the component says straight out that the browser cannot do it and that a detector is needed. Offering “switch the camera on” in that case would mean sending the user to solve the wrong task.

This is checked after mounting: on the server there is never a BarcodeDetector, and a decision made in the render would diverge from the browser during hydration. The first render is the same everywhere — the idle state — and the message “the browser cannot read codes” appears only where it is true.

The slot receives status, start and stop — the GrCameraStatus type is exported from @feugene/granularity-media/components/GrCodeScanner as well. When the slot is passed, only the status text remains in the frame: the component’s own “Start” button there would be a second one under the application’s panel.

The camera gives away dozens of frames per second, and the code is recognised in every one of them. Without a filter the application would receive a stream of identical events and would place twenty orders instead of one, so only what was not in the previous frame is reported.

The symbology is part of the identity: one and the same value in qr_code and in ean_13 counts as different codes, because it means different things too.

continuous removes the filter: at a receiving desk identical packages are scanned one after another, and there a repeat is a legitimate second event.

interval (250 ms by default) is a trade between responsiveness and heating: parsing every frame means keeping the processor busy continuously, and a phone in the hand heats up noticeably.

A frame that did not parse is the norm rather than a failure: a hand, a reflection, a blur got into the lens. Such a pass is skipped silently, and the next one will come after interval.

• there is no parsing of a picture from a file. The component works with a live stream; for a shot of a code the application calls its detector directly;
• there is no torch and no zoom. torch and zoom are extensions of the track, and their support differs even within Chrome;
• there is no marking of the found code on the preview. The native API gives away the coordinates, but someone else’s detector does not necessarily, and drawing a frame for half of the sources would mean promising what is not there.