祖母の葬式

以前、祖父の死について書いた。
記事の祖父母は2人とも母方であり、父方の方はもっと早くに亡くなっている。

https://bom-shibuya.hatenablog.com/entry/2019/03/24/141302
https://bom-shibuya.hatenablog.com/entry/2019/04/12/182348

8/16に祖母が死に、昨日が葬式で参加してきた。
7月に帰省した際に祖母には会っているし、遠方だから葬儀は来なくても良いということだったが、祖母にも可愛がってもらったこともあるし、祖父の時は行って祖母の時は行かないというのも祖母に差をつけるようで嫌だったので、忌引きをとり電車を見つけて参列した。

祖母は何ヶ月も前から長くないという話を聞いていた。
7月の終わりに家族で実家を訪れた際、点滴が刺せなくなり、ペロちゃんキャンディで繋ぐことになった。
その後、お盆前にはキャンディさえなめることが難しくなり、口を湿らせることしかできない状態になった。
その状態で人間が何ヶ月も持つわけがないので、亡くなったと聞いてびっくりはしなかった。
ついに来たかと思ったし、やっと来たか、という気持ちもあった。
キャンディを取ることができなくなるなった後、一度突然目を開いて回復した日があったらしいが、それ以降はやはり駄目だったらしい。
葬式の帰りの車の中で母は、「足の指が紫になってきていた。こんなになってまで生きていなければならないのかと思っていた」と言った。

お盆は先祖が8/13にきて、8/16のお昼を食べてまたあの世に帰る。祖母は8/16の13時ごろに死んだので、祖父が来て、帰りに連れて行ったのじゃないかとお坊さんが言っていたらしい。
そうかも知れないと思った。

7月の帰省中、家族で老人ホームを訪れて、おそらくこれが最後になるだろうと思いながらひ孫たちと面会させた。
思ったよりも祖母は元気そうだった。手を動かすことはできるし目も開けていた。話すことはできないが、握った手に力を入れて意思表示するくらいはできた。
祖母の手を握りながら話しかけたり、ひ孫たちが笑いかけたりする中、すぐに疲れて眠りそうになっていた。
動けなくなってから、こうしてひ孫たちが祖母に対して話しかけてくれるのは皮肉だとも思った。

祖父が死んで、祖母は1人で暮らしつつ、母やその妹の叔母の援助を受けて暮らしていた。
ただ、祖母は生活能力がまるでなく、二層式の洗濯機で洗った衣類を次の日に脱水をかけ、さらに次の日に干すような人なので、家がすぐに荒れた。
帰省して会いに行く時に親はゴミ屋敷だからすぐに帰ってこいと言った。自分では何を話して良いかわからないから、親に一緒に来て欲しいと言ったが、来てはくれなかった。
祖母は初めの頃は入れ歯をカパカパさせながら、息子にクイズを出しながらお小遣いをくれた。金銭感覚も若干破滅していて、本当にもらって良いお金なのかの判断が難しかった。
その次に小さな娘を連れて行った時は家は実際、若干カオスの様相を呈していて、とても小さな娘と長居できる環境ではなかった。
30分くらい滞在して、出ようと思ったがひどく祖母に引き止められた。だけど衛生観念からも、子どもたちがここで遊びようがないことからも、後ろ髪をひかれながら早めに祖母の家を出た。
どうしたら良いのかわからなかった。久しぶりに来た孫とひ孫、帰ればあの家に1人。それも少しだけしか会えないなんて。

祖母は大きく腰が曲がり、入れ歯でひどく痩せていて、絵に描いたような老婆の様相だった。その上、積極的に子供達に近づいたり話しかけたりしてくることもあり、子供たちは少し怖がっていた。

前回の帰郷では、実家に祖母に来てもらう形をとった。
ずいぶん大人しく子綺麗になった印象だったが上の息子はそれでも距離をとりたがった。それを見て下の娘も同じことをした。一緒に写真を撮る時も少し嫌がっていたし、それ以外の時は隠れるなどしてずっとはいなかった。
俺はそれがひどく悲しくて、その後で強く叱った。

それが死にかけて、動けなくなった今の状態ではこうして話しかけてもらえている。ひどく残酷なことなのかも知れないと思った。

葬儀は家族葬でこじんまりと行われた。
父は祖母に対して当たりがきつく、直葬にすれば良いといっていたらしい。そんならお父さんが死んだ時は俺が直葬にしてやろうと言った。
開式の12時に少し遅れてお坊さんが到着した。曹洞宗。祖父は日蓮宗だったが、死後、お寺との関係が途絶え、諸々あって曹洞宗に変わったらしい。
葬式が始まり、お経が始まるや否や父は寝始めた。母隣で父の腕をつねり、幾度となく起こしていた。
自分は本当に父と言う人はこう言う人なんだと思った。

