Map and Buckets Example -> Candid definition not generated

I am further trying to implement the “Map and Buckets Pattern” ( (GitHub - Forum1 - Forum2) but, am now facing an issue with the automatically generated Candid definition.

When I run dfx build it does generate the definition for the main actor (“Map”) but, does not generate the definition for the class actor (“Bucket”).

Is that a known issue? Or do I need in that particular case to implement something so that Candid also generates the types for the sub-canisters?

The Motoko code I implemented so far: deckdeckgo/studio/canisters/decks at feat/one-deck-one-canister · deckgo/deckdeckgo · GitHub

update: I can add my sub-actor in dfx.json to generate the types but then, if I wish to deploy, it asks me to register a canister id in canister_ids.json which I don’t want to, as these canisters should be generated on the fly.

So what I did, I add it to dfx.json, generated the types and then removed the entry in dfx.json to be able to deploy. Not sure if it is the expected behavior or is there a configuration flag that says such canister should not be listed in canister_ids.json to not block the deployment?

You’re link doesn’t work for me, though I can navigate to the repository, I’m not sure what code to look at.

FWIW, the Motoko compiler will only emit Candid types for the types that appear in the interface of the main actor. If the buckets are actually only used internally, their types won’t appear in the .did file.

Depends what you mean with “internally”. I’ve got a canister “Map” that generates a class actor canister “Bucket”. So yes to some extension these buckets are internal as not consumed by any other canisters but, are not internal because they are used in my web app (example).

Therefore, is there a way to generate the .did files for “internal” canisters?

Right now, as a workaround, I added these temporarily to my .dfx, ran dfx build to get the .did files and then reverted my changes in .dfx but, it isn’t really convenient (I think I even fck up one of my test canisters while trying back and forth :sweat_smile:),

Hmm, I’m getting lost in your code and cannot fully understand what is going on.

I suspect Decks is only giving a weakly typed view of the bucket principals and your UI code then needs to access a separate did file to work with those bucket principals at their proper interfaces. But maybe I’m misunderstanding.

I believe you can generate the did file yourself by invoking the moc compiler with flag --idl on the actor class. You might have to strip out the service argument yourself though to use it (not sure about the javascript handling of this).

Dfx installs the moc compiler somewhere under ~/.cache/dfinity/versions/0.8.0/ (as well as the base library whose path you’ll need to pass to moc’s as --package *base* *path* command line argument).

1 Like

Exactly. Decks gives back Principal ID and then the frontend access these buckets. I use TypeScript, therefore need a strong typing on the frontend side, therefore the need of the .did files for these.

Thanks! It seems one argument is missing, the compilet hangs. Maybe the output?

But it’s alright, I was hoping for a solution built-in with dfx. I’ll try to go forward with my workaround.

❯ /…/.cache/dfinity/versions/0.8.0/moc --package /…/.cache/dfinity/versions/0.8.0/base/ /…/canisters/deck/
Motoko compiler (source dphsbbg2-hx7ajr94-7j7higa7-v6hfzw6m)
❯ (here nothing happens)

Sorry for the delay, but something like this works (-o Buckets.did is optional):

crusso@vm:~/examples/motoko/classes$ ~/.cache/dfinity/versions/0.8.0/moc --package base ~/.cache/dfinity/versions/0.8.0/base --idl src/map/ -o Buckets.did
crusso@vm:~/examples/motoko/classes$ dir
Buckets.did  dfx.json  Makefile  src
crusso@vm:~/examples/motoko/classes$ more Buckets.did 
type Value = text;
type Key = nat;
type Bucket = 
 service {
   get: (Key) -> (opt Value);
   put: (Key, Value) -> ();
service : (nat, nat) -> Bucket
1 Like

No worries, I also worked on something else (writing a blog post about the map-bucket architecture basically for web apps)

This works like a charm for the .did file :partying_face:

Don’t want to bother you to much, but do you know if there is another option in addition to --idl to generate also the .js and .d.ts files? or are these generated by dfx?

A dfx generate types command is in our current SDK sprint


Yes, looking forward!

In the meantime you can pass the .did file through didc’s bind command to generate the js and ts bindings:

(Or paste it into a simple GUI for this here: )


Nice! That will do the trick too, thx :+1: