tailwind でobject-containを指定しても、縮小されずにはみだしてしまう場合。 <img>タグのサイズを固定していない可能性があります。 特にh-12やw-fullなどのクラス名を指定していない場合、その可能性が高いため、ここは来るべき場所です。おめでとう。 画像のサイズに影響されないようにする “サイズを固定する"というのは、<img>のサイズが画像の大きさに左右されないようにするということです。 特に何も設定していない場合、画像の大きさが 100x200px であれば、当然<img>のサイズも 100x200px になります。 これではobject-containを設定しても無意味です。 h-12 w-12のような固定サイズを指定しましょう。 親要素が固定サイズである場合、h-full w-fullなどとして間接的に固定サイズにすることもできます。 親が固定サイズでも安心できない <div className="h-12 w-12"> <img className="object-contain" src="https://example.com" /> </div> このような場合、確かに親要素が固定サイズなので、画像はそのサイズで表示されますが、 object-containは効かずに、はみだした画像の右下部分が省略されることになります。 それを解消するためには <div className="h-12 w-12"> <img className="h-full w-full object-contain" src="https://example.com" /> </div> のようにして、<img>本体を固定サイズにする必要があります。
Remix Cloudflareでenvのタイプが反映されない問題
Cloudflare 公式ドキュメントに従ってプロジェクトを作成したものとします。 TL; DR wrangler.tomlを書く。 # wrangler.toml [vars] API_TOKEN = "xxxxxxxxxxxxxxxxxx" RUN npm run typegen loaderで環境変数を使う。 export async function loader({ context }: LoaderFunctionArgs) { const env = context.cloudflare.env as Env; env.API_TOKEN; } wrangler.toml wrangler.tomlをプロジェクトルートに作成し、 [vars] API_TOKEN = "xxxxxxxxxxxxxxxxxx" のように記入する。 そしてnpm run typegenすると、 プロジェクトルートにworker-configuration.d.tsが作成される。 // Generated by Wrangler on Sun Apr 07 2024 04:59:25 GMT+0900 (Japan Standard Time) // by running `wrangler types` interface Env { API_TOKEN: "xxxxxxxxxxxxxxxxxx"; } これにより特に設定しなくても、loader内で環境変数が使えるようになるらしい。 Env export async function loader({ context }: LoaderFunctionArgs) { const apiToken = context....
RemixのuseLoaderData()がunknownになる問題
const loader = () => {}ではなくfunction loader(){}を使うべきかも。 unknown になった問題のコード export const loader: LoaderFunction = ({ context }) => { const hoge = "hello"; return json({ hoge }); }; export default function Index() { const {hoge} = useLoaderData<typeof loader>() ... } “Property ‘hoge’ does not exist on type ‘unknown’“などと怒られます。 正常に型が推論されたコード export function loader({ context }: LoaderFunctionArgs){ const hoge = "hello"; return json({ hoge }); }; 公式ドキュメントではfunctionを使っている https://remix.run/docs/en/main/route/loader 奇をてらったことはしないほうがよかった。
DockerでMongoDBのレプリカセットを動かす
bitnami/mongodb “mongodb docker"などと調べると、Docker 公式イメージが見つかると思います。 しかしこれでレプリカセットを構築しようとするとゴニョゴニョする必要があり、私は失敗しました。諦めました。 お勧めしません。 その試行錯誤の過程でエラーメッセージを検索しているときに見つけたのがbitnami/mongodbイメージです。 Bitnami は VMware 傘下の企業で、主にオープンソースソフトウェアを使いやすくパッケージングし、企業にサポートを提供する企業のようです。 その副産物として私たちはbitnami/mongodbのようなイメージを使えるというわけです。 公式ドキュメント compose.yaml # compose.yaml services: mongo: image: bitnami/mongodb:7.0 ports: - 27017:27017 volumes: - mongo:/bitnami/mongodb environment: - ALLOW_EMPTY_PASSWORD=yes - MONGODB_REPLICA_SET_MODE=primary - MONGODB_ADVERTISED_HOSTNAME=mongo restart: always volumes: mongo: これでdocker compose upすれば、mongodb が使えるようになります。 MONGODB_ADVERTISED_HOSTNAME この環境変数はサービス名と同じである必要があります。 この例の場合、mongoです。 この環境変数はなくても起動はできますが、起動後docker compose downなどでコンテナを削除してしまうと、 NotYetInitialized: Cannot use non-local read concern until replica set is finished initializing. のようなエラーがでて起動できなくなります。 推測ですが、docker composeで自動的に生成されるランダムなホスト名を、mongodb はノードのホスト名として保存してしまうからでしょう。 コンテナの再作成時にはランダムなホスト名は当然変わっているので、不整合が起きてしまうのでしょう。 docker composeの仕様として、そのランダムなホスト名だけでなく、サービス名（ここではmongo）もホスト名として使うことができます。 （例えばmongoが Web サーバーのコンテナならhttp://mongoで接続できる。） そのため、MONGODB_ADVERTISED_HOSTNAMEにサービス名を設定することで、エラーを起こさないで済むらしいです。...