You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a note to myself, the official docs provide all but I wanted a compact overview:
A .ts in any folder creates a standalone endpoint
A same named .svelte file ("page endpoint") in that folder turns the standalone endpoint into a shadow endpoint; now, the page endpoint automagically gets its props from latter without any fetch; this shadow endpoint can still be fetched independently from its page endpoint; be aware that the returned body type loses flexibility, now!
fetch:
GET:
the path and a { headers: { accept: 'application/json' } },
or the path + /__data.json
or you let the endpoint's filename end on .json.ts and then, fetch it with path + .json; be aware that here, the endpoint loses its shadow endpoint functionality but gets more flexibility over the returned body type!
POST: just the path and a respective POST signature (method, headers, etc.)
Even with the potential change of the routing discussed in #5037 non-page-endpoints shouldn't be affected (I presume).
My take regarding GET requests: a and b are recommended, c not because of the lacking shadow endpoint feature and the need to add a dedicated api folder structure for standalone endpoints which adds mental overhead when navigating the code base, I don't know a good use case why I would need more flexibility with the returned body type (to be discussed). To have more terse code, I'd default to option b.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
This is a note to myself, the official docs provide all but I wanted a compact overview:
.ts
in any folder creates a standalone endpoint.svelte
file ("page endpoint") in that folder turns the standalone endpoint into a shadow endpoint; now, the page endpoint automagically gets its props from latter without any fetch; this shadow endpoint can still be fetched independently from its page endpoint; be aware that the returnedbody
type loses flexibility, now!fetch
:GET
:{ headers: { accept: 'application/json' } }
,/__data.json
.json.ts
and then, fetch it with path +.json
; be aware that here, the endpoint loses its shadow endpoint functionality but gets more flexibility over the returnedbody
type!POST
: just the path and a respectivePOST
signature (method, headers, etc.)Even with the potential change of the routing discussed in #5037 non-page-endpoints shouldn't be affected (I presume).
My take regarding
GET
requests: a and b are recommended, c not because of the lacking shadow endpoint feature and the need to add a dedicatedapi
folder structure for standalone endpoints which adds mental overhead when navigating the code base, I don't know a good use case why I would need more flexibility with the returnedbody
type (to be discussed). To have more terse code, I'd default to option b.Beta Was this translation helpful? Give feedback.
All reactions