-
Notifications
You must be signed in to change notification settings - Fork 13
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
Next 13 support #55
Comments
Since the server component doesn't use data fetching functions(getServerSideProps, ...) anymore, but started using the custom functions instead, that allows you to return data directly without any serialization/deserialization. So once you create a server component in the app directory, this plugin gets no longer needed. Hope it was helpful. |
Thanks for the quick response, much appreciated. Please let me lay out my specific use case just so I can be sure I understand. In the app folder, I have a server component that is fetching some data, however I don't want to render that data in the component directly, rather I want to pass it as a prop to a client component which will use it as it's initial data but also enable ongoing fetching itself directly. Reason I'm doing this is because the component has to have function callbacks and Next complains when I include those in a server component and tells me they need to be in a client component. For that initial data that I'm passing, it contains a Date object. Next still gives me a warning for it: Warning: Only plain objects can be passed to Client Components from Server Components. Date objects are not supported. I can get around this using superjson, so I figured there was still use for this package in next13. Is there another way I should be approaching this instead? |
Your detailed explanation helped me a lot to understand. Thanks! After much thought, I found a solution to pass the serialized props to the client components. But only one big problem is still left: Of course, It is possible to apply SuperJSON to the all components in the app directory, but I don't think it will be efficient. If you think this way is okay, I'll think about working on this feature soon. |
Thanks for getting back to me. Good to know there is still a use case and I'm not missing something obvious! With regard to the problem you call out. Why is the app folder in next13 inherently different to the pages or components directory in earlier versions of next. How does the plugin currently know which props to (de)serialise for components in the pages/components directory? Assuming there is some fundamental blocking reason, then a couple thoughts on your suggestion. I'm not against a plugin config somewhere that lists relevant components but thought of the following alternatives:
|
Let's get this straight. It has been clear to seperate the component which wants to get serialized props from data fetching function which wants to return serialized props by their identifier and the export statement. So the plugin was able to wrap those function and page component into SuperJSON functions if a page module contains a data fetching function like However, introducing server components made this approach impossible. For example: export default function ServerComponent() {
const date = new Date()
return (
<>
{/* don't need serialization */}
<AnotherServerComponent date={date} />
{/* needs serialization */}
<ClientComponent date={date} />
</>
)
} As a plugin, It's impossible to know which component needs props serialization in this case. So the plugin has no choice but to transform all the components. Here's the expected output: import { Wrapper } from "next-superjson-plugin/tools"
export default function ServerComponent() {
const date = new Date()
return (
<>
<Wrapper _component={AnotherServerComponent} date={date} />
<Wrapper _component={ClientComponent} date={date} />
</>
)
} Anyway, first idea is great! but we won't have to list specific props. "use superjson" This statement would be used as a flag to detect whether a file is a target of (de)serialization or not with |
Sounds good! So taking the "expected output" you noted, it would then look as follows assuming we have entered "use superjson" on the relevant client component? import { Wrapper } from "next-superjson-plugin/tools"
export default function ServerComponent() {
const date = new Date()
return (
<>
{/* don't need serialization as server component */}
<AnotherServerComponent date={date} />
{/* needs serialization, plugin has detected this by noting the "use superjson" comment on the client component */}
<Wrapper _component={ClientComponent} date={date} />
</>
)
} |
To be exact, If |
Hi, I brought another idea. export default function ServerComponent() {
const date = new Date()
return (
<>
<AnotherServerComponent date={date} />
{ /* Use "data-superjson" attribute for the component where you want to use SuperJSON */ }
<ClientComponent date={date} data-superjson />
</>
)
} The data attributes are reserved in the native DOM attributes. Finally, the codes above can be transformed by the plugin like this: export default function ServerComponent() {
const date = new Date()
return (
<>
<AnotherServerComponent date={date} />
{ /* Use "data-superjson" attribute for the component where you want to use SuperJSON */ }
<Wrapper _component={ClientComponent} date={date} />
</>
)
} Using |
Sounds good to me, seems like a cleaner solution. I look forward to trying it out. |
@Xexr Plugin v0.5.0 with this feature is released! The basic usage("data-superjson" directive) is not changed but you can follow the updated README.md by any chance. Please try it, and I'll waiting for your review 😄 |
Great to see that its up. Unfortunately, I'm getting an error. I've set it up as per the updated readme via experimental.swcPlugins. I'm on next @ 13.0.5, superjson @ 1.11.0, next-superjson-plugin @ 0.5.0, and I'm using pnpm @ 7.17.1 Here's a copy of the error trace I get: @ursa/web:dev: thread '' panicked at 'called |
Reference: #58 Fixed in v0.5.2. Try it! |
All working correctly now. Thanks :) |
I could not get it working with a basic setup, I followed the Readme and I get this error
|
@kevinsimper Have you ever cleaned your build cache? (.next) It looks fine to me. |
@orionmiz Yes it was, had not crossed my mind that it was the build cache! Thank you! |
From what I can tell, this doesn't currently work with Next 13.
I suspect this is because it is presently only active on the pages directory.
Any chance of this being updated to support the Next 13 app directory as well?
The text was updated successfully, but these errors were encountered: