ReactやAngular、VueなどでComponentのスタイリング時に抑えておきたいこと

なんとなく自分の中で言語化しておきたかったので、整理も兼ねて記載しておきます🙆🏻‍♂️

普段仕事で様々なAngular、またはReactののコンポーネントを作ったりメンバーから出るPRを読む中で、コンポーネントのスタイルはどういうふうに当てるのが破綻しにくいんだろうと考えていました🤔
Angularは良くも悪くも一つのComponentが結構おっきくなりがちだったのでそこまで意識しなかったですが、Reactは何なら分割しないと気持ち悪いとすら思えるくらいにコンポーネントを分割しやすいです。
コンポーネントを分割することは各ファイルごとに把握すべき事柄が減るので基本的にはいいことだと思っていますが、スタイリングについては意識しないと破綻してしまうなーと思っています。
(もちろん、スタイリングに限らず意識しないと破滅するんだけど、今回はスタイルについての話です)

スタイルの破綻っていうのは、ロジックの破綻と同じで、どこで何があたっているか把握できない、みたいなことだと思っています。
あるいは、利用側からどうやってそのコンポーネントを使えばいいのかわからなかったり、必要以上にスタイリング用のたくさんのpropsを貰う必要が出てくる、みたいなのもそうかなと思っています。

そこでいくつか守ったほうが良さそうなパターンがあるので、それを列挙していきます💪

■ 外に対してのmarginは持たない

これはMust💪
例えば以下のようなことはNG ​

const StyledButton = styled.button`
  margin: 16px auto;
`;

export const Button: React:FC = () => <Button>ボタン</Button>

なぜNGか

このButtonは自分がどこで使われているか知らないはずなのに外側の隙間を定義するmarginを持ってしまっています。
子はそんなことは考えなくって良くて、どこに配置するかは使う側(親コンポーネント)が考えれば良いとおもいます🙆🏻‍♂️
逆にこういうstyleを持ってしまうと、「違うmargin渡したいから、marginもpropsに追加しなきゃ、、、」みたいになりがちです。 同様の理由で、position: absoluteなんかも自身が持たないようにしましょう(親のコンテキストによって位置が決まるので)

🤔 paddingはどうですか?

paddingは持っても大丈夫です。paddingはコンポーネント自身の内部の隙間です。
例えるなら、paddingというのは脂肪です。marginはソーシャルディスタンスです。自身のことはそのコンポーネントが知っていて大丈夫なので、paddingは問題ありません🙆🏻‍♂️

🙆🏻‍♂️

const Parent: React:FC = () => (
  <div>
    <Button css={{ marginBottom: '16px' }} />
    <Button />
  </div>
);

みたいに使う側で指定してあげましょう。

■ widthは特別な事情がない限り指定しない

widthをpropsとして渡せるコンポーネントを見る機会が結構あります👀
ですが、widthはそもそも、親のコンテキストで決まるので、多くの場合widthを指定する必要はない気がしています👀
というより、display: blockであれば、そもそもwidthは100%になっているはずです。
widthが100%の状態であれば、使う親の方でdivで囲むなりして幅を指定してやることが可能です。

ただ、そのコンポーネント特有のwidth、またはmax-widthがある場合もあります。
例えばボタンや、バッジなどです。こういうものに関しては、width、またはmax-widthを持つことになると思います。 そもそも、そういうコンポーネントは自身のサイズが決められているので、あまりwidthを変更したいと言う機会がない気がしますが、もし必要になる場合はパターンがあると思うので、本当にpropsでwidthpx単位とかで渡すのではなく、サイズを表す定数(たとえばlargeやあるいは使われるコンテキストの名前など)を定義してそれを渡すほうが良さそうです。 もし定義するのが辛くなるくらい大量に定数が発生する場合はもしかしたらデザイナーと相談したほうがいいかもしれません。

■ レイアウトに関するスタイル、またはタグはできる限り全体を見通せるように指定する

