Feature Request: the Candid Web UI should label input fields with arg name in addition to type when available

[luc-mercier]

Example: in a .did file I have:

type ProposalId = nat64;
service : {
  "change_proposal_deadline_for_tests": (proposal_id: ProposalId, timestamp_unix_epoch_nanos: nat64) -> ();
}

In the web UI, I get 2 input fields both labelled nat64 --- so it's hard to tell apart the 2 arguments. It'd be nice if the Web UI would also display the arg name, here proposal_id and timestamp_unix_epoch_nanos.

[chenyan-dfinity]

This is unfortunately a feature, not a bug. The spec says the argument name is immaterial, and is ignored by the parser. There could be someway to display the type name ProposalId instead of nat64, but with the current implementation, it's also not easy to do.

Another workaround is to use record type for input arguments, e.g. record { proposal_id: nat64; timestamp: nat64 }. Then the web UI can display it properly.

I think the ultimate solution is to provide a way for users to specify how they want the method is be rendered. Even for a nat64, you may want to use a slider instead of an input box. But I haven't figured out a good API for this.

[luc-mercier]

This is unfortunately a feature, not a bug. 🤣

Well then, I guess we can close this. (Your argument makes sense, but it's still amusing to me to call it a feature)

[nomeata]

The spec says the argument name is immaterial, and is ignored by the parser.

It is immaterial for the purposes of serialization and subtyping (which the spec puts its main focus on, maybe too much), but it is absolutely fine to use that information in documentation and UI!

It’s like with blob vs. vec nat8 – the difference is immaterial to typing and serialzation, but other uses of Candid (documentatoin, code generation, type import) is welcome to consider the difference, and we do.

[chenyan-dfinity]

It is immaterial for the purposes of serialization and subtyping (which the spec puts its main focus on, maybe too much), but it is absolutely fine to use that information in documentation and UI!

Agreed. All our current implementations also focus on serialization, so it's some work to extend the support there. But I'm not sure it's the best solution for UI:

I think the ultimate solution is to provide a way for users to specify how they want the method is be rendered.

For UI, some people may prefer to use the label and some not. So it's better to have an API/DSL to specify these. This also ties to quickcheck for Candid, where we need a DSL.