Numnumberry
Explore posts from servers"Cannot call server function outside of a request" in onRequest middlware hook
I just got this, found out it was from calling a server function (a function marked with 'use server') inside of middleware
I guess you cannot call server functions in middleware
this looks like it is your case seeing that an error occured in "onRequest"
3 replies
Returning Errors and not throwing
hmm I didnt even know submission.clear was a thing
I see in the no-JS case it really is not meaningful (the page you got is the result of the submission)
but in the JS case the submissions seem to stack on themselves and are popped with clear()
8 replies
Returning Errors and not throwing
thanks for this example, in looking at this I have discovered the key is that the behavior under the hood of SS is different depending on JS being enabled
if enabled, it sends a fetch request, and in the response it has the information needed to dynamically update the UI in the spot of the read submission (in 1 request)
if disabled, it sends a request, and in the response is instructed to refetch the same page which will have the UI updated in the spot of the read submission (it takes 2 requests)
that covers the useSubmission and render the updated page on the server, but now there is returning the Error vs throwing. I see this decision as ultimately deciding to use submission.result or submission.error. The only reason I can see to return the Error is you will get the type information in the result, where as if you throw, the error would still just be any
8 replies
Returning Errors and not throwing
I understand PE, and I understand the stated desire to handle Errors with normal control flow
I do not understand how this gets incorporated, in code, with SolidStart's primitives (action and useSubmission)
My understanding is that a server-action is called from a form that is on the client. Now we are in the server handling the action, and now we run into an Error. Even if I choose to return this error and not throw it, how is it that I can "declaratively render the updated page on the server"? My understanding is that an action can just revalidate or redirect or reload, it doesnt arbitrarily change something in the DOM on the page? If I were to revalidate, redirect, or reload, then what does it matter if I return the Error? Isnt the important part the fact that I either revalidated, redirected, or reloaded?
8 replies
The combination of API routes and data loading functions
yeah, something like that is what I have been looking into (and also an error handler/catcher)
the nice thing about API Routes, even if you double call, is that 1 request equates to 1 function which is 1 log
but in the case of cache server functions and SSR and revalidations, the former could be the case, but ALSO you can have 1 request equate to multiple functions for 1 log
52 replies
The combination of API routes and data loading functions
I also find that, on initial load, multiple cache server functions can be called during SSR (so there is only 1 event, that is the event of loading the initial page, so if something were to be logged it could only be that "I loaded the initial page")
where as if you revalidate a cache key, you will call one or more cache server functions to get new data (which now are there own events to be logged)
so this inconsistency is what I have been thinking about
I have been thinking maybe only log mutations/actions and not "GET"s for new data
52 replies
The combination of API routes and data loading functions
I have been thinking about it for hours and testing things. I have been looking at cache server functions and how they behave with ErrorBoundary. I have been looking at what sort of wrapper I could create for server functions
one issue is I do not know how to log a server function
if I have an action that mutates a resource, I want to log it, but the name of the function is a cryptic hash and number, not useful for identifying what was called
52 replies
The combination of API routes and data loading functions
I actually thought this was already possible at first. I thought I remembered seeing that you could use an internal fetch function to skip making another request
but upon looking at it, it seems it just makes it to where you dont have to "worry about the origin of the URL".. whatever that means, I guess talking about CORS
52 replies
The combination of API routes and data loading functions
lol, yeah this is already miles ahead
I had also thought that if this is deployed on an edge runtime like CF workers, double fetching probably does not have a huge cost since the api endpoint will be right there in the network
52 replies