いいたいことはこれです(毎度非常に良い記事ばかりで勉強になっています🙇‍♂️)。
https://blog.uhy.ooo/entry/2020-10-15/react-paired-css/

例えば、flexdisplay: flexの子要素として初めて意味を成すスタイルです。
なので

const StyledWrapper = styled.div`
  display: flex;
  & > .hoge {
     flex: 〇〇;
  }
`;

のようにまとめて書くと非常に全体を把握しやすいです。
もちろん様々あると思うので必ずこの方法​で記述しろとは言いませんが、少なくとも1ファイル内で追えるようにすべきです👀

また、これはhtmlタグについても同様です。
thtd、またはlidtddなどは親要素がいないと意味をなさない要素です(逆もまたしかりです)。 それらは必ず1ファイル内で追えるようにし、単体でexportしないようにしましょう🙆🏻‍♂️

■ 【要検討】 displayはinline系にしない

これは微妙に賛否が分かれると思うのですが、基本的にコンポーネント自体のスタイルとしてはdisplay: blockまたはflex, tableなど、インラインでないほうがいいのかなと思っています👀
理由はinlineinline-block等のインライン要素は記述コンテンツ => 文章とその中に含まれるマークアップとして定義されているものが持つスタイルで、使用されるコンテキストとしてもinlineであることを期待してしまっているからです。

https://developer.mozilla.org/ja/docs/Web/HTML/Block-level_elements#Block-level_vs._inline

コンポーネントを考えたときに、コンポーネントはなにかのパーツではありますが、それ自身で完結しているものでもあります🤔
そうだとするならば、コンポーネントdisplayがインラインであるのはコンポーネントとして不自然な状態だと言えるのではないかなーと思っています👀

また、使う側からすると、各コンポーネントがblock、またはそれに準じたdisplayになっていることで、どのコンポーネントもある程度似たように扱うことができるようになります。
flex等の指定が可能になったことで、コンポーネントがinlineでないと実現できないレイアウトもほとんどなくなったと言う認識です。

ただ、これについてはwebcomponentsのCustom elementsのissueでデフォルトのスタイルをdisplay: blockにすべきだという議論があったものの、この意見を補強する資料が見つかりませんでした🙄

https://github.com/WICG/webcomponents/issues/224

なので、僕にとってはこのほうがやりやすいが、そこまで気にしなくていいことなのかもしれません👀


以上です🌮
はい

​ ​

ReactでrequestAnimationFrameを使う

ふと自分で遊んでる時に、ReactでCanvas触るのどうするんだろなーという気持ちになったので調べた。

ここを読めばすべてのことが書いてある。
https://css-tricks.com/using-requestanimationframe-with-react-hooks/

DEMO

https://codesandbox.io/s/mystifying-framework-hdk7k

具体的に

基本的にrequestAnimationFrameを使う場合は、再帰的に呼び出されるような処理のことが多い。有限なのであればいいが、例えばcanvasで背景アニメーションを描画するなどして永遠に描画させ続けるような場合もある。 そういう場合、例えばもらうpropsが変わって再描画されるたびに、追加であたらしいrequestAnimationFrameのループが始まるようだと困る。 そういう場合はcancelAnimationFrameでcancelしてから、新しいrequestAnimationFrameのループを始めたい👀

useRefを使えばよろしい

useRefは何もDOMにアクセスするためだけにあるわけではなくって、再描画されても同じ値を保持し続けたいような場合に使える。
なので、戦略的には、useRefにrequestAnimationFrameを格納し続けておいて、任意のタイミングでそれをcancelAnimationFrameするということになる。

const Canvas: React.FC = () => {
  const animationRef = useRef(null);
  const animate = () => {
    animationRef.current = requestAnimationFrame(animate)
  };
  
  // なんかのタイミングで
  cancelAnimationFrame(animationRef.current);
}

