てっくれこーど

Tag: React

  • アトミックデザインをやめて、ディレクト構造を見直す

    atma株式会社では、週2回、フロントエンド・バックエンドに分けて勉強会をしています。 今回は、フロントエンド勉強会で発表した、「アトミックデザインからの脱却」をこちらでも公開します。 そもそもアトミックデザインって何 アトミックデザインとは、Brad Frostさんが提唱した、フロントエンドのコンポーネント設計についてのデザインシステムです。 Brad Frostさんがアトミックデザインについて提唱している記事 大抵のアトミックデザインの解説では以下の画像が使われています。Brad Frostさんの記事で紹介のため使われている画像なので、多くの方に使われているようですね。 出典: https://bradfrost.com/blog/post/atomic-web-design/ アトミックデザインについて要約すると、 デザインシステムを考えに考え、考えぬいたら、化学に行き着いた。UIも地球上に存在するすべての物質のように、原子、分子、有機体、、のようにできてるのでは？？ というような感じです。 実際の現場では、コンポーネントを5つのディレクトリに分けることで、採用されていることが多いと思います。 Brad Frostさんも言っている通り、templates, pagesは、化学的ではないですが便宜上便利なので入れているらしいです。 なんでアトミックデザイン使うの？ これは、調べても僕の力では見つけられなかったです。 https://design.dena.com/design/atomic-design-を分かったつもりになる 有名な記事はいくつかあるのですが、これといった決定打はないようです。 「アトミックデザイン最近（2018~）はやってる」「アトミックデザイン便利そう」 みたいな感じかなと思っています。 アトミックデザイン本当に便利？？ ここからが、今日話したいことになります。 結論を述べると僕は、アトミックデザインが非常に分かりづらいものだと思っています。 前職で大きなプロジェクトで1回、社内では2回利用しています。 何が分かりづらい？？ 1. そもそもatomicとかmoleculesとかパッと見よくわからない シンプルに馴染みのない単語ですし、何を指しているのか分かりづらいです。moleculesとorganismsとかほぼ違いが分からないです。 また、moleculesとorganismsの範囲が案件によってかなり違います。 デザインにおける共通言語としては、atomicsしか定着してないと勝手に思ってます。 2. そもそも、何でもかんでも共通化できるものではない アトミックデザインを採用すると、原則として、必ず、atomic・molecules・organismsのいずれかのディレクトリにコンポーネントを作らいないと行けないです。 例えば、お問い合わせフォームのコンポーネントを考えると、フィールドはatomicとわかります。 では、フィールドの結合は？submit処理はどこに？エラー処理はどこに？ 採用するフレームワークによっては、完全に分離ができないこともあります。 実装によっては、ほとんどがpagesに入ってしまい、pagesが肥大化してしまう可能性もあります。 3. pagesの肥大化を恐れて、コンテキスト込のorganismsが増える 上記とも被りますが、特定のページでしか使わないけど、共通化も面倒なとき、一旦organismsに orgnisms/contact/contactForm.tsx (.vue) のようになったりしがちです。 まとめると アトミックデザインという、デザインシステムを維持するのは、かなり難しいのと、そのコストが高いと思っています。 もちろん、しっかりと定義がされたアトミックデザインは、強いと思いますし素晴らしいと思うのですが、僕の感覚では、上記3点の理由であまりそうならないと思っています。 じゃあ、どんな構造でコンポーネントを設計していけばいいの？ いくつかのタイミングで、紹介していますが、僕は以下の記事の考え方がアトミックデザインからの脱却のための近道だと思っています。 Atomic Designをやめてディレクトリ構造を見直した話｜食べログ フロントエンドエンジニアブログ 食べログの解決策は？…

  • さくらのレンタルサーバー上にWordPressとNextJsでJamstackな技術ブログを構築

    はじめまして、ねづたけるです。 技術ブログ最初の投稿は、「このブログをどのように構築したのか」にします。 ブログ構築は何度も経験をしているのですが、WordPressについては5.0のグーテンベルク（ブロックエディタ）が出たくらいから止まっています笑 当時WPをいじっていた頃から、技術力も上がり、それっぽい構成でもブログ構築できそうだなと思ったので、それっぽい構成で皆さんのブログ構築の参考になればと思います。 前提 それっぽい構成といいつつ、インフラについては、普通にレンタルサーバを想定しています。 僕が、すでにさくらのレンタルサーバを契約しているのでそれにあいのりしたいからです。ちなみに、さくらのレンタルサーバは神がかってるレンタルサーバで、スタンダードプランが毎月500円くらいで、無料でDBも何個も立ち上げられます。個人開発や練習としては本当に神なので、皆さんどうぞ使ってみてください。 さくらのレンタルサーバだけで記事かけちゃうくらいすごいんです。 ただ、さくらのレンタルサーバにもデメリットはあります。 それは、サーバーサイドの言語として使用できる言語に限りがあるということです。 さくらのレンタルサーバでなんの設定もなく利用できるのは、PHPのみです。したがって、どれだけそれっぽい構成にしたくても、サーバーサイドはPHPという縛りがあります。原則PHPしか動かせないので、NextjsのSSRとかも実装できないです。 そこで、WordPressをGraphQLのAPIとして運用し、NextJsでSSGを利用してJamstackにブログ構築をします。 Jamstack構成なら、サーバーサイドの言語関係なく配信できちゃいます。 1. さくらのレンタルサーバにWPをホスティングしておく まずはじめに、さくらのレンタルサーバでDBを作成し、データベース名、ユーザー名、パスワードを取得してメモしておきましょう。 次に、WPのソースコードを展開します。 さくらのレンタルサーバにSSHで接続して、以下のコマンドを実行していきます。 hogehogeには、今回作成するブログの英語名等を入れておいてください。 さくらのレンタルサーバ側で設定したURLにアクセスして、WPの初回セットアップを完了させてください。 この際に、先程メモしたDB接続情報が必要になります。 ダッシュボードへの接続が完了したら、便利なので以下のプラグインを入れておいてください。 Reactとの情報連携時に利用します。 !!注意!! 環境によるかもしれませんが、WP GraphQLが以下の条件でエラーになります。 問題なければ、日本語のままでも良いですが、エラーでうまくWP GraphQLが動作しない場合は、表示言語を英語に変更してみてください。 2. ローカルでNextJsの環境を構築する これで、WPのAPI環境が構築できました。次に、NextJSの環境をローカルに構築して、フロント側の実装を進めていきます。 Dockerを構築（スキップ可） どんな環境でも開発できるように、まず、Docker環境を構築します。 必ずしも必須ではないので、必要な方のみ構築してください。 Dockerを導入する場合、プロジェクトの構成を以下のようにします。 docker-compose.yaml、Dockerfileは以下のようにしてください。 上記の２ファイルを作成して、upすれば、nodeが構築済みのコンテナが立ち上がります。 次に、立ち上げたコンテナ内で以下のコマンドを実行してプロジェクトを作成します。 WORKDIRで、/var/www/appを指定しているため、コンテナのコンソールに入ると、初期で/var/www/appにいると思います。 /var/www/appの直下にプロジェクトを展開したいため、上記のようにディレクトリを移動しています。 3. Github Actionsを設定する ローカルでnextjsの構築が完了したので、最も重要な、GithubActionsの設定を行います。