Atila
Does createAsync cause double renders on the server i.e an extra render after data becomes available
no, that second render shouldn't happen.
Is the function you're passing to
createAsync wrapped in a query() ?
Query will cache/deduplicate the request, otherwise I can see the request firing more than once, specially in Dev5 replies
Throw vs return in router’s action
yeah, I think for the sake of consistency it could be better to have
throw in the code snippets - perhaps add a note about how return/throw can work would be best.
The Data Loading entries are overdue some work for sure23 replies
Throw vs return in router’s action
+1 on throw. I also think it's more idiomatic and it correlates well on how
<Suspense> operates too
Under the hood, Suspense throws a promise to allow it to propagate towards the outer scope - essentially that's what we want with a redirect, so things click better inside my head when I'm reasoning about the control flow.
As you said, a redirect() isn't a directly related to the outcome of the action(), it's more of an "app state" thing. We send the user somewhere else and that interrupts the flow they were at, theoretically, it's "above the paygrade" of a simple form submission... so throwing makes more sense to me too23 replies
Throw vs return in router’s action
the longer answer is that
throw in JS will stop the function execution, interrupting the program and propagating this effect updwards. While return will gracefully end and offer back the value.
So, as you can imagine, when it comes to a redirect()it makes little difference, but you'd be right in expecting the throw to be a bit more predictable and immediate in that case.23 replies
RPC "use server" and CSRF Attacks
I think you're right. Those are my assumptions as well, Chris.
That being said, I still implement a CSRF protection middleware in my apps. SolidStart middleware makes it easier than Next.js does because of how Middlewares are triggered.
For example, I often pass an array of security middlewares to my
onRequest triggers. One for CSRF and another one for the remaining security headers...
I'm about to publish a video where I implement this CSRF protection (checking referrer and origin, not the token) to add Auth in my app - just finishing last editing quirks and I'll update this comment with the link ASAP - I'd love your feedback.5 replies
Saving data to a store that has a getter?
maybe that's a long shot, but looking at your screenshot, I'd stopped unwrapping/cloning.
something like..
produce will receive a function where the current store is the param. Then, you can mutate it as you see fit and it will efficiently merge to the current store.
It's perfect for these granular mutations/appends.
281 replies
Get array of matched nested routes
interesting. So that means not all segments in our URL have a route component attached to them 🤔
yeah, I think that’s the best solution possible! I’ll get it to the docs team so we can document this method on the official docs!! 🏆🏆
8 replies
Solidjs vs Astro with Solidjs
You can create fully functional apps with Solid, either extending with SolidStart - or Astro with Solid.
In a more practical way, this is what you get with each:
:astro: + :solid:
Astro is mainly a static generated framework. Even the SSR mode will output a static HTML towards your user browser. You can add islands of interactivity (via Solid or other framework) and hydrate them on the client-side. This will enhance the funcionality with JS. But still, the islands will need sticthing if you want them to share state and data.
Accepting this tradeoff, this is a very powerful combo. Many people like it, including the Astro team themselves. :solid: You can have a traditional Single Page Application that will render and hydrate everything on the client-side. This is an acceptable approach if you can take that first-load perf hit - many dashboards and highly interactive apps go the SPA route still. You can circumvent lots of the perf issues with a service-worker or some other caching strategies. It takes work, but it can be done. :start: SolidStart takes Solid core and plugs in other tooling (namely Solid-Router and a server runtime) to give the isomorphic experience. With this you can handle your data and requests in a Server Action or Function. This will give you total control over your data and once it reaches the client-side, it will behave as a SPA. While SolidStart will give you a larger bundle footprint than Astro, it will offer more control over your data, it will allow you to make your apps more interactive, and communication between components will be seamless. My take If you know your app will be highly interactive, like a game, go with SolidStart from the beginning. Using Astro will be pointless if every component you get is interactive - the initial gains from a "0 javascript" bundle-size will quickly melt away as you start adding interactivity everywhere and even bringing external dependencies to handle data between separated islands.
Accepting this tradeoff, this is a very powerful combo. Many people like it, including the Astro team themselves. :solid: You can have a traditional Single Page Application that will render and hydrate everything on the client-side. This is an acceptable approach if you can take that first-load perf hit - many dashboards and highly interactive apps go the SPA route still. You can circumvent lots of the perf issues with a service-worker or some other caching strategies. It takes work, but it can be done. :start: SolidStart takes Solid core and plugs in other tooling (namely Solid-Router and a server runtime) to give the isomorphic experience. With this you can handle your data and requests in a Server Action or Function. This will give you total control over your data and once it reaches the client-side, it will behave as a SPA. While SolidStart will give you a larger bundle footprint than Astro, it will offer more control over your data, it will allow you to make your apps more interactive, and communication between components will be seamless. My take If you know your app will be highly interactive, like a game, go with SolidStart from the beginning. Using Astro will be pointless if every component you get is interactive - the initial gains from a "0 javascript" bundle-size will quickly melt away as you start adding interactivity everywhere and even bringing external dependencies to handle data between separated islands.
16 replies
Passing data from `event.locals` to Frontend
Particularly, I like Nuxt's approach, where the developer can define route-specific middleware and then do the protection.
https://nuxt.com/docs/getting-started/routing#route-middleware
I think there's a chance we get there, but I'm not sure how much work is required under the hood to going through middleware on every navigation.
10 replies
Passing data from `event.locals` to Frontend
if you try to protect a route via a middleware, it won't work for soft-navigation (SPA)
Does getRequestEvent only give the first event in a potential series?that's a second case where, at the moment, the won't match assets - so it doesn't fire a million times, no need to filter routes out. But it intercepts every flight between client/server - so if you fire a redirect or something, it will fire multiple times.
10 replies