chore: reduce Searchbox button layout shift

[rjborba]

Description

This is a small tweak to prevent the Cumulative Layout Shift caused by the lazily loaded Search Button Component. The ‘final’ solution would be to support SSR in orana-ui-components, which we are actively working on, but still no ETA.

Validation

Compared to the old behavior, where the items on the right-hand side of the navbar would shift positions, now the items remain fixed. The only change is that the SearchBox is displayed in place of the previously empty space

Related Issues

No issues were created for it

Check List

• I have read the Contributing Guidelines and made commit messages that follow the guideline.
• I have run npm run format to ensure the code follows the style guide.
• I have run npm run test to check if all tests are passing.
• I have run npx turbo build to check if the website builds without errors.
• I've covered new added functionality with unit tests if necessary.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
nodejs-org	✅ Ready (Inspect)	Visit Preview	Jan 3, 2025 7:47pm

[github-actions]

Unit Test Coverage Report

Lines	Statements	Branches	Functions
	84.47% (631/747)	65.37% (185/283)	83.91% (120/143)

Unit Test Report

Tests	Skipped	Failures	Errors	Time
137	0 💤	0 ❌	0 🔥	4.96s ⏱️

[ovflowd]

Hey @rjborba Im adding a skeleton component on a sibling PR, would you mind using it once that PR gets merged? That would even improve the rendering IMO.

Also looking forward for the SSR support, or at least even if not being SSR compatible, if you could move all window API calls to Hooks, that would already do it.

Right now React is bailing out initial page pre-rendering due to the component using window APIs on mount. I would recommend simply making all these aspects of the component behind Hooks/asynchronous.

[github-actions]

Lighthouse Results

URL	Performance	Accessibility	Best Practices	SEO	Report
/en	🔴 73	🟢 100	🟢 100	🟢 91	🔗
/en/about	🟢 99	🟢 100	🟢 100	🟢 91	🔗
/en/about/previous-releases	🟢 99	🟢 100	🟢 100	🟢 92	🔗
/en/download	🟢 99	🟢 100	🟢 100	🟢 91	🔗
/en/blog	🟢 100	🟢 100	🟢 96	🟢 92	🔗

[ovflowd]

@rjborba you can rebase now :)

[rjborba]

@ovflowd Hi! I couldn't find the PR you mentioned, but I found a Skeleton component and I'm using it. Can you please check if this is the right component/behavior? Thank you!

[canerakdas]

We are loading Instrument Sans font on the pages additionally for the search box button, which causes a slight layout shift while loading process

IMO we can directly use the Open Sans we use on the pages. Adding typography information to the configuration looks to be sufficient;

export const themeConfig = {
  typography: {
    '--font-primary': 'var(--font-open-sans)',
  },
  colors: {
    ...

[canerakdas]

Suggested change

	.searchButtonSkeleton {
	@apply flex-grow;
	}
	.searchButtonSkeleton {
	@apply my-px
	mr-2
	flex-grow
	rounded-xl;
	&:empty {
	@apply h-10;
	}
	}

We can make the height and radius of this area a little more similar to the search box button

[canerakdas]

Ah, my bad 😅 The given height is not visible because the order of styles changed after the build, can you update it with a more specific class name?

Something like;
.searchButtonSkeleton[data-inline-skeleton] or span.searchButtonSkeleton should work

[rjborba]

@canerakdas All your requests should be now fixed. Would you mind to double check? Thank you!