Gnoland shows an input instead of a textarea when body.type=textarea

[grepsuzette]

Description

Consider this URL: https://test3.gno.land/r/demo/boards?help&__func=CreateThread&bid=1&body.type=textarea

The intention seems to have the body field shown as a <textarea>. Yet it appears as a single-lined, sad and boring <input>.

[tbruyelle]

Hey @grepsuzette I also came across this for an other contract and yes it would great to have a <textarea> for long strings.

The problem is how to detect a string is a long string ? What is returned by the vm/qfuncs query for CreateThread looks like :

 {
    "FuncName": "CreateThread",
    "Params": [
      {
        "Name": "bid",
        "Type": "uint64",
        "Value": ""
      },
      {
        "Name": "title",
        "Type": "string",
        "Value": ""
      },
      {
        "Name": "body",
        "Type": "string",
        "Value": ""
      }
    ],
    "Results": [
      {
        "Name": "_",
        "Type": "uint64",
        "Value": ""
      }
    ]
  }

I think it's read directly from the method parameters, so IMO the only way to add properties like long string would be to support method metadata in comments.

For instance :

//gno:parameter body long-string
func CreateThread(bid BoardID, title string, body string) PostID {

Then we need to add all the logic to parse such metadata! Definitively not a small task.

An other idea would be to add a small button near each <input>, and if the user clicks on it it turns into a <textarea>. A lot simpler actually.

Do you have an other idea on your side ?

[grepsuzette]

If a variable starts with "body", the template view (realm_help.html) could render it as a textarea. Until a more involved effort for this is planned.

I think it's read directly from the method parameters, so IMO the only way to add properties like long string would be to support method metadata in comments.

Wouldn't a def type MediumText string work in that case? (Though I prefer above solution. In the end the ?help page is for developers only).

[grepsuzette]

You can take a look at the PR. The JS part is not done yet.

[tbruyelle]

If a variable starts with "body", the template view (realm_help.html) could render it as a textarea

Very simple I like it

Wouldn't a def type MediumText string work in that case?

Should work also, but where do you declare this type ? Should be in p/ui probably. Then maybe you'll face annoying type conversion issue.

[thehowl]

Using body as a magic word for multi-line strings doesn't really convince me, honestly. And neither do giving definitions in code of whether a string should be long/medium/short. I personally think the preference should stay as a graphical thing on the website, which can be manipulated through query strings.

I would extend on body.type=textarea (so syntax <variable>.type=<input_type>), and then maybe extend it to support also [<gnoType>].type=<input_type>. This way we can make it so that [string].type=textarea expands all string fields to a textarea, and also add a link to do that at the top of the help page.

(I think this should also be generic inside of the code - a nice feature to add on top of this may be to make all integer and float types an <input type="number"> by default, but overridable by doing [int].type=text...)

[grepsuzette]

Before this PR I tried to replace all <input> with <textarea> with height: 1em in the code. It looked like the linear inputs we have now, but with a little triangle in the bottom-right to extend the size as required. It did feel a bit sacrilegeous.

A discrete link or checkbox to toggle multiline edit would work better I guess.

Now let's take look at body.type=textarea. I researched this last week before posting this issue. It is actually generated by the links of r/demo/board:

func (board *Board) GetPostFormURL() string {
    return "/r/demo/boards?help&__func=CreateThread" +
        "&bid=" + board.id.String() +
        "&body.type=textarea"
}

Do we really want to edit our links in this way? Maybe, but in my opinion it's pointless. Hopefully this will be obsolete in 2 months anyway ;)

BTW I know where you're coming from about the start with "body" thing. The PR actuall has only one line about it:

return "needsToShowAsTextarea", func(fieldName string) bool {
    return strings.HasPrefix(fieldName, "body")
}

The point was that from there it would have been easier to build a better implementation, for instance if we decided the gotuna route for ?help to fetch the realm code to extract semantic comments about the fields.

No big deal for me whatever we decide, I just wanted to show an idea, there are many possibilities.