NILTOを使ってみようとした

フェンリルのCMS、NILTOをちょっと試してみました。 結論として自分の用途にはアンマッチだったので止めたのですが、そこまでの感想をば。

NILTOとは

• 公式はこちら → NILTO (ニルト) - チームの理想を実現するヘッドレスCMS
• フェンリルが出している新しいCMSです。UIがかなり面白そうなので触ってみることにしました。

やろうとしたこと

• 自サイトの『制作物』のセクションをCMS化しようとしてました。なのでフィールドは下記のような感じでした
  • [必須]タイトル
  • [必須] 画像
  • [任意] ひとことコメント
  • [任意] URL（制作物サイトがある場合）
  • [任意] URL（Github）

結論

• 画像のスキーマから『src, alt』のみで、astroのImageタグで使うImageMetadataの生成が困難だったので止めました。
  • ImageMetadataは『src, width, height, format』が必須です。

気になるポイント

フィールド作成がドラッグアンドドロップ

• 横につなげたりとかできるのかな？と思ったらそうでもなさそう？今回はシンプルなフィールドしか作成しなかったので、あんまり恩恵を受けられませんでしたが、複雑なフィールドを作る場合は役に立つのかもしれません。

ライブラリはなさそう

• それはそれでシンプルで良い気もします

画像フィールドがwebpを受け付けてくれない

• たまによくありますよね

公開ボタンを押して『保存していない変更は削除されます』旨が出たことがあった

• 『まあ飛んでもいいや』ってデータなったのでそのままGOしたら、普通に保存されてました
• 自動保存なので、自動保存のタイミングと公開ボタン押したタイミングが悪かったのかも

感想

• ぼっち開発なので実験できませんでしたが、共同編集機能のあるCMSは中々珍しくて良いんじゃないかな、と思います
• ただ私はひとりな上にwidth/heightがどうしても必要だったので、自サイトへの導入は見送りにしました
• 共同編集が必要になったりしたらまた再チャレンジしようとおもいます！おわり

Cloudflare PagesのサイトをGithub Actionsを使って定期デプロイする

ある日、GtihubActionsからエラー通知が届いた。 私のサイトはRSSで自分のブログの記事を表示しているのだが、これをVercel→Cloudflareに移したことで落ちてた模様。修正する。

結論

• 完成品
• scheduleで"0 0 * * *"にすれば毎日0時0分にデプロイされるのでそれを利用
• Vercelとは異なり、GithubAcitons内でBuildコマンドを叩く必要がある

name: deploy website
on:
  workflow_dispatch:
    inputs:
      ref:
        description: deploy website
        default: "main"
        required: true
  schedule:
    - cron: "0 0 * * *"
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
      - name: Build
        run: npm install && npm run build
      - name: Publish to Cloudflare Pages
        uses: cloudflare/pages-action@1
        with:
          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          projectName: ${{ secrets.CLOUDFLARE_PROJECT_NAME }}
          directory: dist
          gitHubToken: ${{ secrets.GITHUB_TOKEN }}

やっていく

• 元々Vercelな部分をCloudflareに置き換えていく
• Use Direct Upload with continuous integration · Cloudflare Pages docs の Use GitHub Actionsの章に書き方は書いてあるのでこれをコピペ
  • コメントアウトされているBuildの部分は利用するのでコメントアウトを外す
• Settings > Secrets and variables > Actions > Repository Secretsに下記を設定していく
  • CLOUDFLARE_ACCOUNT_IDはCloudflareダッシュボードのURLのhttps://dash.cloudflare.com/***の***部分
  • CLOUDFLARE_API_TOKENはダッシュボード右上のユーザーマーク > My Profile > API Tokensから作成可能。
    • GitHub ActionsでビルドしてCloudflare Pagesにデプロイする の Cloudflareのトークンの作成が画像つきでわかりやすい
  • CLOUDFLARE_PROJECT_NAMEの部分は公式ではsecretsされてないのでsecretsにする必要はないかもしれないが、GithubActionsにべた書きしたくないのでsecrets化した

補足

• 今回はpushではなく定期実行なので、workflow_dispatchはをつけておくとWEB上からGithubActionsを発火させられてデバッグが楽。むしろつけないと定期実行タイミングにしか動かないのでデバッグが大変。

おわり

