Generate bindings for remote canisters

Developers
1

I have a question about the feature explained here which is the command dfx remote generate-binding <canister name>. The given dfx.json example is:

{
  "canisters": {
    "<canister name>": {
      "main": "<path to mo/rs/ts/js file that will be generated>",
      "remote": {
        "candid": "<path to candid file to use when generating bindings>"
        "id": {}
      }
    }
  }
}

How can I build more than one bindings file? It seems I can only put one path in there so it can either be mo,rs,ts or js. What if I need two?

In other places of the dfx.json schema “main” seems to be used for an input. Here it is an output. Is that a hack?

When the canister type is “custom”, then the given example is not enough. I also need a “candid” and a “wasm” field on the level above, making the whole look like this:

{
  "canisters": {
    "<canister name>": {
      "type": "custom",
      "main": "<path to mo/rs/ts/js file that will be generated>",
      "candid": "...",
      "wasm": "....",
      "remote": {
        "candid": "<path to candid file to use when generating bindings>"
        "id": {}
      }
    }
  }
}

Is that intended? What if I only need the bindings, not the actual canister?

2

Why do you need multiple bindings?

3

Frontend code may be mixed js/ts and may need both bindings.

4

Short answer is you can’t. Do you have didc available? In that case you could didc bind for every type you need. It does basically the same thing

5

What about using the dfx generate?

For dfx.json as below:

{
    "canisters": {
        "internet_identity": {
            "type": "custom",
            "candid": "https://github.com/dfinity/internet-identity/releases/download/release-2024-03-01/internet_identity.did",
            "wasm": "https://github.com/dfinity/internet-identity/releases/download/release-2024-03-01/internet_identity_dev.wasm.gz",
            "remote": {
                "id": {
                    "ic": "rdmx6-jaaaa-aaaaa-aaadq-cai"
                }
            },
            "declarations": {
                "bindings": [
                    "js",
                    "ts"
                ]
            },
            "frontend": {}
        }
    }
}

Then simply running.

dfx build --check # download wasm & candid from urls
dfx generate

I got both js and ts bindings in the expected directory.

6

Yes, that is one of the work-arounds I have been using.

I was just trying to speed up CI and cut out as much as possible. Adding the dfx build step works but should not be necessary. Or is it very fast in this case because the wasm is already supplied, i.e. no compilation happens?

didc also works as a work-around. I just wanted to skip the installation step for didc if possible.

Anyway, it’s ok to do one of the two. Just wanted to clarify what dfx remote generate-binding can do.

1 Like
7

The dfx build step is there to make sure that the files are available locally. You only need to run it once when you add a remote canister in dfx.json. dfx remote generate-binding also needs it.

IMO, we should not have dfx remote generate-binding. The general dfx generate can cover the use cases of remote canister very well and doesn’t have the limitation you encountered.

1 Like