New React 18 Quagga2 example

[oidualc]

Hi everyone, usage of Quagga with React 18+ is tricky because of this kind of how useEffect works: Quagga.init runs multiple times before Quagga.stop (in the effect cleanup) has time to stop the camera media tracks, failing to close the webcam and leading to resources leaks.
To show a simple use case of safe usage of React with version 18+ I created a new quagga2-react-example on my repo: https://github.com/oidualc/quagga2-react-example/. In particular I'm using a ref isQuaggaInitializedRef to ensure Quagga is initialized only once.
Hope it helps.

[ericblade]

I had recently fixed a similar problem in my application that uses Quagga, but I haven't had a chance yet to see if the same problem affected the demo. From what you're saying, it sounds like it did.

I'll definitely take a look, and see what I can learn. Thank you!

[oidualc]

Actually the demo works correctly because it uses an older version of React and from what I could see the camera has all the time to release the video resources before reinitializing them. The problem is evident when using React 18+ in Strict Mode.

Still, maybe we could do something at the library level also to ensure there will never be a resource leak.
The problem is triggered here: if the camera is initialized more than once, as it happens when the useEffect in React 18+ Strict Mode dev is called twice, the streamRef object is reassigned and the old reference gets lost. So when the release function is invoked, it correctly clears all the video tracks of the last active streamRef but does nothing for the video tracks of the lost reference.

[ericblade]

What I had done in my application, was switch to using a couple of external hooks, useDidMount and useWillUnmount, which prevented init from happening multiple times.

Thanks for pointing out what is probably going wrong there. That's one of those parts where the original code had a ton of globals to access so many things, and it hasn't exactly moved smoothly into a class instance, because of dependencies elsewhere, and so on and so forth, messiness. Basically it fails for the same reason that multi-threading never worked right, internal variables getting stomped on. Makes perfect sense.

I'm thinking there's probably no actually useful reason to try to support a rather advanced situation like "opening multiple cameras simultaneously" in the CameraAccess section, and just assume it would be safe to fully drop the previous, if streamRef is already set when we init.