Remixでleafletを使用する開発で、SSRフレームワーク定番(参考1, 参考2)の"window is not defined"がサーバ側の端末で表示される現象に遭遇しました。
要するに、ブラウザでのみ動かしたいコードがサーバ側のSSRで動いてしまっているわけです。
Next.jsだとdynamicで囲って対処していましたが、Remixでどうやってやるのか調べました。
Remix Viteで一部をクライアントサイドのみにするでは、ReactのlazyとSuspenseを組み合わせて行けるとのことでしたが、私が試した限りではうまくいきませんでした(やり方が悪かっただけかもしれません)。
結局、remix-utilsのClientOnlyを使って解決しました。
動作確認したバージョン
フロントエンド界隈は開発が活発なので、この記事の内容もあっという間に陳腐化するかもしれませんが、備忘録として残しておきます。
DBに入った2行の、特定のカラムの値をスワップする方法。ちょっと日本語で検索しても良いのが出てこなかったけど、英語で良いのが出てきた(下記はMySQL限定)：
Mysql: Swap data for different rows
UPDATE tbl a INNER JOIN tbl b ON a.id <> b.id
SET a.col = b.col
WHERE a.id IN (2, 3)
AND b.id IN (2, 3)
上記は、テーブルtblのカラムcolの中身を、id=2,3のレコードでスワップする。
これ最初に思いついた人、頭良い。そもそもupdate文でこういうjoinが書けるのを正確に知らなかった。SQL奥深し。updateで使える構文を一度しっかり調べたほうが良さそう。
2023/5/23追記：PostgreSQLでは上記の方法では動かない。次のような感じでいける(参考資料：PostgreSQL, Swap data of certain column in two rows)
UPDATE tbl a set col = b.col
FROM tbl b
WHERE a.id IN (2, 3)
AND b.id IN (2, 3)
AND a.id <> b.id
ただ、実際に動作させてみると、colにUNIQUE制約がかかっている とエラーになってしまう。どうやらPostgreSQLの場合、内部的には同時に交換というよりは逐次で更新されているっぽい。さらにちなみに、上記のset colのところをset a.colとすると構文エラーになってしまうので注意。
GitHub Codespaces便利ですよね。無料枠だと一ヶ月あたり120時間使用できますが、本業とは別にちょっと開発するのであれば、これくらいの時間があれば十分に感じます。
CodespacesでNext.js/NextAuth.jsでOAuthを使用したWebアプリケーションを作成して、Codespacesで自動的に割り当てられるHTTPSのURLをコールバックに指定できるので、ログインが必要なアプリも開発できます。
ただ、色々やっているうちに、502 Bad Gatewayエラーが出るようになってしまいました。ちょっと検索してみたら、Port Forwarding returns 502 Bad Gatewayに従って、一旦Codespacesのインスタンスを削除して、再度作成したら解消しました… と思ったら、それでも502が続くようになってしまいました… 2023/3/29現在、解決方法は見つかっていません。
RDBはprismaを使用してアクセスしているのですが、検索条件として同一テーブルの異なるカラム同士間の条件で行を抽出したいと思った時、その方法がわかりませんでした。こちらも調べてみたら、Compare columns in the same tableを見つけました。generator clientの中にpreviewFeatures = [“fieldReference”]を追加してprisma generateすると、prisma.table.fields.columnといた感じでカラムを条件部で参照できるようになりました(tableがテーブルに対応するスキーマ名で、columnが参照したいカラム名)。ドキュメントではversion 4.3.0から使えるようになっていると書かれていますが、手元では4.11では動かなかったように思います。4.12に上げたらfieldsが出てきました。
ORM (Object-relational mapping)については賛否両論あると思います。 私もこの件について思うところが最近あったので、ポエムを投下します。
「ORM SQL」といった感じで検索してみると
のような記事が見つかりました。不要とほぼ断言しているものから、積極的にORMを使う派の方まで。
私もこれまではどちらかといえば、「別にSQLで書けるのに、敢えてORMを使う必要性は無いのでは」と思っていました。 ただ、最近開発をしている際に、初めてORMを使いたくなる場面に遭遇しました。
これは、端的に言えば、上の3番目の回答に挙げられているORMの機能
に大きな有用性を感じたためです。
これまでの開発では、コードの開発前にRDBのスキーマがほとんど決まっていたので、 レコードの更新や取得を行うSQLは(手間でも)一回だけ書けば良い場面ばかりでした。
でも、今回経験した開発では、要件が完全に決まっていない段階で開発をスタートしたのもあり、 開発がある程度進んだ段階で要件が精緻化されたところ、(ER図でいうところの)エンティティのテーブルとの対応が大幅に変わる可能性が生じました。 具体的には、現実との整合性を保つために
といった状況です。
さて、これまで真心込めたSQLで結合してマッピングしていたエンティティですが、 いざRDBスキーマが変更になると、これらも書き直さなければいけません。当然、検索(SELECT)だけでなく、 更新(UPDATE)もです。多:多でエンティティの属性を取得するためにforループを回している記述も修正する必要があります。
困った… というわけでORMの出番です。実現方法は静的コード生成だったり、実行時のリフレクションだったりしますが、 基本的にORMではエンティティ間の1:多などの関係をメタデータとして記述することで、 関数一撃で関連するエンティティを取得できるようになるわけです。
もちろん、ORMでも、RDBスキーマが変わって際の変更がゼロとはいきませんが、複数のSQLやfor文を正しく書き直す労力を考えれば、 メタデータの更新と関数呼び出しの変更程度で対応できるのであれば、相当有用であると思いました。
まとめると、スキーマが完全に決まっており、将来的にも変更されることは(ほぼ)無い、というのであれば、 SQLのみで記述してもそれほど問題にはならないかも知れません。 一方で、要件に伴ってRDBスキーマが開発中にも変更される可能性があるなら、 ORMを使用するのは保険として大変役立つのではないか、と思いました。
SQLでwhere検索を行うときに、条件によって、さらに検索条件を切り替えたいということが生じることがあります。
例えば、テーブルにカラムC1, C2, C3が存在するとして、気持ちとして以下のように書きたくなる場合です。
select something from tbl where if p(C1) then q(C2) else r(C3)
カラムC1に依存する述語p(C1)がTRUEの時はq(C2)で検索し、FALSEの場合はr(C3)で検索する、というものです。
SQL: If clause within WHERE clause に答えがでていますが、この場合は、
select something from tbl where (p(C1) and q(C2)) or (not p(C1) and r(C3))
が答えになります。if p(C1) then q(C2) else r(C3)がTRUEになる場合を考えると、p(C1)がTRUEであれば、q(C2)がTRUEである必要があり、 p(C1)がFALSEであればr(C3)がTRUEでないといけません。これを論理式で書いたのが上になります。
あるいは、if p(C1) then q(C2) else r(C3)はp(C1)→q(C2)かつ￢p(C1)→r(C3)と書き直すこともできるので、 A→B = ￢A ⋁ Bを使って、
(not p(C1) or q(C2)) and (p(C1) or r(C3))
と書いても同じ結果になります。
今回の例では説明を具体的するためにカラムC1, C2, C3と書きましたが、大切なのは述語p, q, rですので、 カラムとは無関係に条件を書くことができます。
2023/1/6追記： SQLのwhere句でifで条件文を複数切り替えは不可 case式で代替可能に説明されていますが、whereの中でcaseを使うこともできるので、
select something from tbl where case when p(C1) then q(C2) else r(C3) end
と書くこともできますね。
© 2019 東京に住むプログラマ (webmaster@living-in.tokyo). Based on MH Magazine lite.