Correctly render dag tags when there are MAX_TAGS + 1 tags

[amoghrajesh]

closes: #50639

Previously, when the item count was maxItems + 1, the last visible item and "+1 more" were rendered without a separator, leading to formatting issues. This fixes the logic to include the separator in this specific edge case.

For 3 tags:

For 4 tags:

FOr 5 tags:

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[shubhamraj-git]

Looks good.
One comment : I can see 2 commas in case of 5 tags.

[amoghrajesh]

@shubhamraj-git i realised that and pushed a fix for it now, updated the images too.

[bbovenzi]

What are you trying to solve here?

The reason I had that logic before is because "+1 more" is just as long as just showing that one extra tag. So we should only use the overflow once it actually saves us space

[natesinger]

How much of a pain would it be to show the full list vertically stacked on hover over the + element? Suppose we can address in a subsequent pull but jw because in this case we have no access to the full list of tags once truncated. On a tooltip I mean.

[amoghrajesh]

What are you trying to solve here?

The reason I had that logic before is because "+1 more" is just as long as just showing that one extra tag. So we should only use the overflow once it actually saves us space

@bbovenzi the current behaviour without this fix is a squash of MAX_LEN'th element in the tags.

My tags: tags=["events", "bronze", "download", "mlb"],

I guess we can either show a "+n more" in a more generic sense which is for n > MAX_LEN or just do something more better. We cannot have the last 2 tags concatenate.

[pierrejeambrun]

Nice, I think as Brent mentioned we need a little bit of both. There's no point showing +1 more we might as well show the last tag at this point.

But indeed in that particular scenario we need a correct separator between the max and max + 1 tag. (not a concatenation the two tags as you highlighted)

[amoghrajesh]

There's one thing though -- "+1 more" will be much much shorter than having a tag of max_len, defined as TAG_MAX_LEN = 100.

So should we have some logic that something in between? Show the min of the two?

[pierrejeambrun]

Indeed +1 more will be shorter if the extra tag name is really long, but we don't have logic based on the tag length at all. And if we do that for the latest tag should also do it for previous tags.

I wouldn't bother going down that rabbit hole for now.

[amoghrajesh]

Definitely yes

[amoghrajesh]

@pierrejeambrun / @bbovenzi how do you suggest we proceed with this one?

[pierrejeambrun]

I would only solve the current case of a missing , separator when there are max + 1 tags, between max and max + 1 items.

[amoghrajesh]

Sounds fair, yeah.

I have handled that case and pushed a fix for it. Also updated PR desc and title.