まぁ、いわゆるなんかのタイミングっていうのは、このコンポーネントが破棄されたとき、となるわけなので、

const Canvas: React.FC = () => {
  const animationRef = useRef(null);
  const animate = () => {
    animationRef.current = requestAnimationFrame(animate)
  };
  useEffect(() => {
    animationRef.current = requestAnimationFrame(animate);
    return () => cancelAnimationFrame(animationRef.current);
  }, [])
}

のようにuseEffectを使ってやると、コンポーネントが破棄されたときにcancelAnimationFrameが呼ばれるようになる。

そういうわけでrequestAnimationFrameを使う処理をCustorm Hooksに切り出してやる

const useAnimationFrame = () => {
  const animationRef = useRef(null);
  const animate = () => {
    animationRef.current = requestAnimationFrame(animate)
  };
  useEffect(() => {
    animationRef.current = requestAnimationFrame(animate);
    return () => cancelAnimationFrame(animationRef.current);
  }, [])
};

const Canvas: React.FC = () => {
  useAnimationFrame()
}

これで、useAnimtionFrameをつかって何かしらをすることができるようになったが、実際のrequestAnimtaionFrameで回したい処理をどの様に書くかかという点がある🤔

requestAnimtionFrameで回す処理をもらう

どうすべきかなーとか思っていたけど、useAnimationFrameはAnimationFrameについて関心を持っているべきで、それ以外のことは知っておくべきではない。
それ以外のことについては使う側が勝手にやってくれよな✊🏻

というわけで、requestAnimationFrameで関数を受け取るように変更する🚀  

const useAnimationFrame = (callback: () => void) => {
  const requestRef = useRef<ReturnType<typeof requestAnimationFrame>>();
  
  // callback関数に変更があった場合のみanimateを再生成する
  const animate = useCallback(() => {
    callback();
    requestRef.current = requestAnimationFrame(animate);
  }, [callback]);
  
  // callback関数に変更があった場合は一度破棄して再度呼び出す
  useEffect(() => {
    requestRef.current = requestAnimationFrame(animate);
    return () => {
      if (requestRef.current) {
        return cancelAnimationFrame(requestRef.current);
      }
    };
  }, [animate]);
};

const Canvas: React.FC = () => {
  useAnimationFrame(() => {
    // なんかやりたい処理
  })
}

まとめ

  • useRefはコンポーネントの再描画に関わらず、とっておきたい値を入れるのに向いている
    • elementの参照以外にも色々活用法があるぞ!

これでReactでCanvas遊びがやりやすくましたね✊🏻

Good Canvas & React Lifeを🎍

switchかなんかで条件によって異なる値を返す関数の型の書き方

この間やっててハマったので、意外とハマる人多いのでは?ということでメモ

前提⚠️

  • typescript v4.0.2

■ 前提となる変数たち

type valueOf<T> = T[keyof T];

const KEY = {
  foo: 'foo',
  bar: 'bar'
} as const;
type Key = valueOf<typeof KEY>;

const VALUE = {
  foo: 'foo',
  bar: 'bar'
} as const;
type Value = valueOf<typeof VALUE>;

こんな場合の話🙆🏻♂️‍

const getFooOrBar = (key: Key) => {
  switch (key) {
    case KEY.foo:
      return VALUE.foo;
    case KEY.bar:
      return VALUE.bar;
  }
};

const foo = getFooOrBar(KEY.foo);

このとき、foofooリテラル型になっていてほしい、というかなるのでは?と思ったが、実際は以下のようになる

const foo: "foo" | "bar"

僕がハマったとき、実装がもう少し複雑だったので問題がなにかに気づくのに時間がかかったし、端的に言って鬼ハマリして時間をドバドバとほとんど湧いては捨てられる温泉のように無駄にした♨️

どうやんの?😕

ここに書いてあります🦸♂️‍ https://stackoverflow.com/questions/58673034/type-inference-from-switch-case-return-with-typescript

