"Fragments: Unsupported input type" if I don't specify the "optional" name in ifcLoader.load

[sanzoghenzo]

Describe the bug 📝

I'm updating the IFC wiewer anywidget to the latest version of the libraries.

The project is a simple wrapper to display the viewer inside a jupyter or marimo notebook.
In the python part, I get an ifcopenshell model as an input and pass the result of the to_string() method, which is the entire IFC text content, to the javascript part.

in the javascript part, I loaded the content like this:

    const loadModel = async () => {
      const modelContents = model.get("ifc_model").contents;
      await ifcLoader.load(new TextEncoder().encode(modelContents));
    };

With the library update, I got a Fragments: Unsupported input type error.

I spent the entire morning troubleshooting this issue, only to find that it can be solved by passing the name argument alongside the ifc data:

      await ifcLoader.load(
        new TextEncoder().encode(modelContents),
        true,
        "IfcModel",
      );

The documentation states the the name argument is optional, but it doesn't seem the case anymore.

In fact, the name is passed as-is to the fragments manager as modelId argument, and that breaks the crc.ts functionality since it needs a non null object.

Is the "Optional" word a leftover from previous versions, or am I hitting some sort of edge case here?

Reproduction ▶️

No response

Steps to reproduce 🔢

No response

System Info 💻

- Windows 11
- latest libraries from esm.sh
  - components 3.1.3
  - components-front 3.1.7
  - ui 3.1.1
  - ui-obc 3.1.3
- firefox 142.0.1 and ms edge 140.0.3485.54

Used Package Manager 📦

npm

Error Trace/Logs 📃

Console traceback

Error: Fragments: Unsupported input type
    getHandler blob:http://127.0.0.1:2718/653d2d32-3a13-4f33-81a4-bce4d6b12537:7
    compute blob:http://127.0.0.1:2718/653d2d32-3a13-4f33-81a4-bce4d6b12537:7
    generate blob:http://127.0.0.1:2718/653d2d32-3a13-4f33-81a4-bce4d6b12537:7
    getModelCode blob:http://127.0.0.1:2718/653d2d32-3a13-4f33-81a4-bce4d6b12537:7
    Uc blob:http://127.0.0.1:2718/653d2d32-3a13-4f33-81a4-bce4d6b12537:7
    zu blob:http://127.0.0.1:2718/653d2d32-3a13-4f33-81a4-bce4d6b12537:7
    init blob:http://127.0.0.1:2718/653d2d32-3a13-4f33-81a4-bce4d6b12537:7
    t blob:http://127.0.0.1:2718/653d2d32-3a13-4f33-81a4-bce4d6b12537:7
    setupTiles blob:http://127.0.0.1:2718/653d2d32-3a13-4f33-81a4-bce4d6b12537:7
    zd blob:http://127.0.0.1:2718/653d2d32-3a13-4f33-81a4-bce4d6b12537:7
    createModel blob:http://127.0.0.1:2718/653d2d32-3a13-4f33-81a4-bce4d6b12537:7
    execute blob:http://127.0.0.1:2718/653d2d32-3a13-4f33-81a4-bce4d6b12537:7
    this.id blob:http://127.0.0.1:2718/653d2d32-3a13-4f33-81a4-bce4d6b12537:7
    connection blob:http://127.0.0.1:2718/653d2d32-3a13-4f33-81a4-bce4d6b12537:7
    manageConnection blob:http://127.0.0.1:2718/653d2d32-3a13-4f33-81a4-bce4d6b12537:6
    manageInput blob:http://127.0.0.1:2718/653d2d32-3a13-4f33-81a4-bce4d6b12537:6
    Si blob:http://127.0.0.1:2718/653d2d32-3a13-4f33-81a4-bce4d6b12537:6
    initConnection blob:http://127.0.0.1:2718/653d2d32-3a13-4f33-81a4-bce4d6b12537:6
    init blob:http://127.0.0.1:2718/653d2d32-3a13-4f33-81a4-bce4d6b12537:6
    useConnection blob:http://127.0.0.1:2718/653d2d32-3a13-4f33-81a4-bce4d6b12537:7
    onmessage blob:http://127.0.0.1:2718/653d2d32-3a13-4f33-81a4-bce4d6b12537:7
    EventHandlerNonNull* blob:http://127.0.0.1:2718/653d2d32-3a13-4f33-81a4-bce4d6b12537:7
653d2d32-3a13-4f33-81a4-bce4d6b12537:6:122559

Validations ✅

• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a repository issue and not a framework-specific issue. For example, if it's a THREE.js related bug, it should likely be reported to mrdoob/threejs instead.
• Check that this is a concrete bug. For Q&A join our Community.
• The provided reproduction is a minimal reproducible example of the bug.