POS UI Extension - useScannerSourcesSubscription is [] on initial tile load

Extensions
1

We are using: const availableScanners = useScannerSourcesSubscription();

to retrieve the list of available scanners. However, we’re finding on the very first open of our modal after restarting Shopify POS, availableScanners.length is always an empty array []. We have a useEffect as well that has availableScanners as a dependency, but it continues to be empty on that initial open.

We are using retail-ui-extensions-react 1.7.0. Thank you.

2

Hi Derrick,

I’m taking a look at this today. Thanks for the report!

Also, I wanted to take the opportunity to urge you to update to at least 2024-07 as soon as possible. We will be removing support for versions 1.0-1.7 and 2024-04 on the release of 2025-04.

3

I tried to reproduce with a simple Modal:

import React from "react";

import {
  Text,
  Screen,
  ScrollView,
  Navigator,
  reactExtension,
  useScannerSourcesSubscription,
} from "@shopify/ui-extensions-react/point-of-sale";

const Modal = () => {
  const sources = useScannerSourcesSubscription();
  return (
    <Navigator>
      <Screen name="HelloWorld" title="Hello World!">
        <ScrollView>
          <Text>{sources}</Text>
        </ScrollView>
      </Screen>
    </Navigator>
  );
};

export default reactExtension("pos.home.modal.render", () => <Modal />);

But on my iOS sim, I am getting an appropriate array of [“camera”] on load and re-load. This is on 2024-10, but the scanner API code has not changed since 1.1.

May I ask what scanner types you’re expecting when you open the modal? What sort of device are you on?

As a side note, your component will re-render when a scanner source changes, so a useEffect on it should be unnecessary.

4

Thanks @Nathan_Oliveira for the quick response - we are expecting either [“camera”] or [“camera”,“scanner”]. To confirm in your testing, did you restart Shopify POS and then open the tile? This behavior is on the first open after you restart Shopify POS.

We are also in the process of trying to update to a newer package to see if the behavior changes.

5

@Nathan_Oliveira thanks for your help - it seems whatever was causing this got resolved in our migration to 2024.10.