はじめに 少し前にNuxt3 + Tailwind CSS + Storybook ver7の環境を作ったことがありました。 storybookの導入時NuxtのAutoImportの対応が思いの外時間がかかったので備忘録として環境構築の流れを書いてみました。 環境
--- name: 'component' description: 'Generate standard React component.' root: 'src' output: '**/*' ignore: [] questions: parts: 'enter parts name(Ex: atoms, organisms ..)' module: 'enter directory name(Ex: Button, Drawer ..)' name: 'enter component name' --- # `{{ inputs.parts | lower }}/{{ inputs.module | pascal }}/{{ inputs.name | pascal }}.tsx` ```tsx import { VFC } from "react"; type Props = {
2023/05/05 追記 v13.4.0 をもって App Router は安定版になりました! https://nextjs.org/blog/next-13-4 公式ドキュメントもベータ→正式版にマージされました。 内容が充実してきている様子ので、そちらを確認してください。 https://nextjs.org/docs 加えて、公式ドキュメントの改善で分かったポイントもいくつか修正しています。 Next.js v13 から App Router 機能 (app ディレクトリ) が新しく追加されました。 (v13.3.0 現在はベータ版です。 v13.4.0 をもって安定版になりました!) ファイルベースの Layout 機能 処理の一部を Server Component に移しバンドルサイズを削減できる 例: remark を利用した Markdown のパース が有名なところだ
Reactアプリケーションのアーキテクチャの一例として公開されているGitHubリポジトリ「bulletproof-react」が大変勉強になるので、私自身の見解を交えつつシェアします。 ※2022年11月追記 記事リリースから1年ほど経過して、新しく出てきた情報や考え方を盛り込んだ続編記事を書いていただいているので、こちらも併せて読んでいただければと想います(@t_keshiさんありがとうございます!)。 ディレクトリ構造が勉強になる まずはプロジェクトごとにバラつきがちなディレクトリ構造について。 ソースコードはsrc以下に入れる bulletproof-reactでは、Reactに関するソースコードはsrcディレクトリ以下に格納されています。逆に言えば、ルートディレクトリにcomponentsやutilsといったディレクトリはありません。 たとえばCreate Next Appで作成
Reactは「自由にカスタマイズできる」かつ「日進月歩」というのがメリットの反面、 ネット上には新旧の情報が入り乱れていてベストプラクティスが見つけづらいというのがデメリットになっているのではないでしょうか。 その最たる例がHooks、Reduxをどういった構成にするかだと思います。 巷ではHooksはReduxの機能を補えるから、Reduxはもはや必要ないといった意見もでているようです。 本当に不必要なのでしょうか? 初学者の方にもなるべくわかりやすいようにReduxの概要・非同期処理について根本的なところから改めて振り返って整理したのち、Hooks(useReducer・useContext)との設計概念・機能比較を行いました。 「もうそんなこと知ってるよ」という方は、Redux概要の箇所は飛ばしていただけるとありがたいです。 【Redux概要】 MVC・Flux・Reduxアーキテク
今現在、React、Reduxを使っているプロジェクトは日本国内においてもたくさんあるかなって思います。ディレクトリファイル構成などの設計に関しても、各社・各人様座あり、答えもないので、悩ましいものでもあります。 ただ、チーム開発では、ここをしっかりルールづけしておかないと、個人任せの無秩序なソースコードが散乱し、途中で参画したメンバーはキャッチアップに時間を要します。また、既存のコンポーネントがあるのにその存在に気づかず、新たに作成したりし、ファイルサイズも大きくなり、パフォーマンスにも影響する可能性があります。さらに、Reduxなどの状態管理ツールなどが導入されていると、さらに複雑になります。 現在、僕が配属されたプロジェクトでも、ディレクトリ構成のルールはある程度あるものの、その判断基準も個々で曖昧で、ドキュメントとして残っておらず、テストコードもなく、結構複雑な構成をしております。
Dockerコンテナの概要と利点 コンテナでぐぐると、「仮想サーバー技術がうんたらこんたら〜」と出てくるが、それは忘れていいというのから衝撃を受けた。笑 それから入る情報が多かったので、(正直意味不だった) 一言で、コンテナとは「互いに影響しない隔離された実行環境を提供する技術」 もっとシンプルに考えていい。難しく考えようとしていた →システムの実行環境を隔離した空間のこと 例)システムAとシステムBは、コンテナがあれば例えば、共通のフレームワークをアップデートしたりしても互い影響はない コンテナの特徴は、「独立」していること(ここで言う独立とは単体で完結していること) 1台のサーバーにシステムが複数あっても競合しないこと コンテナを実現するソフトの代表が「Docker」 DockerはLinux上で動作するソフトで、Linuxに「Docker Engine」をインストールするとDocke
一般的に「名盤」とされる作品でも、「良さが分かりづらい作品」があるのではないか それを確かめるため、ツイッターで「良さがよく分からない」、もしくは「良さが分かるまで時間がかかった」名盤について投票を呼びかけ、数多くの方にご参加頂きました (参加者:305名、エントリー数:520作品) 一般的に名盤とされてるアルバムで、「良さがよく分からない」、または「分かるまでに時間を費やした」作品を一人当たり1枚から最大5枚まで、このツイートに返信か私にDMで頂けますでしょうか。今週末までを目処に集計し、発表したいと思います。 — 𝑷𝒆𝒕𝒆𝒓 (@zippu21) May 16, 2022 この記事では、前回の記事(100位-31位)に引き続き、投票が7票以上あった30位の作品から順に発表していきます。 なお、前編の記事をまだ読まれていない方は、是非そちらを先に読まれることをお勧めします。
2023年現在、Reactでは多種多様なスタイリング手法が用意されています。 代表どころで言うとCSS ModulesやTailwind、CSS-in-JSなどが有名です。筆者の個人的な好みでは、これらの選択肢の中でもCSS-in-JSを用いたスタイルが特に好きですが、CSS-in-JSライブラリ群の中にはランタイムでスタイリング処理がなされる為にパフォーマンス上の問題を抱えているとの指摘を受けているものもあり、最近は人気が下火になっているように感じています。 そこで本記事では、CSS-in-JSが生まれた背景から遡り、各ライブラリの内部実装を確認しながらそれぞれのライブラリの仕組み・メリット・問題点を明らかにし、CSS-in-JSのパラダイムシフトを追ってみたいと思います。 CSS-in-JSの登場 CSS-in-JSという言葉が最初に公の場で登場したのは、2014年にFacebookの
本記事のモチベーション 約8年前、Gitを使い始めたときに以下の記事を公開したところ、想像以上の反応をいただきました。 当時はSubversionからGitに移行し、試行錯誤をしている中だったこともあり、多くの反応をいただけたことはモチベーションのひとつでした。 ただ、時が経ち、当然かもしれませんが現在は当時と違う書き方をしており、思想として変わっていない部分はあるものの、今でもときどきLikeをいただく中で、アップデートを全くしないのは誠実じゃないなと感じていました。 というわけで、現在のフォーマットも数年後には変わっている可能性が高いですが、その時々のスナップショットを公開することにも何らか意味があるかなと思い、「今の僕はこうコミットメッセージを書いているよ」というのをまとめました。 Gitを使う環境 開発フローやホスティングサービスごとのUIのdiffによって、最適なフォーマットは変
こんにちは!フリーランスエンジニアの雄貴です! Reactを用いたコンポーネント設計の方針は様々ありますが、 私が普段用いている手法を紹介しようと思います! Reactのコンポーネント従来のコンポーネントだと、以下のコードのように関数の中でstate(状態)やfunction(ロジック)を定義し、それを「return」直下のview部分に渡してレンダリングしています。 import React from 'react' /** * InputForm * @returns */ export const InputForm: React.FC = () => { // state (状態) const [value, setValue] = React.useState('') // function (ロジック) const handleChange = (event: React.Ch
Chapters: Why?, Thinking in React, Imperative vs. Declarative, Pure Functions What you’ll learn Optimized for aha! We’re obsessed with helping you reach your aha! moments. Our text sections help you master the “why” behind React concepts and include fun, interactive visuals you can play with. Give it a try.
この記事はProcessing Advent Calendar 2020の19日目の記事です。 ■ はじめに 12月になってこの度、五年付き合っている彼女と同棲を始めまして、平日の晩御飯は主に僕が担当しているんですが、如何せんもうすぐ27歳なのに人生でここまでほとんど料理をしてこなかったので日々悪戦苦闘しています。今一番欲しいのは家庭科の教科書です。 そんな生活の中でふと思うのが「どこまでやって自分の料理と言えるか?」と言う問題です。例えばカレーライス。市販のレトルトカレーを湯煎してご飯にかけても立派なカレーライスだし、スパイスからこだわって絶妙なバランスで配合して作ったカレーもまた立派なカレーライスです。 結局は心の持ちようなのですが、ことp5.jsを使って作品を作る身となったとき、そこにはすでに様々な便利な関数が用意されています。市販のレトルトカレーがすでに他の人が作ったソースコードの
みなさんはCSSのメディアクエリについて本当の意味で理解して使用しているでしょうか。ブラウザがデフォルトの状態なら正常に動くと思います。しかし、ブラウザで拡大率を変更したりするなどブラウザの設定によってはメディアクエリの解釈が大きく変わってきます。また、メディアクエリに使える単位のpxやem、remによっても変わってくるため、適切な単位を用いる必要があります。 検証に用いるCSS 以下の6パターンを使って検証します。すべてのバージョンを検証するのは大変なので、過去3年間のバージョンまで遡りました。 /* 600px以上 */ @media (min-width: 600px) { ... } @media (min-width: 37.5em) { ... } @media (min-width: 37.5rem) { ... } /* 600px未満 */ @media not all
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く