Closed italodeandra closed 2 years ago
This plugin works by wrapping getStaticProps
and getServerSideProps
. These aren‘t supported for _app.tsx
. You can, however, deserialize the SuperJSON-ified props manually in your _app.tsx
. Refer to this line for how to make that work:
Yeah, I did exactly that as a workaround.
Would it make sense to have an util on the lib that does that (that's also going to be used on the line you quoted)? Because I feel that I won't be the only one needing that.
If you don't agree you may close this issue.
Yes, that‘s a good idea! Would you be interested in opening a PR for that?
Yes, I'll do it after work!
@Skn0tt How costly is the SuperJSON.deserialize
function? I already created the code but I still didn't commit because I just noticed that I'm deserializing the props twice. Once manually on _app.tsx
itself (my function) and another wrapped by the plugin.
Then it got me thinking: perhaps it would be better if I didn't use this plugin at all? What's your opinion on that?
SuperJSON.deserialize
cost is linear to the number of non-JSON-native values and their depth on the object tree.
You should be able to save the second deserialize
call by deserializing in _app.tsx
and then passing down the already-deserialized props to Component
. Makes me wonder if that could be a good abstraction for a v2 of this plugin 🤔
What I plan to contribute doesn't break existing API, so maybe just a minor version would be good.
You should be able to save the second deserialize call by deserializing in _app.tsx and then passing down the already-deserialized props to Component.
Yeah, that worked. I'll create the PR.
I did some research and I see that there was a change that made the file
_app.tsx
be skipped. Why is that? I need the deserialized data exactly on_app.tsx
since I need to add the data to a provider.Is there a solution for that?