公式はこいつです🙋 https://www.typescriptlang.org/docs/handbook/functions.html#overloads

なるほど、たしかにopenapiとかで自動生成されたコードで見たことあるわ、こいつ🤔
というわけで、functionのoverloadsを使います

function getFooOrBar(key: Extract<Key, 'foo'>): Extract<Value, 'foo'>;
function getFooOrBar(key: Extract<Key, 'bar'>): Extract<Value, 'bar'>;
function getFooOrBar(key: Key) {
  switch (key) {
    case KEY.foo:
      return VALUE.foo;
    case KEY.bar:
      return VALUE.bar;
  }
}

const foo = getFooOrBar(KEY.foo); // const foo: "foo"

■ curry化されていて、返す関数の型をやるとき

はキモいですがこんな感じ🐛

const createFooOrBarGetter = () => {
  function getFooOrBar(key: Extract<Key, 'foo'>): Extract<Value, 'foo'>;
  function getFooOrBar(key: Extract<Key, 'bar'>): Extract<Value, 'bar'>;
  function getFooOrBar(key: Key) {
    switch (key) {
      case KEY.foo:
        return VALUE.foo;
      case KEY.bar:
        return VALUE.bar;
    }
  }
  return getFooOrBar;
};

■ この関数をexportしたいとき

は全部exportしてね🚛

export function getFooOrBar(key: Extract<Key, 'foo'>): Extract<Value, 'foo'>;
export function getFooOrBar(key: Extract<Key, 'bar'>): Extract<Value, 'bar'>;
export function getFooOrBar(key: Key) {
  switch (key) {
    case KEY.foo:
      return VALUE.foo;
    case KEY.bar:
      return VALUE.bar;
  }
}

良かったですね🙆🏻♂️‍

TypeScriptで自作している便利型Tips

たまになんかこういうの取り出したいんだけど、なんかないかなーみたいなことになっていくつか作ってみたりしているので、せっかくなので記載しておく🙆🏻♂️ ‍ 命名が微妙なので、命名をどうにかしたいというのがある

valueOf<T>

keyOfの反対。
与えられたオブジェクトのvalueのユニオン型を作る

type valueOf<T> = T[keyof T];
const HOGE = {
  hoge: 'test',
  fuga: 'test2'
} as const;

type Hoge = valueOf<typeOf HOGE> // 'test' | 'test2'

mappedConst<T extends string>

与えられた文字列のkeyとvalueを持つオブジェクト

type mappedConst<T extends string>  ={
  [key in T]: key;
};
type HogeOrFuga = 'hoge' | 'fuga';

type HogeFuga = mappedConst<HogeOrFuga>;
/**
{
  hoge: 'hoge',
  fuga: 'fuga'
}
*/

OptionalExceptFor<T, K extends keyof T>

Tの型からKを除いたものをOptionalにする

export type OptionalExceptFor<T, K extends keyof T> = Pick<T, K> &
  Partial<Omit<T, K>>;
type A = {
  foo: string;
  bar: string;
  baz: string;
};

type B = OptionalExceptFor<A, 'foo' | 'bar'>;

const b: B = {
  foo: 'test',
  bar: 'test'
};

RequiredExceptFor<T, K extends keyof T>

Tの型からKを除いたものをRequiredにする

export type RequiredExceptFor<T, K extends keyof T> = Pick<T, K> &
  Required<Omit<T, K>>;
type A = {
  foo: string;
  bar: string;
  baz: string;
};

type B = RequiredExceptFor<A, 'foo' | 'bar'>;

const b: B = {
  baz: 'test'
};

ArgType<T, N>

引数のN番目の型がほしいとき。Nは省略可能で省略された場合は0番目の型

type ArgType<
  T extends (...args: any[]) => any,
  N extends number = 0
> = Parameters<T>[N];
const getNString = (num: number, str: string = 'hoge') => str.padStart(num, str);

