Closed5

メモ:アウトライナー制作進捗

waterz1815waterz1815

7/21

アウトライナー作成のため、部品の調整に着手した。モティベーション維持のために、作業過程をメモとして残す。今作ってるのは事前調査的なプロトタイプなので、陶芸家のごとくちょっと作っては壊しを繰り返す予定。公開の予定もないです。

とりあえず手始めにreact-outliner を react native用に作り替えている。

そのままReactでreact-outliner使って作っていってもいいんだけど、Expo使った方が速度が速そうなのと、ライブラリはどの道手を入れることにはなるので、そのまま使うより早い段階でバラして再構築した方が理解度が高まり、トータル手が早くなるだろう・・・という判断

react-outliner

中を見ると思ったより綺麗に書かれていてびっくりした。インターフェースベースの実装者の意図がわかりやすいやつ。多少クラシックだが様式美があっていいね。

割にReactに依存する部分とそうでない部分がわかりやすい形で分かれていたのは助かる。

ElementでDivタグ使ってるところを、react-native系のタグに差し替えるのと、DnD系のライブラリをReact系の「react-beautiful-dnd」からNative系の「react-native-drax」に差し替えればいいかな。

ローカルにreact-outlinerのコードを取り込み

importしたときの拡張子の扱いに癖があるなと思った。*.tsxとかは、拡張子書かないのね・・・

react-native-drax

めちゃめちゃ作りこんでるライブラリだったのね・・・コード見たら重量級でした・・・。とはいえ「react-beautiful-dnd」とインターフェース似てる部分もあったので差し替えるには都合がいいかも。

DnDの仕組みをコード見て理解するのは「react-native-easy-dnd」の方が短くていいかも。

キー入力イベント

native系ってキー入力判定に癖がありげ。プラットフォームの種類意識しないと、そんなキー判定プロパティないでーすって怒られるのが痛い気がする。

今はイレギュラー系は無視して、Webアプリ環境で正常系を検証する。ん?keyDownやkeyUpなくて、keyPressイベントしかないの?後の課題になりそう。

ReactNativeでのキーボードイベントって、仮想キーボードの出し入れを指すのね・・・。

waterz1815waterz1815

7/23

ざっくりとNative系にコンポーネントを置き換えた。

元のコードがクラスコンポーネントベースなので、関数コンポーネントベースの感覚で書こうとするとすぐ引っかかってつらい。

大きな変更としては「react-native-drax」の場合、KeyPressイベントが無効化されてしまうようなので、「react-native-easy-dnd」に置き換えた。

ある程度動かすと、キーバインディングとかの細かい動作が気になってしようがない。
見た目の向上、操作性向上、機能向上・・・それぞれをテーマに取り組む

waterz1815waterz1815

7/30

いくつか期待通り動かない課題があり、調査にかなり時間がかかっている

  • DnDの挙動がやたら遅い(Droppableの生成が重いっぽい)
  • カーソル移動の挙動がやたら遅い(参考元のコード側では、forceUpdateベースの実装になっていた)

また参考元のコードとやりたいことが違うため、実現したいことのギャップが大きいことに気付く。
同時に技術的な課題もいくつか見つかった。

  • 参考元のコード側では、(処理が軽量なせいか)モデルから毎回コンポーネント作り直せばいいという思想。こちらはコンポーネントが重いため(それは別途解決予定)ミスマッチ。
  • 参考元のコード側では、元々クラスコンポーネントベースで作られており、関数コンポーネントベースの知識が適用できなかった

一旦、苦しみながらうまく行ってない所をクラスコンポーネントで作り直してから、安定して動くようになったら関数コンポーネントの置き換えを考える。

waterz1815waterz1815

8/1

ポエム

  • 少し進んで、課題に当たって、これダメじゃんってなって、へこむ。体感は1歩進んで半歩下がる感じ
  • でも課題が明確化されてるってことだから、ポジティブにとらえなきゃ
  • 都合が悪い状況になる度、基本に戻って確認となるので、基礎力は向上した体感はある。(問題は十分をいつ感じるかだが・・・)
  • 参考元コードの意図が理解ったけど、破綻箇所とその対策も見えてきたとき、なんか一瞬超克したような高揚感が得られて好き。

知見

  • 関数コンポーネントは記述がシンプルになるが、ステートやカスタムフックの数が増えるなど複雑さが増すとクラスコンポーネントの方が取り回しがよくなる。可能な限り分割して関数コンポーネントを維持するのが理想
  • 外部からの操作が必要なオブジェクトをリスト管理するときは素直にクラス化する(コンポーネントの話とごっちゃになって毎回混乱してるけど)
waterz1815waterz1815

Obsidian 使うようになったんで、自作のOutlinerは別にいいや・・・ってなっちゃいました。
閉じまーす。

このスクラップは2023/10/13にクローズされました