• VercelではBuildをいれてなかったので、最初Buildをすっとばして『distがないよ』というエラーが出て、あれ？distじゃなかったっけ？と何度か確認してしまった
• VercelもCloudflarePagesも定期再デプロイがﾎﾟﾁﾎﾟﾁでできるようになったらいいなあとは思うが、まああまり需要はないのだろうな
• Cloudflare Workersを使った方法もあったが、cron用に1つリポジトリを作った方が良さそうな雰囲気になったところで止めた。

cloudflareの*.pages.devを閉じる

astroで作っているサイトをcloudflareに移動した。ドメインはcloudflareで管理しているので、独自ドメイン設定も楽々完了。

設定画面を見ていて気付く。独自ドメインを設定したのに、Cloudflare Pagesのデフォルトである『*.pages.dev』が生きている。同じページが違うドメインにあるのは避けたいので閉じたいが、Settingsにそれっぽいボタンがない。

行き当たったのがDevelopersIOの下記の記事。

dev.classmethod.jp

私が求めてるのは上の記事の『2. バルクリダイレクト』の方法だが、普通にページ自体をデプロイしない方法があるはずだと思ってもう少し検索。公式を発見。

developers.cloudflare.com

『Disable access to *.pages.dev subdomain』の項の2つ目。

Redirect the *.pages.dev URL associated with your production Pages project to a custom domain. You can use the account-level Bulk Redirect feature to redirect your *.pages.dev URL to a custom domain.

公式でもBulk Redirectの手法が説明されていた。*.pages.devの公開自体をオフにする手段が何らかあると思ってたのだが、公式の説明がこうなら多分ないのだろう、ということでDevelopersIOの記事と同じ手段を実行した。

独自ドメインセットした時にBulk Redirect設定もサジェストしてくれてもよさそうに思うが、違うドメインに同じサイトがあることを特に気にしなくてもいいのだろうか。悩。

astro view transitionを導入する

最近色々なサイトを見て良い！と思ったのをメモるようにしている。
（メモ → manas-design-input ）

その中で『ページ遷移時のアニメーション、最近トレンドかも』と気づいた。

そういえばastroでそういう機能が実装された気がするので、やってみる。

公式Docは下記。

docs.astro.build

Docを見てあまりの記述の少なさに理解が追い付かなかったのだが、本当の本当に、『ページにビュートランジションを追加する』の項の2行を追加するだけで動く。私は前ページで利用しているlayout.astroのheadに追加した。

styleの位置変更を含んでるので差分が見づらいがこんな感じ 

 → view transitionを追加 · thetalemon/manasandbox@1e85ec1 · GitHub

Beforeはこんな感じだった。ヘッダ以外の部分がぱっと変わる感じを確認してほしい。

view transition導入前

Afterはこちら。おわかりいただけただろうか。
ヘッダ以外の部分がすこしふんわり変わるようになった。

view transition導入後

これがたったの2行追加だけで実現されるなんて良い時代だなあと思う。

このアニメはデフォルトの『fade』というアニメーションである（ドキュメントのview transitionのページの『組み込みディレクティブ』の項に記載されている）。slideも試してみたが、slideを採用するなら『トップに戻る』はスライド方向を逆にしたい気持ちが湧いてしまったので、今回はデフォルトのfadeをそのまま採用した。アニメーションのカスタマイズも簡素ではあるが可能なので、『さっと消えてふわっと出る』とかもできるかもしれない。

カスタマイズ無しのfadeでもちょっと凝ってる感を演出できるので、2行だけだが追加してみるといいかもしれない。

話は変わるが、はてなブログではmp4をアップロードできないので、AdobeのGIFに変換ツールを使った。2つ目のファイルを変換するにはリロードをするしか手段がなさそうなシンプルなつくりだが、変換が早い上に変換後サイズも選べてネットにアップロードするのに向いているので紹介しておく。

https://new.express.adobe.com/tools/convert-to-gif

スクロールに応じて画像がふわっと拡大するやつの実装メモ

スクロールに応じて、画像がふわっと拡大する | manasas ui sandbox

というのを実装してみた。GSAPは『知ってればすぐ実装できるが、情報にたどり着くまでに時間がかかる』ことが多いので、数こなしたら表現の幅が広がって楽しくなれそうだなあ、という印象。

実装は結構単純。Github

jsはこれだけ

  import { gsap } from "gsap";
  import { ScrollTrigger } from "gsap/ScrollTrigger";
  gsap.registerPlugin(ScrollTrigger);

  gsap.fromTo(
    ".js-animation-section",
    {
      width: "25vw",
      height: "25vw",
      borderRadius: "50% 50% 50% 50%",
    },
    {
      width: "100%",
      height: "100vh",
      borderRadius: "0%",
      scrollTrigger: {
        trigger: ".js-trigger",
        start: "center center",
        scrub: true,
        pin: true,
        // markers: true,
      },
    },
  );

