Comments (10)
I think I'm encountering this bug in a different form.
Following the Protected Routes example and I cannot get the redirect to work even when my definition is:
export const getUser = cache(async () => {
console.log("getUser");
throw redirect("/");
}, "user");
from solid-start.
I was able to reproduce the issue using the following route src/routes/redirect.tsx
:
import { type RouteDefinition } from '@solidjs/router'
import { cache, createAsync, redirect } from '@solidjs/router'
import { getRequestEvent } from 'solid-js/web'
const exampleAction = cache(async () => {
'use server'
const location = new URL(getRequestEvent()!.request.url)
return redirect(`${location.origin}/target`)
}, 'exampleAction')
export const route = {
load() {
// redirect will start working if uncommented:
// void exampleAction()
},
} satisfies RouteDefinition
export default function Component() {
const data = createAsync(() => exampleAction())
return <h1>Result: {data()}</h1>
}
With the route above, when you navigate to /redirect
, it does not redirect you to /target
.
Unless you trigger an action with redirect inside route.load
or use a relative redirect which starts with /
instead of a full URL with the origin, i.e., redirect('/target')
works, but redirect('http://localhost:3000/target')
does not.
from solid-start.
@mmmoli Redirects are ignored inside load
functions and that section of the docs is incorrect accordingly, are you calling getUser
inside a route/layout as well? solidjs/solid-docs-next#769
@frenzzy This seems like a separate issue, the redirect should happen on the client whether exampleAction
is called in load
or not. solidjs/solid-router#438
from solid-start.
@apatrida looks like the X-Error
header which tells the server function handler to throw is only set for error's, I'll make a PR for it to be included with responses too.
from solid-start.
@Brendonovich thanks for the follow-up. I was, yes.
Question: will your PR fix error handling for load functions too, or is that by design?
I'll keep an eye on the docs to see what the behaviour is supposed to be.
from solid-start.
@mmmoli That redirect should work, is your setup something like this? https://stackblitz.com/edit/github-fk8exj-zbxuey?file=src%2Froutes%2Findex.tsx,src%2Froutes%2Fredirect.tsx,src%2Fapp.tsx
Question: will your PR fix error handling for load functions too, or is that by design?
wym by error handling? i don't think load functions are meant to handle errors at all
from solid-start.
@mmmoli That redirect should work, is your setup something like this? https://stackblitz.com/edit/github-fk8exj-zbxuey?file=src%2Froutes%2Findex.tsx,src%2Froutes%2Fredirect.tsx,src%2Fapp.tsx
Question: will your PR fix error handling for load functions too, or is that by design?
wym by error handling? i don't think load functions are meant to handle errors at all
Yes? Forked with more specifics: https://stackblitz.com/edit/github-fk8exj-waqwjq?file=src%2Fcomponents%2Fuser.tsx
I'm brand-new to solidjs so might have a different mental model.
Features:
profile
is a protected page<User />
attempts to render information on the profile page- '/nope' to redirect to
- route load function (Does this make any sense at all? Is it even being called?)
from solid-start.
@mmmoli The stackblitz you provided seems to be working as expected, and the behaviour isn't affected by the presence of load
.
- Clicking the button starts the navigation to
/profile
getUser
runs insidecreateAsync
, which suspends the navigation- Whether or not
getUser
is first ran inload
or not doesn't affect this
- Whether or not
- At the end of
getUser
the redirect is thrown, which navigates to/nope
If you do think there's a bug there I'd suggest opening a new issue with a dedicated reproduction, I'm not sure it's related to this bug.
from solid-start.
Ok yeah this was an oversight that I probably introduced towards the end of the beta phase. We definitely should be throwing Responses that were thrown. It is interesting if we should always be throwing them. The types suggest we should but maybe the types are wrong. I see this going one of 2 ways.
-
We keep server functions "transparent". You return a Response, you get a Response. To be fair this will include some special processing of the Response by server functions. We will probably have special Response types from the Router helpers which aren't exactly the standard one.. but like type the body as a generic. We also probably need to do some special handling of the custom body processing. I think with a little work we can make this work although right now we do use the existence of
customBody
to make decisions, but I think we could find other ways. The important part is that thecache
andaction
functions would be the one stripping the Responses out of the types. Which I think is probably more accurate. -
We always throw Responses when they are sent across the network. We used to and for some reason I changed it to a return at some point. There is no issue here really other than the caller of the server function that returns a Response maybe not expecting it. Since we don't expose the custom Response stuff we don't really really need to worry about it too much and the developer basically can ignore it. In some ways this is easier for everyone but its less accurate. It is also less extensible.. like if for some reason you wanted to send a Response you couldn't perhaps.
In any case since this takes work my gut is to just merge the current PR for now so that the immediate issue is resolved. And then probably make a choice and do a minor release of the router and/or Start. But would appreciate thoughts/feedback on the direction. I think option 1 is better long term if I can figure out because it makes this into more of a standard protocol rather than a special cased hack. But sometimes hacks work really nicely.
from solid-start.
imo option 1 is better, seems more predictable and typesafe. 'You return a Response, you get a Response' sounds more inline with the isomorphic nature of server functions.
We will probably have special Response types from the Router helpers which aren't exactly the standard one.. but like type the body as a generic
The important part is that the cache and action functions would be the one stripping the Responses out of the types
This would definitely be doable, I made a small symbol-based implementation the other day but it could just as easily be done with a custom Response class.
from solid-start.
Related Issues (20)
- [Bug?]: Cannot get response returned by a server function via a GET request HOT 1
- [Bug?]:TypeError: Cannot read properties of null (reading 'FormContext')
- [Bug?]: [vite] Pre-transform error: xxx.tsx: Property value expected type of boolean but got undefined HOT 1
- [Bug?]: Server action chunks are not generated in production build when using `experimental.islands` HOT 5
- [Feature?]: Websocket for SolidStart/SolidJS, instead of fetch HOT 2
- Issue with File Updates on Dev Server HOT 1
- [Feature?]: Tailwind template should come with automatic theme switching support "out-of-the-box"
- [Bug?]: Hydration Mismatch for passed JSX elements HOT 5
- [Bug?]: `compressPublicAssets` nitro config does not work HOT 4
- [Bug?]: Wrong server function called due to incorrect handling of file hash collisions for server func sources
- [Bug?]: Landing page is broken on small screen size
- [Bug?]: how to prerender *404 page? HOT 2
- [Feature?]: Add an option to disable lazy loading in `<FileRoutes />` HOT 3
- [Bug?]: "Zero-config" Netlify provider does not load a Netlify preset automatically HOT 4
- [Bug?]: TypeError: Response body object should not be disturbed or locked HOT 3
- [Bug?]: pnpm create solid@latest doesn't work HOT 1
- [Bug?]: Using layouts with route groups at root level causes hydration errors HOT 3
- [Bug?]: Unexpected Link Element Generation for Stylesheet Imports in Production Environment HOT 1
- API routes have to be inline exported function declarations
- [Feature?]: Add ability to add/modify head classes, lang and lang dir HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from solid-start.