ラクスフロントエンドチームLT会 2024/1・2月議事録

2024年3月28日 08:12

こんにちは！ラクスフロントエンドチームの松本です！
来週には4月を迎えるというのに、まだ肌寒さが残る日々ですが、安心してください。ビール片手にお花見できる時は、刻一刻と迫っています…！

さて、今回はチームLT会 1月・2月分の議事録を共有します。

ラクスフロントエンドチームでは、チームのコミュニケーション活性化を目的とした、チームLT会を開催しています。（会の目的や、効果についてはこちらの記事にまとめています。ぜひ、ご覧ください！）
チームLT会で発信した情報は、社内だけでなく世界にも余すことなく発信していきたいと思い、noteにて定期投稿しています。

フロントエンドネタ

TypeSpecの紹介

Microsoftが出しているTypeScriptっぽくOpenAPI定義を書けるライブラリ

■個人的には以下のような使い方がアリかと思っている

ドキュメンテーションはTypeSpec(+ Redoc + Docusaurus)でOpenAPIリポジトリとして管理
アプリケーションではkiota、OpenAPI generatorあたりで生成したクライアントコードを使う

■嬉しいところ

YAML/JSONと比較して馴染みのある構文である + ドキュメントに対して静的型付けが行われるところ。
Syntaxがめちゃくちゃ豊富。欲しいものは大体あるhttps://typespec.io/docs/getting-started/typespec-for-openapi-dev
linter, formatter, vscode extensionのようなエコシステムが一通り揃っているところ(ヒューマンエラーが減らせる)。
ドキュメントとアプリケーションリポジトリが密結合にならないところ。
NestJSやSpring Bootだと、パッケージに同梱されているswagger-uiが〜みたいな事が多いため、ドキュメントのメンテが比較的楽に(依存が小さいので捨てやすく)感じる。

■期待しているところ

今後TypeSpec -> TypeScriptあたりはサクッと起こせるようになりそうな予感はする。
kiotaのようなクライアントコード生成ライブラリは既に出ているので、現状TypeSpec -> kiota のような使い方が良さそう。https://github.com/microsoft/kiota

■コメント／ガヤ
・バージョンが1になってないのが懸念
・TSに馴染みがある人は良さそう

TanStack Formを使ってみての所感

■コメント／ガヤ
・良いまとめですね(個人的にTanStack Formの好きなポイントが書かれていた)
・FormStateのObserverとかvalidateAsyncあたりは直感的に使えそう(+ 現代のリアクティブプログラミングと親和性が高い)ので今の方向性で行ってほしいと思っています。

> そもそもzodがフォームバリデータとしてどうなのか説はある
・同感です。zodやvalibotはForm Validatorと言うよりはJSON SchemaのSerializerのようなイメージを持っていた。本来HTTP Request/Responseの成形の層で本領発揮されるものじゃないのかなーとか考えています。

・valibotはコアパッケージでi18nのマッピングを持ってくれているのとトランスパイル後のjsファイルがzodより軽量なので、個人だとvalibotばっか使ってます(シェアはzodですが...)
https://valibot.dev/guides/internationalization/

多言語対応の日付の取り扱いで迷走した話

・プロダクトのスタンスは将来的に多言語対応の可能性はあるというレベル ⇒ いずれにせよ、メッセージの一元管理はしたいので、i18nextを採用

・多言語対応するなら日付の表示形式って変わるよね（曜日の表示もあるのでその変換も）
⇒ i18nextにDateTimeフォーマッター組み込まれているらしい、i18nextのJSON定義↓でいけるか

"yearMonthDayWeekday": "{{val, datetime(year: 'numeric'; month: '2-digit'; day: '2-digit'; weekday: 'narrow';)

⇒ 何だかんだutilsでフォーマット関数あった方が使い勝手いいよね、でもIntl.DateTimeFormatのインスタンス生成って負荷大きいらしい
　予めインスタンス生成しておいて、言語切り替え時に再生成する関数も作っとくか

⇒ 無理してIntl.DateTimeFormat使う必要ないな、i18nextのJSON定義で言語毎にフォーマット指定↓出来れば十分か

"yearMonthDayWeekday": "yyyy/MM/dd(E)"

⇒ i18nextはメッセージ管理に特化して、フォーマットは別管理の方がいいか

⇒ API通信時にTimeZone入ってないし日付は暗黙のJSTで画面上整合性取れているっぽく表示できるってレベルだし、現時点ではベタでいいな（DatePicker用のLocalもja固定に）

■まとめ
日付はちゃんと考え出すと沼る（TZ,Locale,閏年,閏日,閏秒,グレゴリオ/ユリウス暦,元号,サマータイム,2038年問題...）

■コメント／ガヤ
・マジのガヤですが、うるう秒は廃止されるらしい
・担当プロダクトの英語化対応で日付の入力欄の順番どうすんのって話が出てます

Reactの仮想化対応についての相談

担当プロダクトで使おうとしているライブラリ

入力フォームが複数あるテーブル行の仮想化でパフォーマンス懸念があり使用（Max 200行 × 4個）
MUIの example にもある
テーブル用のコンポーネントがあり、sticky header にも対応
仮想化 + α で Drag & Drop で並び替えとかしようとすると考えることが増える
参考）マネーフォワードさんの例

■コメント／ガヤ
・私のプロダクトではメモ化を頑張りました

その他技術ネタ

Jujutsuのまとめ記事の紹介

少しまえにXで話題になった、Gitから置き換わるかもしれないJujutsu。
そんなJujutsuについて、すごくまとまった記事を共有します。

■コメント／ガヤ
・意味と読み方は柔術かも

カナダのカレッジとコーディングテスト対策について

フロントエンドエンジニアになる前に、カナダのカレッジに通っていました。その時に使っていたプログラミングカリキュラムの共有です。

あとは、カナダでの就職活動でコーディングテスト対策で使ってたサービスも。
https://leetcode.com/problemset/

■コメント／ガヤ
・LeetCode面白そう(一時期AtCoderドハマリしていた人)。日本だと企業独自のコーディングテストかPaiza(問題が簡単すぎるので最近は見ない)が多いけど、ある程度オープンなサービスで揃えてほしいですね。
・転職時期にpaiza少しやったけど面白くないのでやめてしまった。
・LeetCodeはEasy全部とMedium半分くらい解けるようになれば、コーディングテストで落ちることはなくなると聞いたことがある...※個人の見解

開発管理ネタ

スプレッドシートのセル結合がつらいので足掻いてみた話

■コメント／ガヤ
・集計不要な場合は安易にセル結合しがちだな・・
・私は条件付き書式で「上と同じ値の場合は薄グレー文字」にする派です

UI/UXデザインネタ

『オブジェクト指向UIデザイン』を読みました！

■この本を読んだ背景

担当プロダクトは現在、デザイナー不在
だがしかし、ユーザーにとって使い辛いUIがある
幣チームはこの課題に対して、UI改善の提案をやっている

■この本を読んでの所感

なぜ使い辛いかを論理的に理解＆改善するためのヒントをくれた
実際の改善提案に活かすことができた

■コメント／ガヤ
・UIデザイナと同じ目線で会話するためにも読んでおいて損はないかも

終わりに

ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っています。ご興味ありましたら是非ご確認をお願いします。

採用情報

https://career-recruit.rakus.co.jp/engineer_jobs/frontend_tokyo/
https://career-recruit.rakus.co.jp/career_engineer/

イベント情報

https://rakus.connpass.com/

この記事が気に入ったらサポートをしてみませんか？

ラクス フロントエンドチームLT会 2024/1・2月議事録