-
-
Notifications
You must be signed in to change notification settings - Fork 34
Description
Describe the bug
server$ server call is not being serialized on the sever to match the network boundary which can result in runtime errors if passing un-serializable objects like Date/Map/Set
on the server the function in called directly
/**
* currently in the context of the server render you can basically think this as const fn = () => new Date()
*/
const $$server_module0 = fetch$.createHandler(async function $$serverHandler0() {
return new Date();
}, "/_m/43dde1d673/getNow", undefined);
fetch$.registerHandler("/_m/43dde1d673/getNow", $$server_module0);
and on the client its a fetch to the endpoint
/**
* again you can think of this as const fn = () => fetch('/_m/0dbe216f23/clientDate')
*/
const $$server_module0 = fetch$.createFetcher('/_m/7d3e2194d0/clientDate', void 0),
This also effects solid-start solidjs/solid-start#792. Bling currently does try to parse client and server the same but only for Reponse objects
another thing to note is when this is fixed server$ return type will not reflect what is really returned.. for simple values like number object and string it is correct.. but when returning something that is not serializable like Date Map or Set. the return types don't match what is being parsed on the wire. ex Date -> string, Map -> {}.
TRPC had this same issue trpc/trpc#3261 i prototypes fixing the return types for solid-start by copying what TRPC did but this only handles using JSON.parse & stringify. with bling supporting custom serializer & deserializer types should refelect this somehow
Your Example Website or App
Steps to Reproduce the Bug or Issue
- build bling dev
- Run astro-solid example
- go to
/
- server console says response is date while browser console reports string
Expected behavior
The return type should reflect the network boundary and serialize the response
Screenshots or Videos
No response
Platform
- OS: [Linux]
- Browser: [Chrome, Safari, Firefox]
- Version: [commit 98a28d8]
Additional context
No response