As a self-proclaimed lazy developer, there’s nothing more important to me than having my tools “just work”. I’ve been frustrated by the fact that we are able to generate typescript declarations from a candid file, but that there has been no common pattern for getting nicely inferred types from our auto-generated actors. That is changing soon.
Changes to dfx
The file structure inside of .dfx/local/canisters/{canister_name} will change a bit. {canister_name}.js is renamed to index.js, and {canister_name}.d.ts is now {canister_name}.did.d.ts.
The new index.js will be significantly different, as well. Now, instead of exporting the canisterId and the idlFactory from the .did.js file, we have a createActor function that initializes the actor with sensible defaults. It now relies on process.env as a pattern to recognize the canister id, and returns an actor that has been automatically linked with the _SERVICE types from the typescript declarations.
To support the new process.env patterns, there are also changes to the default project. Webpack.config.js is now slightly simplifed, and assumes you will be generating a single webpack config. It comes along with npm start, giving you hot reloading with asset management and a proxy to localhost:8000 by default.
Package.json will also be modified with a new “copy:types” command. As a postbuild step, npm will copy the autogenerated types out of .dfx/local and into your src directory, allowing you to commit the files.
Moving the files is necessary for correctly inferring types from the auto-generated code, and the alias pattern we had been using in webpack created difficulties when working with TypeScript or using bundlers other than Webpack.
Request for comment
How do you feel about these changes? There will be incremental improvement from this point forward, but this may be a breaking change for some of your frontends. I hope that the benefits pay off though!
This is very helpful for beginners. Right now we have a factory file that creates Actor instances, but this change would make that almost entirely obsolete.
@Hazel created a shell script to generate candid types and TypeScript types, which works, but I can imagine that people that just got started will have a hard time figuring that out so that’s also more than welcome.
I don’t suspect this will require big changes to our codebase to tie things together again.
Down the road I’ll replace the “copy” step with a “generate types” step that will be configurable in dfx.json. The starter code is only a starting point though, and there will need to be additional configuration if you start to talk to more canisters. I wanted to get the particularly disruptive changes all out at once, though
This is really good to hear! This will move us closer to more intuitively integrating with other front end frameworks such an Angular. Look forward to seeing the change, please keep us posted.
That’s a Motoko language feature, and I don’t think there’s much of a roadmap for the motoko plugin right now. I’ll bring it up with the team, at least!
Tried the new version 0.7.6 on MacBook pro Big Sur 11.4 dfx --version dfx 0.7.6
dfx new test_me dfx start
I get that error
Stopping icx-proxy...
Stopped.
dyld: Library not loaded: /nix/store/2v68by9vfqg4i555apwxxkxpwa67x6m1-openssl-1.1.1i/lib/libssl.1.1.dylib
Referenced from: /Users/my_macos/.cache/dfinity/versions/0.7.6/icx-proxy
Reason: image not found