type Arg1 = ArgType<typeof getNString>; // number
type Arg2 = ArgType<typeof getNString, 1>; // string

ToKeyValueTuple<T>

keyvalueのタプル型を得たい👀
例えば、関数で

const [state, setState] = useState({});
const updateValue = (key, value) => {
  setState(state => ({
    ...state,
    [key]: value
  }));
};

みたいなときに、stateのkeyValueのペアを引数でもらうのに型をつけたいみたいなモチベーション

type ToKeyValueTupleWithKey<
  T,
  K extends keyof T
> = K extends keyof T ? [K, Pick<T, K>[K]] : never;

type ToKeyValueTuple<T> = ToKeyValueTupleWithKey<T, keyof T>;
const a = {
  a: 'a',
  b: 10,
} as const;
type A = ToKeyValueTuple<typeof a>;

const aa: A = ['a', 10]; // 型 '["a", 10]' を型 '["a", "a"] | ["b", 10]' に割り当てることはできません。

なお、以下だとうまく行かない

type ToKeyValueTupleWithKey<
  T,
  K extends keyof T
> = [K, T[K]];

const aa: A = ['a', 10]; // ['a' | 'b', 'a' | 10]なのでエラーにならない

また気が向いたら追加していきます💪

2019年が終わる

もう後7時間後には2019年が終わる。全くなんの感慨もないし、実感もない。年々実感がなくなっていく。
僕にとって年越しというのは、祖父の家に行って寿司を食って、帰りの車の中でフロントガラスに雪が吸い込まれていく様子を眺めながら除夜の鐘を聞くことなのかもしれない。
そしてそのあと、コンテナが連なったみたいなカラオケボックスに行って友達たちがいかに地獄になっているかを確認することなのかもしれない。
しばらくそういうことは行われていない。
だから年末年始というのが実感を伴わないままやってきて過ぎていくというのが、ここ最近の通例になっている。

さっき作品が多分完成したので微妙にハイだ。多分というのは、後ほど見直すとなにかしら手を加えたくなる可能性があるからで、だけど多分このまま完成とする可能性が高いのでは?と思っている。
できたはいいけど、これは来年の1月からの展示で使うので今すぐ公開できない。できたものをすぐ公開できないのは悲しい。

展示すること自体、3年ぶりくらいになる。
年末に声がかかって出すことに決めた。そろそろ動きたいと思ったからだ。公募展で出展するのは一作品だけ。周りの出展者が決まると僕はなんとなく他の出展者のサーチをしまくった。久しぶりすぎてびびってる。びびってるし、やっぱり出すからにはポジティブな評価を得たい。調べたことで作成する作品に変更を加えるということはないけれど、なんか気になって仕方なかった。多分3年の間に随分と周りの状況が変わっているだろうし、自分も変わった。その差分がどの程度なのかを確認したかったのかもしれない。

制作は難航した。
序盤にしっかり失敗して、夜中3時に途方に暮れた。 絵のパーツが全く浮かばなくて、会社の往復中ずっとiPadにぐちゃぐちゃ描いてみたりした。
色も決まらなくて、絵の前でなにもせずに音楽を聴いて、取り敢えず、と言って漫画を読んで時間が過ぎた。
塗った色が気に食わなくて6時間くらい同じ色ばかりいじってみたりした。
さっきまで完成の見込みが立たなくて、どうすればいいのか途方に暮れていた。

絵を描いてる時に思い出すのは、大学の時に良くしてもらった柳楽先生の

絵は結局、色と形と構図

という言葉で、ずっと頭に残っている。
最近料理について考えていた時、この言葉が浮かんで、料理は味と香りと食感やなと思ったりした。

—-

2月から新しい職場に移って、もうすぐ丸一年。
仕事についてここでとやかく言いたいことはないけど、何事もなく過ごせている。

