Loaders - ObjectLoaders and other example loaders giving TypeError in react-native

[TypeError: undefined is not an object (evaluating ‘response.body.getReader’)]

Above error is produced when load function of any loader ( like GLTFLoader or ObjectLoader ) is called.

Platforms tested on:

Mobile - iPhone OS: iOS, MacOS Three.js version 0.135.0 expo-three version 6.0.1 expo-gl version 11.0.3 expo version 43.0.2 react version 17.0.1 react-native version 0.64.3

Sample Code:

const asset = Asset.fromModule(
    require("./assets/v_knife_karam/v_knife_karam.gltf")
  );
  await asset.downloadAsync();

  const loader = new GLTFLoader();

  loader.load(
    asset.uri,
    (gltf) => {
      // model = gltf.scene;
      scene.add(gltf.scene);
    },
    (xhr) => {
      console.log(`${(xhr.loaded / xhr.total) * 100}% loaded`);
    },
    (error) => {
      console.error("An error happened", error);
    }
  );

Error : [TypeError: undefined is not an object (evaluating ‘response.body.getReader’)]

[gkjohnson]

I thought this was an unnecessary breaking change that was only causing problems for native and older platforms

I think it’s more accurate to say that three.js made a change that exposed a bug in react-native / the polyfill. In terms of the benefits of the change the fetch implementation simplified the handling of data URIs in the FileLoader, is easier to follow, and personally I’d like to see Loaders take a set of fetch options in the future considering how much more ergonomic they are.

As for issues, response.arrayBuffer would rely on github/fetch#992, but it looks like native’s networking stack would need some work for full compliance.

Have you created an issue for react-native, then? Again this is clearly a shortcoming of these other packages and limits the broader js ecosystems ability to leverage stable, modern APIs. Asking libraries to stall modernization to support workarounds for issues in other packages with no plan or effort to alleviate it is hard to support.

I was hoping this wouldn’t be a hassle, but if it is, then I think this is something that can live in three-stdlib. They already target node, so it should be fine to move FileLoader there.

What I’m really asking for is for some effort to be made to fix the fetch polyfill and react native here instead of expecting three.js to revert because it’s the easy way out. I think instead this effort is best spent making a PR for github fetch to fix the res.arrayBuffer issue and informing or making a PR for react-native to improve the fetch behavior if that’s needed there too. Seeing what kind of progress can or can’t be made on either project I’d think would better inform decision made by three.js.

And to be clear – like I’ve said before – this ultimately isn’t up to me but these are my opinions.

[Mugen87]

If Node isn’t a platform that three supports

three.js does not officially support node environments. As mentioned in the documentation (section Node.js), the engine is designed for the web and relies on Web APIs which are not necessarily supported in node.js.

That said, we try make a node integration easier with PRs like #10732 or #14914 but only if the changes do not affect the code base too much.

In this particular case, the issue needs to be solved elsewhere like mentioned in https://github.com/mrdoob/three.js/issues/23015#issuecomment-994251807.