The Candid UI is a fantastic tool when you want to quickly test your backend APIs from the browser. The compelling reason to choose it over using dfx canister call is because it lets you pass in arguments to your functions without having to Candid encode them.
This is a fantastic feature and beats having to try to appease the dfx gods as you try to get your Candid encoded arguments right multiple times on the terminal.
However, the Candid UI only lets you make calls as the anonymous principal. There’s no way for you to impersonate/authenticate a different principal and you need to fall back to using dfx if you need to make authenticated calls.
Please consider adding this to the Candid UI roadmap. A mechanism to add authentication to Candid UI. Would really help with service testing/discovery.
Would make it almost as friendly as what GraphiQL is to GraphQL
Integrating with internet identity is easy to do, but we cannot get the same identity as logging in from the frontend, because the principal is derived based on the frontend canister id (real frontend vs candid UI). There is also not an easy way to import dfx identity in agent-js.
Have you tried ic-repl? It’s almost like a textual version of Candid UI and supports all identities from dfx.
I’ve tried IC-repl for trying out integration testing. It doesn’t really fulfil the same use case that Candid UI does.
If I have to mess around with the CLI and learn/figure out the syntax for another tool, that defeats the purpose of wanting something like Candid UI. We underestimate the power of UI tools for discoverability/exploration.
I understand the technical limitation of not being able to login using the same identity on Candid UI.
I guess a reasonable expectation is a UI for IC-repl in that case. Basically, what I’m trying to get at is being able to visually see and call the canister’s API without having to type out esoteric commands that I need to lookup from a documentation is a superpower.
And when said API needs authenticated calls, that should be supported by the tool. It doesn’t have to be Internet Identity if that’s not possible but the minimal friction way, could even be a dfx identity that can be created/selected from the UI of the tool itself.
I suggested Candid UI be enhanced because that’s the default tool shipped along with the dfx replica deployment experience where its URL is made available in the terminal logs is ideal.
Consider this thread as a wishlist/feature request rather than a request that I need help solving immediately.
Sure, it’s certainly possible to add II to Candid UI.
I’ve tried IC-repl for trying out integration testing. It doesn’t really fulfil the same use case that Candid UI does.
I’m curious about this. My personal experience is that ic-repl is much more suited for testing than Candid UI for several reasons:
In Candid UI, you need a lot of mouse clicks for a moderately complicated Candid type;
In ic-repl, after typing in the canister method name, it generates a random value of the method type, so that we don’t have to look up the Candid syntax. It’s not perfect, but the saving for mouse clicks is a major time saving for me; Adding a full featured auto-completion will certainly make it more beginner friendly.
In terms of discoverability, in ic-repl, after typing the canister id, if you press tab, it will also show all the canister method of this canister id in textual format.
In Candid UI, you cannot take the return result from a previous call and feed them into the next call, or writing any assertions about the return result. This is all possible in ic-repl.
It also gets complicated when you want to make calls to several canisters in Candid UI.
If you want to put the test into CI, you will either need ic-repl or a bash script with dfx.
In summary, my feeling is that ic-repl is more scalable than Candid UI. We want to improve the UX for both tools, but Candid UI will be positioned more as casual use, while ic-repl will be used more in testing and deployment.