プログラミングは楽しい。もちろんなにをするかによるわけだけど、多くの場合コードを書くことは自分にとって楽しい。
楽しいことをやって金を得ている。絵を描いている時は金のことを考えると途端にしんどくなったが、コードは楽しく書いてられる。もちろん金を得られるからコードを書くというわけでもなく、家だと環境の問題で書くことができないのでわざわざコワーキングスペースに行ってまで書いたりしている。
結局物を作るのが好きで、それがコードから成ろうが、絵具からなろうがあまり差異はないのかもしれない。むしろ絵の場合は個人的な部分に深く根ざしすぎているし、マネタイズが非常に難しいこともあって、同じ好きを仕事にするでもプログラミングの方が合っていたのかなとおもう。
特に絵は3年前はなんとなく制作に金銭のことがちらついて、これが売れるといくら、あるいは売れやすそうな作品、飾りやすそうな作品、というようなことが常に浮かんでしまっていた。
3年経ってそういう気持ちは随分なくなった。もはや忘れ去られただろうという気持ちと、金は別で稼いでいるので、売れなくても困らないと割り切れるようになった。というより、売れなくてもいいので自分が面白いと思える物を、という気持ちが強くなった。

なんとなく仕事は辛いイメージがある。楽しくない、生きるために仕方なくやることだ、みたいな。
1日8時間、月160時間も費やすのに苦痛でいるのはどうなのだろうと思う。なんとなく子どもには仕事は楽しいものだと伝えたいし、子どもの前では楽しく仕事してるようにしたい。

個人的にアプリを開発しようと思ってコワーキングスペース通いを週一くらいで続けていたけれど、全く形にならないまま終わってしまった。これは来年頑張りましょう。

プログラミングの職種的に僕はWebフロントエンドデベロッパーに分類されるわけだけど、来年はデザイナーやサーバサイドとの協業をもっと意識的にしていきたいし、新しいことにももう少し挑戦したい。レガシーとの戦いもどこかでまとめておきたい。
これらは来年仕事でやりましょう。

—-

絵が完成して、今年これで何枚かけただろう。アナログ作品は記憶にある限りこれで4枚目。毎年4枚50年描いても200枚にしかならない。
200枚。人間の一生で描く枚数としては非常に少ない気もする。
もちろんそれはライフステージによって変化するし、いつか辞めたりすることもあるのかもしれない。プログラミングも全くしなくなる時がやってくるのかもしれない。であればできるだけ楽しく自分に嘘なくやっていきたい。

子どもが来年から幼稚園。
今は嫁の実家で同じ歳の甥っ子と戦争を行っていて、今そこに向かっている。
子供はかわいい。非常にかわいい。子どもと遊ぶのはすごく疲れるけど楽しい。だけどそれだけが自分の全てと言うことではもちろんない。
子どもと家庭と自分とのバランスをもっとうまくとりたい。

来年はオリンピックがある。オリンピックを見ながら酒を飲むのがすごく楽しみ。

そういうわけで、グッバイ2019

まぜそば。油そば。そういう系のやつのレシピ

まぜそばが好きなので自作している。
最近はまぜそばと呼んでいるけど、昔地元で見かけた時は油そばって名前だった気がする。

イメージ

油が絡んでいてしょっぱい、ラーメンというイメージ。というかラーメンのタレをスープで割らずに麺に絡めたらなりそう。
オイルと塩と砂糖と酢を混ぜたものに麺を絡めたら形になりそうな気がするけど、オリーブオイル一本だと弱い気がするので動物性の油があると良い。
油自体の融点は豚に比べて鳥の方が低いし、ラーメンって鶏ガラベースで作られることが多いので鶏油を使っておこうみたいにしている。

考え方としては、

  • コク+ 旨み + 滑らかさ = 動物性油 + 植物性油
  • 味 = 塩味 + 甘み + 酢

というイメージ。

スーパーで買えるつけ麺用の麺、或いはラーメン用の麺。こういうノリのやつ

https://www.life-netsuper.jp/fuchunakagawara/item/detail.php?im_id=13662197&detail_ilc_code=000008&detail_imc_code=001830&detail_isc_code=183010

