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?
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 ),
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).
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.
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
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?