htmlは実装に関わる部分はこのくらい

    <div class="main-visual js-trigger">
      <img
        class="main-image js-animation-section"
        src="https://source.unsplash.com/CakC6u4d95g/2400x2400"
      />
    </div>

スクロール量にあわせて変化するscrubというオプションを見つけるまで少しインターネットをさまよった。
あとは『大きさが変化する対象そのもの』ではなく、『変化後の大きさに合わせたWrapperコンポーネント』をtriggerに指定するのがコツだろうか。
startやscrubは『triggerに対しての位置/スクロール量』みたいな感じなので、triggerの大きさ変更はバグの元になりやすそう。

markersをデプロイ時にコメントアウトしたり消したりが嫌なので、後でastroでdev/buildを見分ける方法探してデプロイ時には勝手に消える/dev起動中は出る、みたいにしておきたい。
おわり。

はてなブログなどのRSSの日付を上手に表示する

※RSSによって返ってくるものが若干異なっていることがあるので確認の上で実装してください

弊ブログにてRSSで表示してるコンテンツに日付をだしたかったけどそのまま出したらグリニッジ標準時っぽいのが出たのでお直し。

コード

RssPosts.astro

利用しているもの / 利用するもの

• RSSはrss2jsonを利用してコンバートしています
  • RSS to JSON Converter online - rss2json.com
• 日付ライブラリはdate-fnsにしました
  • JSの日付ライブラリは、どれを使えばいいのかまとめ の記事を参考にして、スポンサーが多く開発継続性が高そうという理由で選定

実装時のコツ

• RSSで帰ってくる日付が2023-08-02 13:10:41になっている。こんな昼間に投稿してないはず。
  • 多分GMTだなあということで……下記。
  • .000+0000ではなく+0000でも動いたが、念のため
  • locale:ja もなくても動くが、念のため
  • hh:mm:ddにしてズレるなあと思うアホをした。24時間表記は大文字でHHなのでHH:mm:dd

import { format } from "date-fns";
import ja from "date-fns/locale/ja/index.js";

const formattedRecentData = recentData.map((item: RssItem) => ({
  ...item,
  pubDate: format(new Date(`${item.pubDate}.000+0000`), "yyyy-MM-dd HH:mm:dd", {
    locale: ja,
  }),
}));

つぶやき

• 世界的な規格なのでGMTを利用しているのだと推測するけど、それなら+0000までつけてほしかったな～

astro2.8から3.0にアプデした記録

• PR: astro3.0にアップデート by thetalemon · Pull Request #55 · thetalemon/manasandbox

何するの

astroの3.0が出た。パフォーマンスや最適化がより向上しているし、Astro View Transitionsという良い感じの遷移ができる機能もできたようで、色々試したいので自分のサイトも3.0にすることにした
Astro 3.0 | Astro

やったこと

参考: Upgrade to Astro v3 🚀 Astro Documentation

1. package.jsonから@astrojs/imageを削除する
2. npm install astro@latestを走らせる
3. Upgrade to Astro v3 🚀 Astro Documentation の Removed: @astrojs/imageと [Images 🚀 Astro Documentation] を参考に書き換え
   • astro.config.mjsを修正
   • @astrojs/imageのラッパーコンポーネントがImage.astroというファイル名だったので、ImageWrap.astroにRename（astro:assetsのImageと名前が衝突してエラーがでるため）
   • ImageWrap.astroで利用していたPicutureタグをImageに変更
   • Imageタグにはaspect-ratioがないので削除し、heightを追加
4. ｵﾜﾘ🎉！！

つぶやき

• Upgrade Guideが結構長いのでちょっと警戒してたんですが、そんなに面倒な作業じゃなくてよかったです
• 1番面倒だったのはaspect-ratioからheightを算出する作業でした。
  • Wrapperコンポーネントあったおかげでpropsをちょっと書き換えるだけで済んだのでまあWrapperにしといてよかったのかな
• ちょうど1ページサイトから複数ページサイトになったところなので、Astro View Transitionsを近いうちに素振りしようと思います
• この作業のついでに利用してなかったtailwindを削除しました。astro導入した時はこれを機に覚えようと思ったのかもですが、astroみたいにCSSとHTMLが1ファイルにあると特にtailwindにしたい気持ちが湧かないですね。こうしてtailwindチャレンジが見送られ続けていく。

おわり。