曹洞宗のお経はシンバルやら引導を渡す大声やらがあり、興味深く退屈しなかった。
祖父の時、お経を聴きながらぼうっと祖父についての思い出を振り返ったりしたが、今回は何も思い出せなかった。
時間が経ったからなのか、気持ちの整理がとうについていたからなのか、全て忘れてしまったからなのか。
生花を棺に詰め、祖母の頬を撫でる。冷たい。
出棺し、火葬場につき、最後の別れをする。焼却炉の中に棺を入れ、扉が閉まる。
ばあちゃんバイバイと、叔母がいう。自分はつい癖で、じゃあまたねと言いそうになったが、踏みとどまってじゃあねと言った。またはないんだなと改めて思った。

焼くのを待つ間、祖父のお骨をとりに例の祖父母の家に向かった。人が住んでいないし、畳がひどく汚れているからビニール袋のカバーを足につけて入る必要がある。
祖父は死んで8年経つが、まだお墓には入っておらずその家に置かれたままになっている。分家ということや、子が女2人で誰も後を継がず、お墓の管理ができないこと、祖母がこの状態だったこともあり保留され続けているということだった。

そんな中、叔母がとあるお寺に紫陽花を見に行った時に、非常に魅力的を感じ、その後今回の葬儀会社がそのお寺と繋がっていることがわかり、2人ともこのお寺の合同墓地に入れることにしたらしい。
以前の日蓮宗の寺とはすでに関係が切れていたため、宗派が曹洞宗に変わるがここに決めたということだった。

祖父もこれでやっと墓に入れる。一緒に入れてよかったねと叔母は言った。

お骨をとりに祖父母宅に到着し、中を見た。思ったよりも綺麗だった。長年生きていた金魚がいた水槽は空になっていた。
ここで祖父母から面倒を見てもらって、みんなで集まって、ご飯を食べて、父は酒によって潰れて、俺はお寿司をお腹いっぱい食べて、妹や従兄弟は遊んでたんだなと思った。
部屋の写真を何枚もとった。古い箪笥の中に入った角砂糖を勝手に舐めて、すごく美味しかった記憶が蘇ってきた。
もうすぐここは売られて、取り壊しになるらしい。

祖父が使っていた数珠を形見分けでもらった。
祖父のお骨の近くにあった。数珠の中の一つにガラス窓が空いていて、中を覗くと日蓮聖人が描かれている。

祖母は2年前に脳梗塞で倒れてから病院に入り、それ以降この家には帰ってきていない。その間祖父もひとりぼっちだったということだ。
祖母はこの家に暮らしていたことをもう覚えてないかも知れないと叔母は言った。
だけどどこからきたか聞くと、ちゃんとこの家の住所を言ったらしい。

火葬が終わり、骨を拾う。箸渡しをさせてもらい、緊張する。骨壷（というか箱だが）に骨を入れていき、紙で区切って頭骨は最後にいれる。職員が頭の形に頭骨を揃えてくれる。出来上がったものを父が写真に撮った。
帰りの車の中で、葬式で寝るような人間が、故人を偲ぶことをしっかりしない人間が写真を撮るのは本当に良くないと言って叱った。
その写真は偲ぶために撮ったのじゃなく、好奇心のために撮ったんだろうと思った。

お寺に祖父母のお骨を持って、お経をあげてもらう。確かに素敵な寺だ。うちの父と母ももしかしたらここに寄せることになるのかも知れない。
お経の後は軽くお寺で歓談し、お坊さんと叔母が合同墓地に納める契約の相談をしている。
妹の子は飽きて虫を探している。
窓からはオニヤンマが入ってきた。まだ蝉も鳴いている。
よく晴れてすごく暑い日だった。稲には穂がつき始めている。
住職と叔母の契約話をよそに、景色やお堂を眺めていた。
夏だなと思った。

子どもが産まれたし、最近のこととこれからのこと

11月に子どもが産まれた。
長女で名前は日菜乃とつけた。僕は5歳になった長男といつまでもふざけていてまともな案を出さなかったが、妻がいい名前を考え出してくれた。非常に素敵な名前だと思う。
女性の名前は難しい。いくつか考えてみたけれど、どうにもしっくりこない。
あまり名前に対して強い思い入れがない質なので、画数がほとんど命名の拠り所になっている。まず画数で調べて、その中で音と雰囲気で良さそうなものを選ぶことにしている。
長男の時もそうだし、今回産まれた長女についても上記の通りなので、幼稚園なんかで名前の由来を提出するような企画で少し困る。

