Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extending StoryblokComponent with pageData prop for context passing #1253

Open
1 task done
edvinasjurele opened this issue Oct 15, 2024 · 3 comments
Open
1 task done
Assignees
Labels
dx [Issue] Improvement or fix with impact on the developer experience. has-workaround [Issue] Temporary solutions available. p2-nice-to-have [Priority] Lower priority, beneficial enhancements that are not urgent. pending-author [Issue] Awaiting further information or action from the issue author pending-triage [Issue] Ticket is pending to be prioritised

Comments

@edvinasjurele
Copy link

Description

Context / Problem

As we know, NextJS does not have native data passing mechanism from server to server component (something like Astro has Astro.locals, which is available in components, middleware and endpoints), hence we can only use prop-drilling in NextJS.

Here is a quick comparison of the mechanisms available in Astro vs NextJS:
image

NextJS has reasons for not having this, and it's due to segmentation (explained here vercel/next.js#43704 (comment)). For the same reasons, you can't access the URL / Pathname information in server components.

Suggested solution or improvement

Workaround with Storyblok approach

However, not having the possibility to pass data server-to-server can be a challenge, there is a pattern how can we overcome this, and here is how?

There might be users who want to implement the following use cases (just a few examples):

  1. Fetch the data from CMS about the page theme - light / dark - and switch descendant components look based on that
  2. Fetch pricing plan data for the whole page and pass down the information for various deeper components to consume so data like price or discount, can be used in multiple components without the need to fetch them in each instance.
  3. When rendering f.e. [...slug]/page.tsx), resolve the "locale" for the page and pass it down to Storyblok components so they can react to it, hence pre-render language switcher choices according to business logic.

The pattern we use is to always pass pageData prop to StoryblokComponent:

<Section
  heading={headingBlok && <StoryblokComponent blok={headingBlok} pageData={pageData} />}
  subheading={
    subheadingBlok && <StoryblokComponent blok={subheadingBlok} pageData={pageData} />
  }
  {...storyblokEditable(blok)}
>
  {content &&
    content.map((contentBlok) => (
      <StoryblokComponent blok={contentBlok} key={contentBlok._uid} pageData={pageData} />
    ))}
</Section>

So we always know that the other component has access to that contextual data. The only thing is that developers should not forget to pass that data down each time in component implementation - this might have the potential to be enforced by wrapping StoryblokComponent with custom logic and using it, or the component in this SDK could do so.

Closing remarks

This may not necessarily be something to implement or do in the code, as it is possible to implement in projects even now, because StoryblokComponent implementation allows us to pass any rest props down to components, but I am sure this pattern could be outlined somewhere in the documentation of the SDK as an example of how to achieve one or the other sophisticated pattern.

Additional context

No response

Validations

@edvinasjurele edvinasjurele added pending-author [Issue] Awaiting further information or action from the issue author pending-triage [Issue] Ticket is pending to be prioritised labels Oct 15, 2024
@edvinasjurele
Copy link
Author

@edodusi as per your request, raising this issue to share how we do. Hopefully it will be helpful.

@edvinasjurele
Copy link
Author

The best thing that this approach works with both client and server components :)

@edodusi edodusi self-assigned this Oct 15, 2024
@edodusi edodusi added dx [Issue] Improvement or fix with impact on the developer experience. p2-nice-to-have [Priority] Lower priority, beneficial enhancements that are not urgent. has-workaround [Issue] Temporary solutions available. labels Oct 15, 2024
@edodusi
Copy link
Contributor

edodusi commented Oct 16, 2024

Thanks @edvinasjurele!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dx [Issue] Improvement or fix with impact on the developer experience. has-workaround [Issue] Temporary solutions available. p2-nice-to-have [Priority] Lower priority, beneficial enhancements that are not urgent. pending-author [Issue] Awaiting further information or action from the issue author pending-triage [Issue] Ticket is pending to be prioritised
Projects
None yet
Development

No branches or pull requests

2 participants