Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

[✨] Allow data to be passed in StaticGenerateHandler #37

Closed
adaliszk opened this issue Apr 28, 2024 · 1 comment
Closed

[✨] Allow data to be passed in StaticGenerateHandler #37

adaliszk opened this issue Apr 28, 2024 · 1 comment
Labels
[STAGE-2] incomplete implementation Remove this label when implementation is complete [STAGE-2] not fully covered by tests yet Remove this label when tests are verified to cover the implementation [STAGE-2] unresolved discussions left Remove this label when all critical discussions are resolved on the issue [STAGE-3] docs changes not added yet Remove this label when the necessary documentation for the feature / change is added [STAGE-3] missing 2 reviews for RFC PRs Remove this label when at least 2 core team members reviewed and approved the RFC implementation

Comments

@adaliszk
Copy link

adaliszk commented Apr 28, 2024

Is your feature request related to a problem?

I'm trying to load non-serializable data, typically JSX, with the statically generated routes. However, when building imports dynamically, the frameworks force serialization, or I must skip that and cannot render with SSR.

Describe the solution you'd like

I would like it if there would be a way to pass a Content JSX function for each statically generated route on build time so that when it gets rendered, there would be a <Content /> component to be used and inlined without trying to serialize into JSON.

So ideally, something like:

export const onStaticGenerate: StaticGenerateHandler = async () => {
    const slugs = ["foo", "bar", "qux"];
    const contents = {}
    for await (const slug of slugs) {
        contents[slug] = await readMarkdown({ file: `../../content/${slug}.md` });
        // ^ yields a { frontmatter: Record<string, unknown>, Content: () => JSXNode }
    }
    return {
        params: slugs.map((slug) => ({ slug })),
        data: contents,
    };
};


export default component$(() => {
    const { params, data } = useLocation();
    const { Content } = data

    return (
        <>
            <h1>/{loc.params.slug}</h1>
            <Content />
        </>
    );
});

Describe alternatives you've considered

The dynamic import works with noSerialize, but when navigating around in development mode, the contents disappear. I considered forcing the compiler somehow, not automatically, to serialize a JSX function, but I found no suitable solution.
As an alternative, I also considered just generating index files with all the contents already imported statically, but before I commit to that solution, I wanted to raise a request here.

Additional context

I have a repository where I am trying to implement this; it can be opened in stackblitz at: https://stackblitz.com/github/adaliszk/web-sandbox/tree/develop/apps/qwik-website

@gioboa
Copy link
Member

gioboa commented Oct 14, 2024

We moved this issue to qwik-evolution repo to create a RFC discussion for this.
Here is our Qwik RFC process thanks.

@gioboa gioboa transferred this issue from QwikDev/qwik Oct 14, 2024
@github-project-automation github-project-automation bot moved this to In Progress (STAGE 2) in Qwik Evolution Oct 14, 2024
@github-actions github-actions bot added [STAGE-2] incomplete implementation Remove this label when implementation is complete [STAGE-2] not fully covered by tests yet Remove this label when tests are verified to cover the implementation [STAGE-2] unresolved discussions left Remove this label when all critical discussions are resolved on the issue [STAGE-3] docs changes not added yet Remove this label when the necessary documentation for the feature / change is added [STAGE-3] missing 2 reviews for RFC PRs Remove this label when at least 2 core team members reviewed and approved the RFC implementation labels Oct 14, 2024
@QwikDev QwikDev locked and limited conversation to collaborators Oct 14, 2024
@gioboa gioboa converted this issue into discussion #114 Oct 14, 2024
@github-project-automation github-project-automation bot moved this from In Progress (STAGE 2) to Released as Stable (STAGE 5) in Qwik Evolution Oct 14, 2024
@shairez shairez removed this from Qwik Evolution Oct 15, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
[STAGE-2] incomplete implementation Remove this label when implementation is complete [STAGE-2] not fully covered by tests yet Remove this label when tests are verified to cover the implementation [STAGE-2] unresolved discussions left Remove this label when all critical discussions are resolved on the issue [STAGE-3] docs changes not added yet Remove this label when the necessary documentation for the feature / change is added [STAGE-3] missing 2 reviews for RFC PRs Remove this label when at least 2 core team members reviewed and approved the RFC implementation
Projects
None yet
Development

No branches or pull requests

2 participants