search

polkadot-api / papi-console

Polkadot dev console powered by polkadot-api
https://dev.papi.how
GNU Affero General Public License v3.0
6 stars 2 forks source link

Some "RawX" types aren't user friendly #12

Open Tbaut opened 3 days ago

Tbaut commented 3 days ago

Some pallets calls have Raw0, Raw1... types. Such as the Identity.set_identity on the people chain. Because of this, users have no idea what type they should select and input.

image

josepot commented 3 days ago

I couldn't agree more. However, I don't quite understand why you are opening this issue here. This is how the pallet has defined this field... In order to make sure that the length won't take more than one byte they have defined it as an enum... 🤷 This makes this kind of data very, very difficult to consume: both as an input and as an output. If you want to complain, you should open an issue on the PolkadotSDK repo, not here.

That being said, the console actually makes it fairly easy for the developer to know what option to enter, eg:

https://github.com/user-attachments/assets/2fd85ce7-09c8-4381-8514-d0eac442aa20

Please, let's keep in mind that this is a dev-console. It's meant for developers, not for normal users, I expect a developer to know how to pick the right variant if they are provided with an error that tells them the byte length that they have actually entered. I don't think that it's very reasonable for us to create a custom component for an atrocity like this kind of data that probably shouldn't exist in the first place.

Tbaut commented 3 days ago

We were talking with @voliva and he suggested this repo for me to open an issue. I don't want to complain, I want to help, and I would appreciate a more welcoming answer!!

I expect a developer to know how to pick the right variant

this is wrong in my case, if you accept my humble person as a dev. I had no idea those RawX were for the length. The error message is super helpful though. Feel free to close if you think it's not useful to track this.

josepot commented 3 days ago

I don't want to complain, I want to help, and I would appreciate a more welcoming answer!!

You misunderstood my words. I don't think that complaining and helping are at odds. Complaining is good, it helps improve things. I'm just saying that I really don't want to spend a single minute creating a custom component for this atrocious data-structure, because IMO this is something that should be fixed upstream.

I'm sorry if my answer came across as unwelcoming... I actually started by saying that I couldn't agree more and I also showed you how the console is hinting the variant that should be selected.

Anyways, I'm of the opinion that there are some custom components that are a lot more important and that would bring a lot of value. For instance, when using System.set_storage it would be awesome to display a component that allows users to select a custom storage entry and a valid value for that storage entry. I much rather prioritize these kinds of custom components, which are super important for doing any kind of development work on any network.

I haven't closed this issue b/c I'm still on the fence on whether it's worth it for us to create custom components for things like this. It's similar to the vote on ConvictionVoting.vote, these things are def not a priority ATM... However, the could eventually become a priority (not in the near future, though).

Tbaut commented 2 days ago

Hehe all good, I know you and your way of arguing! And I know papi is not responsible for this atrocious data structure. But we have to deal with it regardless. And just like for the conviction, it's either we all do the job in every Dapp, or the lib everyone uses does it (better). It's understandable that it's not a priority though.