Long filenames in dropdown

[ayya-vimala]

See screenshot below. The entry for Tha-Ap is two lines and both lines are half disappearing under the previous and next lines.

[ayya-vimala]

The backend gives back two things for each entry: the category and the categoryname. The category is the key that you need to give back to the backend once selected, but that shouldn't be displayed. That is why you are getting everything double because the categoryname contains everything that needs to be displayed, including the category codes in brackets behind. Is there a way to remove the display of the category in the filter menus and just use the category as the key to communicate with the backend? That will solve a lot of your 'too-long-line' problems already and makes the display nicer.

(VV) Vimanavatthu (VV)
...
(PLI_SUTTAS-LATE-2) SUTTAS LATE-2 (ALL)
...

Should become:

Vimanavatthu (VV)
...
SUTTAS LATE-2 (ALL)
...

[aminahbl]

@ayya-vimala

There are two separate details here:

(1) the calculation to handled the line heights of varying title lengths. This is a FE issue, and the calculation can be looked at again.

(2) the return from the BE. In most cases we want the BE to do as much of the work as possible, but in this case, I think it's "doing too much" and trying to take care of formatting / rendering where it shouldn't.

This is a sample return from the categories endpoint and I think categoryname should only give the category name:

 {
            "category": "pli_Suttas-Early-1",
            "categoryname": "SUTTAS-EARLY-1 (ALL)"
        },
        {
            "category": "dn",
            "categoryname": "• Dīghanikāya (DN)"
        },
        {
            "category": "mn",
            "categoryname": "• Majjhimanikāya (MN)"
        },

[ayya-vimala]

@aminahbl - if it gives back just the categoryname param you would not get back correct category for the (ALL) ones. How are you communicate that to the backend?

[aminahbl]

I don't know how categoryname is composed. I guess it's just a predefined string, so can be anything...?

[ayya-vimala]

The idea was that the FE didn't need to do any calculations any more so didn't need to call all the collections and categories any more (only 1 API call that lists everything). So pli_Suttas-Early-1 is a collection. If someone clicks on SUTTAS EARLY-1 (ALL) the frontend sends the pli_Suttas-Early-1 param back to the backend, where it is converted to a list ['dn','mn','sn','an'] which is then fed into the database query so it finds matches of all 4 of these categories. If you just use the categoryname, this is no longer possible.

[aminahbl]

Yes, absolutely. All I mean is that maybe categoryname shouldn't include • and (DN)

[ayya-vimala]

I see. I think Sebastian's idea was that you can then plug it into the list without formatting while making a difference between the collections and the categories: Something like this:

SUTTAS-EARLY-1 (ALL)
• Dīghanikāya (DN)
• Majjhimanikāya (MN)
....

But I see you removed the dot ... is there a specific reason for that?

[ayya-vimala]

Even if it gives back only the categoryname stripped like this:

 {
            "category": "pli_Suttas-Early-1",
            "categoryname": "SUTTAS-EARLY-1"
        },
        {
            "category": "dn",
            "categoryname": "Dīghanikāya"
        },
        {
            "category": "mn",
            "categoryname": "Majjhimanikāya"
        },

That works for the categories like dn and mn and you can convert that to Dighanikaya (DN), etc. but it won't work for the collections where you would get SUTTAS-EARLY-1 (PLI_SUTTAS-EARLY-1) which is pretty ugly. Unless of course if you convert all the things that look like collections (starting with pli, skt, chn and tib) into an (ALL) at the frontend. So you would need to iterate through the list. And then when a user clicks on it you have to convert that back. That might work as long as BN still has only one language matches, but Sebastian is working on multilingual matches too.

[ayya-vimala]

@aminahbl - This is how it is right now on BN1. Do you have any ideas on how to do it and if the backend needs to give back something else than what it does now?

[aminahbl]

You mean right now on the preview site? I would be cautious about knowing what the exact latest status of this is. I have the idea that there is an update for this already in the pipeline.

[ayya-vimala]

No, I mean on BN1: buddhanexus.net I think the preview site (BN2) is still very much outdated and there is a lot that isn't merged yet.

[aminahbl]

Aaaah sorry! I actually read as "DN1" in the first time - the endless fun of dyslexia :joy:

[ayya-vimala]

I think what is needed here is a change in: category.ts on line 25. This should be: label: categoryname But I'm not entirely sure as I don't know the frontend.

In any case, the category should not be mentioned before the categoryname and the dot should not be removed from the response.

So in ListboxComponent.tsx the function trimName on line 36 needs to be removed entirely. And the return should be:

    <RowItem inheretedstyles={inlineStyle} {...dataSetProps} component="li">
      <ListItemLabelWapper maxLines={maxLines}>
        <Tooltip
          title={<Typography>{lable}</Typography>}
          disableHoverListener={!isTruncated}
          enterDelay={1500}
        >
          <ListItemLabel>
            {name}
          </ListItemLabel>
        </Tooltip>
      </ListItemLabelWapper>
    </RowItem>

Of course that also means that the other dropdowns, those with just the texts names, also miss their ID and need to be put in from the backend. But I think you already get this back in the form of textname separately. So you can for those just add textname behind the displayname of the text. Right now it also shows the file ID in front of the files and not their textname. (the difference is between dn1 and Dn 1)

[aminahbl]

Superseded by #183.

[ayya-vimala]

Moving this ticket to done column.