11月の半ばから12月いっぱいは育休を取得している。 長男は予定日より早く生まれたので、今回も予定日より早めの11月に初旬頃に生まれるだろうと漠然と思っていたけれど、たっぷり予定日を超えて産まれた。
11月初旬に生まれたらその段階から育休取得すれば2ヶ月くらい取れると考えていたが、その目論見は完全に外れてしまった。
最終的には計画出産になったけれど、突然生まれるのと違って、産まれる日を決めることができてしまうので、お腹から出てくるのがなんとなく寂しいような気持ちになった。

出産にあたって、長男の幼稚園の諸々とか家事のことがあるので7時に起床することになった。今までは9時に起床することが多かったので心配だったけど、今は逆にこのサイクルに慣れ始めている。
7時に起きて洗濯や子供のご飯の用意、着替え、布団を片付けて幼稚園の支度、送り出し、諸々が済むと大体9時ごろになっている。
この調子が続くのであれば仕事に入っても問題ないと思うけれど、赤ん坊は刻一刻と状況を変化させるので、実際に仕事が始まる頃にはどのような状況になっているかはわからない。

もう長男は冬休みに入ってしまったので変わってしまったが、およそ午前中9時から長男の迎えがある15時ごろまでは、たまに赤ん坊の様子を見つつ自分の時間を過ごしていた。
絵を描いたり、最近では音楽を作ったり、または新しいプログラミング言語の勉強をしていたりするとあっという間に時間は過ぎる。
この時間が本当に楽しくて、いつまでも育休だったらいいのにとも思う。
思えば仕事で1日8時間働くというのは凄まじいことだ。
起きてから日が暮れるまで、体感的に最も人間が何かを行うのに向いている時間だと思うし、そんな時間を週の5日分も提供するということをもっと意識すべきだなと思う。

2年前の自分の日記を読み返すと、子供には仕事は楽しいものだと伝えたい旨を記述していたけれど、今もそれは変わっていない。
逆にいえば、上記のような時間を費やすことを考えると、前向きに過ごせない仕事だとすごくもったいないと思う。

仕事はおそらくうまくいっている。もう長いこと今の職場で働いたような気がするが、来年でまる3年ということになるらしい。
コードを書くことは相変わらず楽しい。コードを書くことはもちろん楽しいのだけれど、ここ最近は何を作るかということが自分のモチベーションに強く関わっていることに気づいた。

世の中には様々な課題があって、多くの会社はその課題を解決することで需要を創出し、利益を得ている。 その課題や解決方法が自分の関心に近いほど仕事は面白いのかもしれない。

子供と仕事の話をすることがある。仕事の話というか将来なりたい職業のような話をする。
話していると自分は社会にでてこの年齢なるまで、仕事の種類というものをほとんど知らなかったなと思う。
仕事だけでもないけれど、世の中にある様々なものを広く知ることで、可能性が広がるし、いろいろなことに興味を持ってその中から好きなものを選べるようになるといいなと思う。

音楽の制作は最近始めたばかりですごく楽しい。
元々音楽が好きで自分で作ってみたいと言う気持ちはあったけど、何から手をつけたらいいのかわからなくて後回しになっていた。
そんな中、たまたま先輩のところに遊びに行って相談したところ、使ってないMIDIキーボードがあるからといただいた。
それを毎日のように触っている。鍵盤を押すといろんな音がなってとても楽しい。
もちろんまだまだ思うようなものは全く作れていないけれど、もっと早くやればよかったなと思う。

もっと早くやればよかったと思うことは沢山あるし、今後も増えて行くと思う。
消化するには今は時間が足りなさすぎる。10年前は時間があったがお金がなかった。

だけど、今思えばお金がなかったというのはいいわけで、単純にお金を払う胆力がなかったんだなと思う。

少し前に、僕の職域の界隈で有名なazu氏が寄付に関するサービスをリリースしていて、そのドキュメントにお金を手放すことには苦痛が伴うということが書いてあった。

https://azu.github.io/slide/2021/open-philanthropy/open-philanthropy.html

思い返せば、今まで満足にお金を持った経験がなく、常にお金を使うことを避けてしまっていたので、僕は多分お金を手放す苦痛と今までうまく向き合うことができていなかったんだなと思う。

