VueFes 2023 メモ
別部屋だったから日本語翻訳しか聞こえなくてつらい〜〜〜〜 になってた 日本語聞きながら英語スライド追うのむずい
Vue2 → 3 への移行における反省点と逆に良かった点の話、あとはこれからのロードマップ
クラウドサインのスポンサーセッション
2.6 → 2.7 → 3.0 の順にアプデを進めている
今は2.7
アプデが難しい理由
1. ライブラリのバージョンが古い
2. @vue/composition-api を剥がす必要がある
3. 破壊的変更への対応
かなり参考になりそう
eslint でルールを設定して、エラーになるファイルはTODOとして適用外にする
新しく作られるファイルは新しい書き方をされるという嬉しさ
進捗が一覧で見れるのも嬉しそう
進め方3つ まとめ
LT
PC、タブレット、モバイルの3つのブレークポイント
CSS grid
grid-template-columns repeat(12, 1fr) 、そうだね
grid-column auto/span 4 この書き方知らなかった
LT
Maplibre gis
WebGISではクエリパラメータに緯度経度を載せたい場合がある、そうなんだ
なんかわりとそれはそうだよねという実装ぽい、 loute.query.hoge を書き換えたり参照したりする
LT
積読ハウマッチ?!
使ってたライブラリがNuxt3対応してなかったから自作したという話? かな 強い
LT
23新卒!
Tauri Chromium を内蔵してない、WRY (webview rendering library) Rust
Rust も書くのか
サイズ 588MB→31.1MB
Vue というより Electron → Tauri への移行についての話だった
nuxt/bridge
QR からリアルタイムで投票できるのおもろい
EOL 2024/6 なんだ……
View Transitions API!!
デモ bun だ
set theory ってやっぱり集合論なんだ
まずは target user を定める developer or end user, vue developer or others, …
その中の一部が実際にユーザーになってくれる
最初の OSS の first start が kazupon さんだったという話
vscode-vue-i18n-ally
VSCode ユーザーであり、かつ Vue developer であり、かつ i18n 対応をしている
これってベン図の intersection のように表せるよね
VSCode && Vue: Vetur, Volar
Vue && i18n: vue-i18n
VScode && i18n: これがなかったので、こっちにシフトすることにした
Vite も同じ、最初は Vue のためのツールだった
この2つは universal になってよかった例
specific なもので良かったのは Nuxt
Nuxt - Nitro - …
Nitro: like vite, but on the server side
set union
DevToolsKit というアイディアを温めている Vue, Nuxt だけではなく React, Svelete などでも使える web devtools のための
modular, composable, collaborative
これマジでほしいな React 書いてると本当に Vue Devtools が恋しくなるから……
Anthony さんの発表、思想が伝わってきて好き
Vue とか React とか関係なく web 全体を良くしていこうという意思が伝わってくる(これは Anthony さんだけではなく Vue の開発者全体がそんな感じだけれど、特に)
集合論になぞらえてOSS開発の考え方をまとめてあるのもストーリーがきれい
Nuxt 2 は legacy browser もサポートしていた、 3 はしていない
What made Nuxt 3 possible? → UnJS
UnJS: Unified JavaScript Tools
Nuxt のためではなく、あらゆるパッケージから利用されるために作っている
lodash みたいなイメージ? かな
実際にどれだけ Nuxt 以外から使われてるのか気になる
Pooya’s tools , Tools for Nuxt, Nitro などがベースになっている
最近だと pdf.js がジョインして unpdf になったりした
unjs のパッケージ例いくつか
core of Nuxt CLI
.ts, .json, .conf などのあらゆる config をまとめてロードしてくれる
Nuxt 3 で使われている server engine
いま一番力を入れているのがこれ
express とかの代替になるもの
Nuxt 3 時代は axios を入れたりなどの必要があったが、 Nuxt 3 からはこれを使えば良い
SSR, CSR の両方に対応している
東京工業大学デジタル創作同好会traPの人だ
js でのマルチスレッドの利用方法
js はシングルスレッドで実行される、そうだね
回避策
1. js エンジンの外で実行する
Node.js なら Node-API swc, tauri などでは NAPI-rs を使っている
Deno なら FFI API, Bun なら bun:ffi
2. 複数の js エンジンのインスタンスを実行する
単純に別プロセスを実行する: jest はデフォルトでこれ、 vitest にも最近オプションが入った
Node.js: Cluster
Node.js: Worker threads, vitest はデフォルトでこっち
ブラウザ / Deno / Bun: Web Worker
今回話すのは2のほう
難点: 参照の共有ができない
なので
1. スレッド間でのやり取りのたびにコピーによるオーバーヘッドが発生する
2. スレッドの境界を超えた後では、参照の比較ができない
コピーが発生するので、異なるオブジェクトになる
3. コピーできないものはやり取りできない
関数や、クラスの情報(プロトタイプチェーン・クラス名など)など
4. コピーせずに移動。共有できる ArrayBuffer / SharedArrayBuffer が扱えるのはバイト列のみ
都度バイト列に対する操作に変換する必要がある
これをやってくれる buffer-backed-object というライブラリもあるが、可変調なものには対応していない
マルチスレッドを活用しやすい理想的な設計: スレッド間の依存関係を減らすことが重要
依存関係のパターンの例
グローバルで共有する状態への依存
関数を持つオブジェクトへの依存
参照への依存
いい感じにするライブラリ antichokieを作った、近日中に公開予定
複雑 GUI の話だ
スライドがきれいで分かりやすくてすごい
オブジェクトのサイズ変更
ユーザーがバウンディングボックスを変更 → vue が持つデータを更新 → レンダラーに描画されるオブジェクトの更新 → 描画されたオブジェクトのサイズを計測してバウンディングボックスを再描画
最後にオブジェクトに合わせてバウンディングボックスを再描画するの、なるほどなー
ズーム平面
1. 超巨大なコンテンツ領域10万ピクセルとか)で擬似的な無限スクロールを実現、ブラウザデフォルトのスクロールがいちばんパフォーマンス良いのでそれに任せる
2. ピンチイン・アウトはjs
パフォーマンスのため、 vue は経由させない
共同編集のデータはFirebase realtime DB にデータを丸ごと突っ込む
OpenAI 連携: デモが普通に使えそうなレベルですごい
現状のデザインとユーザーが入れたプロンプトの2つを渡して、デザインの差分を出力させる
差分だけにしているのは、そうでないと重すぎて実用レベルにないから