タレ

  • 鶏油
  • オリーブオイル
  • 醤油
  • 砂糖

鶏油は、鶏皮が売ってたら鶏皮をカリカリに焼くと得ることができる。

このような感じだけど、もう少し小さく切った方が扱いやすいし、食べやすい。

量としては一人前に対して大さじ1から2くらいあると足りる。多分鶏皮1、2枚あれば得れると思う。量が足りなければオリーブオイルで補えばいい。
気持ち的には、鶏油だけでもいいけど、若干オリーブオイル混ぜたほうがあっさりする気がする。

使いそうな分の鶏油にオリーブオイル適当混ぜて、砂糖、醤油、酢を入れて混ぜる。これは普通に混ざらない。砂糖が溶ければいいやくらいのノリ。
麺に適当のかけて和えて、あとは醤油とか酢とか足しながら食べたらいい。特に酢は無限に足せる。

トッピング

肉味噌

  • 豚、または鳥のミンチ肉
  • 砂糖
  • ニンニク
  • 味噌
  • オイスターソース
  • 欲しければ鷹の爪

イメージとしては甘辛い味。麺と絡めたいので少し味濃いくらいの感じ。甜麺醤とか使うと雰囲気出ると思う。
最初にニンニクと欲しければ鷹の爪と油を入れて火にかけ、気持ちになったらミンチ肉を入れる。大量の油が得られるようならどっかでキチペ(キッチンペーパー)で拭くといい。
火が通ったら各種調味料で味付けする。俺は辛いものがええんやとなれば豆板醤でも入れておくといい。

その他お気持ちトッピング

■ 玉ねぎ、或いはネギ

玉ねぎは粗めのみじん切りにして塩揉みして、水にさらしておく。玉ねぎのベストプラクティスがわからず、最終玉ねぎが口を支配することになるので、4分の1個とかにするか、白髪葱とか青ネギのみじん切りみたいなのでもいいと思う。 この生玉ねぎの辛さを軽減する方法はマジで知りたい

■ 煮卵

樋口直哉氏の素晴らしい記事があります。

https://note.com/travelingfoodlab/n/n07b2ebda1e5f?creator_urlname=travelingfoodlab

■ もやし

簡単に火を通したものでもいいし、茹でたものでもいい。ナムルでもいい。

アドバンスド

最初に書くべきだったけど、最終的な味をどうするかというのを思い浮かべて、足すなりするといい。
上記でベーシックなわけだけど、ここに花椒と、唐辛子、胡椒をがっつり振るスパイシーになるし、好きならパクチーを入れると雰囲気が出る。パクチー入れるなら酢を強めに効かせるとより良い気がする。
食べながら適当に味を変えていくのも面白いと思う。

コンポーネント指向とデザインに対するメモ

知り合いでWebの会社やってる人が、ツイッターコンポーネント指向について、Vueを始めて初めて実感として理解できたと言ってた。
その人はデザイナーがメインで、フロントエンド周りはある程度というスタックの人だけど、確かにそうかも知れんなーと思ったので、いつかネタにするかもと思いながらメモしとく。
コンポーネントベースの考え方ってアトミックデザインやらなんやらの文脈で散々語られているけれど、デザインの文脈から理解するのが結構難しいのかも知れない。
僕も普通にWebサイト作っていた時は実感として理解できていたかわからないし、Vue始めた頃になってようやくコンポーネントで組み立てるってなんなのかわかった気がする。
昨今の開発において、デザインとフロントの距離がどんどん近づいていることは周知の通りだと思うし、デザインベースでコンポーネントが考えられていないと、もちろん実装が破綻する。
なのでこの辺の意識のすり合わせを行う時に、知識差や実感としての理解のあるなしが、デザインとフロントの間の距離に関係してしまうことになる気がしているので、そういう何かがあってもいいかもなーと思った。