Make blueprints previews adjustable to window height

[nightnei]

Related issues

• Fixes STU-766

Proposed Changes

With this PR we increase height of Blueptints' previews when window height is more then 680

Testing Instructions

1. Run Studio
2. Click on "Add a site" -> "Start from a blueprint"
3. Increase/decrease window's height
4. Assert that if it's kess then 680px then we see short preview and on oposite we see tall ones
5. Also assert that we never see scroll, when the height is more then 600px (default Studio's height)

600-679px	680+px

[katinthehatsite]

In terms of this PR, it works as described and the height of the previews increases based on the window height 👍

I am not sure if it was discussed already but I am finding the presence of the scrollbar on the smallest screen a slightly not cohesive in the UI. I am wondering if there was a way to fit everything on the smallest screen so that there is no need for it 🤔

[nightnei]

I am not sure if it was discussed already but I am finding the presence of the scrollbar on the smallest screen a slightly not cohesive in the UI. I am wondering if there was a way to fit everything on the smallest screen so that there is no need for it 🤔

@katinthehatsite Hm, maybe I misunderstood your message, but yes - avoiding scroll om small (default 600px height) screen is the main goal of the trick with previews' height:

1. Marina wanted to have tall previews, but our default height is 600 so if we keep tall previews then we would have scrollbar, that's why windows with 600-679px of height has short previews.
2. But when teh height of window is more then 680 then we have tall previews, according to the design.
   As a result, in both cases we don't have scroll.

[bcotrim]

Nice work, it's looking good!
You might consider using CSS media queries instead of JavaScript for this:

  className={cx(
    'w-full h-32 object-cover object-top cursor-pointer',
    '[@media(min-height:680px)]:h-48', // CSS handles the responsiveness
    // ... other classes
  )}

Benefits:

• No resize event listeners or state management needed
• Better performance (browser handles natively)
• Simpler code maintenance

What do you think?

[katinthehatsite]

Marina wanted to have tall previews, but our default height is 600 so if we keep tall previews then we would have scrollbar, that's why windows with 600-679px of height has short previews.
But when teh height of window is more then 680 then we have tall previews, according to the design.
As a result, in both cases we don't have scroll.

On interesting because I do see the scrollbar on the smallest screen on my end (either on this PR or on trunk) while resizing to the smallest possible screen. This is where my comment was coming from:

Perhaps I should add that I also resized it to the smallest possible width along with the smallest possible height.

[sejas]

From that last screenshot, I see the tags cover two lines. I wonder if we could keep them in one line for the smallest screen width, and if that would help with the scroll.

[nightnei]

@bcotrim thanks, I didn't knwo about this oportunity and Cursor didn't tell me too 😅

[nightnei]

@katinthehatsite got it, you meant not 900x600, but the smallest possible option. To fix it I will go with what Antonio proposed, to keep tags always inside 1 line.

[nightnei]

@katinthehatsite fixed this way. I think it's enough and it's unnecessary to polish cutting at the right side, otherwise we will add tricky code (for ellipsis or something similar) to cover non-critical edge cases. WDYT? Are you ok with it?

[bcotrim]

@nightnei we recently introduced some changes to display a "+X more" element when we have more than 3 categories.
Could we maybe adjust this logic to display that element when the categories don't fit in one line?
It would prevent the categories from being cut

[katinthehatsite]

I had a chance to take a look and I am seeing the same issue as Bernardo with the tags being cut off:

One option might also be to make the tags/ tabels themselves smaller.

[nightnei]

@nightnei we recently introduced some changes to display a "+X more" element when we have more than 3 categories.
Could we maybe adjust this logic to display that element when the categories don't fit in one line?
It would prevent the categories from being cut

Do you have a proposition of logic to cover it? Any polished solution, most likely, will add a lot of lines of code and I am not sure that it's reasonable... Actually, I find the initial scrollbar approach as the most pragmatic decision. If a user wants to work with the smallest possible screen, then they should expect to have scrollbars etc. WDYT about reverting one-line-approach and keeping scroll for the smallest screen?
cc @katinthehatsite @sejas

[sejas]

I think for a full solution we would need to observe if the last tag appears fully or not.
A mid-term solution could be showing only two tags +X for small windows.

[nightnei]

A mid-term solution could be showing only two tags +X for small windows.

It's an option, but I don't find it as a good approach, since we sacrifice rendering tag for our users due to low amount of users who use the smallest size of window and just to avoid rendering scrollbar.

I think for a full solution we would need to observe if the last tag appears fully or not.

What about resizing the window, probably it should be recalculated. Also, what if we have 1 very long tag for some blueprint in the future. Personally, for me, it sounds like overkill for a non-critical thing.

I would vote for reverting to keepign a few lines of tags for teh smallest screen and seeing scrollbar. But I don't mind any decision.

[sejas]

The good part is that these tags come from our backend, so changing them should be easy.

It's an option, but I don't find it as a good approach, since we sacrifice rendering tag for our users due to low amount of users who use the smallest size of window and just to avoid rendering scrollbar.

That's why I suggest showing two tags in the smallest width, 3 tags in the regular or higher width. Although It might bring issues when the tags are in different languages.
Then, I would suggest implementing a full solution, monitors which labels are visible and which are not.
I also considered CSS container queries, but because the tags could change I think we'll need to use JS anyway.

[bcotrim]

LGTM 👍

[sejas]

Thanks for creating useOverflowItems ✨