先日久しぶりに服を買いに行った。服や靴などを1人で買いに行くことは非常に久しぶりだったが、自分で選び何かを買うという体験はこんなに難しくて、こんなに楽しいものだったのかと思った。
何より僕は服を買うことが下手になったなと思った。 何かを決断するのにも苦痛が伴う。
このことと僕はもう少し向き合う必要があると感じている。

絵は引き続き描いている。
年内に一枚、少し大きめの絵を仕上げたいと思っている。
今回は特に展示をする予定もないし、おそらく完成してSNSにあげて、それでおしまいになると思う。
今年はおそらくアナログでは4、5枚、デジタルで着彩したようなものが他に何作か、それでも地道に続けている。

そもそも僕は絵を描いて何をしたかったんだろうなとよく考えている。
何者にもなれずに、特に評価されるわけでもなく、今後評価されることもおそらくはないと思う。
お金にしたいという気持ちもあまりない。展示をしたいみたいな気持ちはあるけれど、優先度としてはかなり低い。
東京のことは知らないけれど、関西アートシーンに対してははっきり言ってネガティブな印象を抱いていることも関係しているのかもしれない。

ただ、それでも描き続けているし、今のところ辞めるということは全く考えていない。

長男の幼稚園が冬休みに入って、昼間の自由時間はすっかりなくなってしまった。
子供を寝かしつけた後、可能であれば起きて自分の作業をする時間に充てる日々が始まっている。
来年になれば仕事が始まるので、この日々がまたずっと続くと思う。
これを繰り返すことは、なんというか、削っていくような感覚になる。

もしかしたら今後、絵を描くことは限りなく少なくなるのかもしれない。
でも絵の代わりにコードを描くことや、音楽を作ること、または違う何かを作ることは続けて行くと思う。

最近よく、人間というのはコンバータみたいなものでかもしれないと考えている。
なんらかの入力があって、それを何かの形に変換して出力することを繰り返しているのかもしれない。
入力は例えばその日の出来事や今までの記憶、経験みたいなもので、出力は入力に伴う単純な応答や、表情、あるいは料理、絵、創造物みたいなものになる。
自分は単純に、自分が何を出力するのかに興味があって、それが知りたいがためにずっとこの行為を繰り返しているのかもしれないなと、漠然と考えている。

自分が絵を描いて、世の中に対してインパクトを残したいというよりも、自分が何かを作るとどんなものができるかわからないから知りたい、みたいな単純な話なのかもしれない。

幼稚園が冬休みに入った長男と、毎日レゴで遊んでる。
レゴで何かを作るというより、レゴの小さいフィギュアたちに名前をつけて、毎日戦わせたり物語を作って一緒に遊んでいる。
この遊びはもう2年続いている。
2年間、ほぼ毎日ずっとこの遊びを繰り返している。
最初はトラックたちが主人公だった。毎日形を組み替えながら、何台かのトラックたちで話をして、物語を作っていた。
今もそのトラックたちはいる。長男の成長と興味の移り変わりに合わせて、トーマスが入ってきたり、マリオが入ってきたり、マイクラが入ってきたりして、ほとんどカオスな世界観が広がっている。
今、自分の一番の友達はきっとこの長男で、2人で2年かけて作りあげてきたこの世界は、本当に宝物みたいに感じている。
だけどいつかきっと、パパとは遊ばなくなって、この世界が終わって、この世界があったことも忘れてしまう日が来るんだろうなと思う。
それでもいいさ、それがいつになるかはわからないけど、だから今思う存分遊んでおかないとなと思う。

---

そういえば今年は個人制作でアプリを一つリリースした。長男がマイクラのスキン作りにハマっていたことがあって、既存のアプリだと作りにくそうにしていたので、より簡単に作れそうなものを考えて作ってみた。
マイクラのスキンを作るためのアプリで、ブラウザで遊ぶことができる。
カスタムスキンは残念ながらswitchのマイクラは非対応だけど、スマホ版やJava Edition では使えると思う。

https://minecraft.skin-editor.com/

来年はどんな年になるかわからないけど、後悔がないように楽しく過ごしたい。

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でwidthをpx単位とかで渡すのではなく、サイズを表す定数（たとえばlargeやあるいは使われるコンテキストの名前など）を定義してそれを渡すほうが良さそうです。 もし定義するのが辛くなるくらい大量に定数が発生する場合はもしかしたらデザイナーと相談したほうがいいかもしれません。

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

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

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

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

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

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

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

これは微妙に賛否が分かれると思うのですが、基本的にコンポーネント自体のスタイルとしてはdisplay: blockまたはflex, tableなど、インラインでないほうがいいのかなと思っています👀
理由はinline、inline-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);

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

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>

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

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