2024-01 svelte めも

Rows for which the expression returns true will be visible. Any rows for which the expression returns false or null will not be visible to the user (in a SELECT), and will not be available for modification (in an UPDATE or DELETE).

Such rows are silently suppressed - no error is reported.

WITH CHECK

This expression will be used in INSERT and UPDATE queries against the table if row-level security is enabled.

Only rows for which the expression evaluates to true will be allowed. An error will be thrown if the expression evaluates to false or null for any of the records inserted or any of the records that result from the update.

Note that this expression is evaluated against the proposed new contents of the row, not the original contents.

32px

CREATE POLICY "Enable update for users based on email" ON "public"."posts"
AS PERMISSIVE FOR UPDATE
TO public
USING (auth.uid() = user_id)
WITH CHECK (auth.uid() = user_id)

gpt くん

The USING clause (auth.uid() = user_id) specifies that users can only update rows where the user_id column matches their auth.uid(). In other words, users can only see and thus update their own posts.

The WITH CHECK clause (auth.uid() = user_id) ensures that upon updating a row, the modified data still satisfies the condition that user_id equals the user's auth.uid(). This is important to ensure that users cannot update a post to change its ownership to another user.

32px

つまり WITH CHECK は更新されたデータについての restriction で、 USING は更新する人の制限なのね

32px

つまり WITH CHECK は更新されたデータについての restriction で、 USING は更新する人の制限なのね

32px

supabase auth を使うときは users テーブルはもうある

A user signs up. Supabase creates a new user in the auth.users table.

32px

how to check if user is signed in

32px

server or client with supabase

32px

starter kit

32px

request.formData() のなかみ

FormData {
  [Symbol(state)]: [
    { name: 'email', value: 'xxx@example.com' },
    { name: 'password', value: 'xxxxxxx' }
  ]
}

32px

sample code here: https://kit.svelte.dev/docs/form-actions#anatomy-of-an-action

32px

ちゅうい: const { email, password } = await request.formData() はできない

32px

another good sample code

pointers

use String(request.formData.get("email")) to force a type; c.f. Number()
use fail to return an error result

32px

めも: 401 "idk who you are", 403 is "i know who you are but im not going to let you in"

(permit.io のきじ)

32px

https://kit.svelte.dev/docs/types#generated-types めも

32px

auth

32px

The new ssr package exports two functions for creating a Supabase client. The createBrowserClient function is used in the client, and the createServerClient function is used in the server.

browser と server でそれぞれ client がある

auth-helpers はつかわない

+layout.svelte: 共通のレイアウト
+layout.ts: load data for the layout like page.ts loads data for the page
+layout.server.ts: load data for the layout on server

+page.svelte: frontend for the page
+page.ts: expose the load function
page.server.ts: load data for the page on the server-side; examples are loading data from DB, using private keys

32px

event.locals の typing は app.d.ts をいじる必要あり

32px

hooks.server.ts の type error

I've fixed it by forcing the type CookieSerializeOptions & { path: string }, but CookieSerializeOptions comes from the cookie package so you'll need to install it first pnpm add --save-dev cookie.
then change options to options as CookieSerializeOptions & { path: string }

32px

こっちかも

this is happening because since SvelteKit 2, path is now a required property when setting cookies. this is how to fix it: { ...options, path: '/' }

こっちだわ

32px

そもそも load ってなんだっけ

Before a +page.svelte component (and its containing +layout.svelte components) can be rendered, we often need to get some data. This is done by defining load functions.

render するために必要なデータをとってくるのが load

32px

hooks.server.ts のいめーじ

This function runs every time the SvelteKit server receives a request — whether that happens while the app is running, or during prerendering — and determines the response. It receives an event object representing the request and a function called resolve, which renders the route and generates a Response. This allows you to modify response headers or bodies, or bypass SvelteKit entirely (for implementing routes programmatically, for example).

32px

error vs fail について

This throws an exception that SvelteKit catches, causing it to set the response status code to 404 and render an +error.svelte component, where $page.error is the object provided as the second argument to error(...).

https://kit.svelte.dev/docs/errors

a wise man also said..

error is for serious issues that cause the +error.svelte to be displayed.
fail is for form action results that are invalid, which can return relevant data to show, e.g. validation errors for form fields.

(今は wise man も sexist になるのか??)

とりま error を投げると +error.svelte が投げられるので、ログインエラーで error は使わんほうがいいのかも

32px

https://fontsource.org/fonts/outfit このフォントありかも

32px

posting data

As well as pages, you can define routes with a +server.js file (sometimes referred to as an 'API route' or an 'endpoint'), which gives you full control over the response.

In general, form actions are a better way to submit data from the browser to the server.

api はやせなくないけど、form action のほうがいいらしい