nisshiee.orgnisshiee.orgTOPaboutblogYewのタスク管理アプリをコンポーネント化してみる(1)2019-01-24今日、ヌーラボさんのブログにて、こんな記事が公開されていた。かんばんライクなタスク管理アプリを作ってみました。ヌーラボTechBlogこれを見て、「そういえば最近Rust書いてないから書きたいなー」とか「wasmもそろそろ触ってみるかー」とか思って、触ってみることにした。こちらの記事がとても丁寧に書かれていて、Rust初心者でもコピペしていけばだいたい動かせるはず。興味がある方はぜひ写経してみてほしい。Started」としてはとてもクオリティが高いのだが、できあがったコードは1つのコンポーネントに全てのViewが詰め込まれている。(一応、Viewの構築を関数化して共用しているものの、コンポーネントにはなっていない。)ReactやVueなどを触ったことがあれば、この画面を見たときに、「このようにコンポーネント化されていてほしい」と思うはずだ。いうわけで、コンポーネント化してみた。今日は、黄色で囲った「Task」の部分をコンポーネント化してみたのでその部分について書く。Taskの部分は、元記事にもあったものを持ってきただけ。別モジュールに切り出しているのでpub属性をつけてあるのと、Propertiesのいち要素にするためにいくつかderiveしている。Componentする主体。意味合い的にはViewModelとかにした方が責務に合ってるんじゃないか?とか思ったりもしているが、一応本家の命名に合わせている。TaskでTask構造体をコンポーネント化できないか」という仮説を試してみた。結論としてはダメで、何故かと言うと、onchangeなど、Propertiesで与えられる付加的な属性を持つ場所が別途必要だから。Stateから持ってきている。元記事の「全入り1コンポーネント」で実装してしまうととにかくこの関数群が増え続けてしまうが、適切にコンポーネント化できると、関数群がパッケージ化されて見通しが良くなる。元記事のincrease_status関数は引数にidxというビジネスロジックではなくデータ構造に依存したものを受け取ってしまっているが、コンポーネント化したらidx引数が不要になっているのがわかると思う。}}で、Taskコンポーネントを使う側。元記事のview_task関数がなくなり、Taskコンポーネントを埋め込むだけに変わっている。Reactを書いたことがあればとてもイメージしやすいと思う。おわりにというわけで、部品をコンポーネント化し、コンポーネントをまたいでデータやイベントのやりとりをするコードを書いてみた。そんなに複雑なことはしていないという理由もあるが、比較的きれいにまとまったと思う。いうわけで次はColumnとHeaderもコンポーネント化してみよう。nisshiee.orgTOPaboutblog。