音声書き起こし
1. オープニング
@potato4d
こんにちは。uitのコーデです。ユナイタスと敵のに対する開発者のためのプロキャストuitインサイド、今週もやっていきたいと思います。 今回はですね、タイプスクリプトコンパラapiを、円滑に入力するためのライブラリー、ts毛布を使って、作った成果物であったりだとか、ま、そのts毛布自体の良さっていうのに、ついて語っていきたいと思います。 よろしくお願いいたします。
@odiak
よろしくお願いします。
@potato4d
今回はですね、ゲストにお2人招待しておりまして、かいどうさんと、このさん、お2人をご招待しております。では、かいどうさんの方から自己紹介お願いできますでしょうか。
@odiak
はい。line福岡に所属しています、フロントエンドエンジニアの岩本海童です。line証券のフロントエンド開発を担当しています。よろしくお願いします。
@potato4d
はい、よろしくお願いいたします。では、このさんの方もお願いいたします。
@kazushikonosu
はい。このかしと申します。lineの東京のオフィスに所属していて、最近だとlineスキマリの開発を担当しています。
@potato4d
よろしくお願いいたします。 ではですね、早速本題に入っていきたいと思いますが、今回のテーマは。冒頭にも話した通り、タイプスクリプトコンパイラーapiを、 うまく使うためのライブラリー、ts毛布っていうものがあるっていうところかなと思うんですけど。ですが、その前に、そもそもts毛布ってどんな感じで、使えるものなんだっけ。みたいなのを、説明できればなと思っておりますが。このさん、ちょっと紹介お願いしてもいいですか。
2. ts-morphについて
@kazushikonosu
はい。ts毛布っていうのは、タイプスクリプトのコンパイラのコンパイラーapiのラッパーのライブラリーになっていて、ま、タイプスリプトのコンパイラーのapiを直接触るよりは、 こう、簡単にタイプスクープトのatの操作ができるか、そういう関数を提供してるものになります。 結構、タイプスクリプトのコンパイラpiは複雑なんですけども、その辺がこう、うまくラップされてるかな。
@potato4d
例えば、どういう感じのものがラップされてるライブラリーになるんですかね。そ、
@kazushikonosu
そうですね。例えばですけど、コンストで定義されてる変数を探してきたりだとか。ま、なんかそれ、見つけてきた変数に対して、まる条件で、ま、名前を変えたり、操作したりとか、そんなことができるイメージかな。
@potato4d
こう、便利そうですね。私もなんかコパラペア直でぐらいでしか使ったことないんですけど、めちゃくちゃめんどくさかったんで、なんかそういう、こう、探すとか、完全にライブライ側に寄せられるとかなり便利そうな気がしますね。 なるほど、ありがとうございま。そうです。まではそんなts毛布、どんな感じで使って開発したかみたいなところを聞いていければなと思いますが。じゃ、今回、それぞれ2人とも成果物を、 実際に実務で使う生活を作られたっていうところなんで、具体的にどんなもの作ったか聞いていきたいなと思ってますけど、引き続き、じゃあ、こうのさんの方からお願いしてもいいですか。
@kazushikonosu
ツールで前提から話すとか、タイプスクリプトのtscを使っていると、使用されてない変数だったりとか関数とかって、多分エラーとして検知してくれて、それでこう、コードの品質を高めるみたい ことができると思うんですけど、それって、エクスポートされてる箇所があると、仮にそのエクスポートが1箇所でも使われてなかったとしても、エラーとして検知できないみたいな問題があると思っています。 でまあ、なので、なんかそのエクスポートされてるけど使われてないみたいなものについて、それを検出して、エクスポートキーワードを取り除いて、そうすると使用されてないかどうか
@kazushikonosu
がわかるので、それを全部自動で削除するみたいなツールになっていますが、さらに、なんかそこから踏み込んで、あるファイルの エクスポートの全てがどこでも参照されてない場合には、ファイルボットを削除してしまうみたいな機能も持たせて、ま、リファクタリングとかになってる。
@potato4d
便利ですよね。ユーティルみたいな、ああいう、こう、色んなところからインポートすること前提でエクスポート書いたらいいものの、結果なんか使われなくなったみたいなコードって、プロダクト開発してると出てきがちでしたけど、そういうの、結構一層できるっていう感じ ですかね。
@kazushikonosu
そうですね。なんか、元々の課題感としては、uiライブラリのリプレイスの作業するっていう機会があって、ま、そこで、こう、ちょっとずつコンポーネントごとにリプレイスしていくみたいな 作業が発生したんですけど、コンポーネントがエクスポートされてて、ま、どこで参照されてるか、その把握するのにすごい時間がかかったので、果たしてこのコンポーネントは削除していいのかなんか、もしくは、まだ使ってるのかみたいなのを判断できなか
@kazushikonosu
あ、みたいなのがああります。で、なんかのツールとしてtsplonっていうものもあるんですけども、これはメンテナンスフェイズであって、かつ、この列挙してくれるだけで、自動でコードを見てさく編集してくれ、削除してくれ、 言葉ではしてくれないので、なんかその辺でこう自作ししてもいいかなっていうモチベーションが高まりました。
@potato4d
確かにこう列挙するだけだと、どうしてもこう、手動でま、ないよりは絶対あった方がいいものの、こう消すところまでやるとどうしてもこう作業のコストがかかったりとかってのがありますし、こう気軽にあの一括削除かけましたみたいな感じで言えるわけでもないんで、 なんかもう定常的な業務になっちゃうっていうのありますもんね。
@kazushikonosu
そうなんですね。どうしても単調な作業になってしまうので、なかなか誰もやりたがらないので、その結果、放置されることになっちゃうので、 ここ、そういうツールがあって、仮にこう、100パーセントリファクタリングの自動化ができなくても、90パーセントぐらい自動化して、ま、そのcliが対応できない部分だったりとか、本当にその、ちゃんと削除できてるかみたいなのは、プルリックのレビューで担保して効率化ができたら、 きっとうまくいくだろうなと思ったんで、そうい
@potato4d
単調なところほど、こう、コストはかかる割にリターンはそんなに実感しづらいところなので、そこはもう完全に自動化しちゃって、やんないといけないところだけ、 こう、フォーカスできるようにしたって感じですね。そうですね。なるほどなるほど。なんか作るにあたって、作りやすかったみた。要因とかもあったりするんですか。
@kazushikonosu
あ、そうですね。結構、その、開発してるプロダクトがリアクトをベースにしていて、ま、リアクトのコンポネントとか書いてるとこ、結構関数型で、ま、フックとかも含めて、 あんまり副作用がないみたいなのもあるんで、なんか仮に、こう、もう少し、手続き的な書き方をしてるものだったら、なんか、エクスポートはしてなくて、なんか、特に参照されてないけど、そのファイルを読み込むことに意味が、
@potato4d
あー、はいはい
@kazushikonosu
したりすると思うので、まあ、なんか、そういうのがない分、ファイルの削除とか、グレッシブな機能も取り入れやすかったかなと。
@potato4d
なんかこう、言語的にも、tsプラスアクトっていう環境が、こう、ツールツールにもマッチしてて、うまい具合に使えたかなって感じだったっていうところですね。
@kazushikonosu
そうですね。確かにビューとかだったらccのバースとかも必要になって、もう1ステップ必要になるんで、そういう意味でもこのtsモーフがすごい合ってる 環境だったかな。
@potato4d
はい、ありがとうございます。 結構tsリムバンド単体でも1エピソードとっても良さそうなぐらい、なんか便利ツールな話もな気がするんで、また詳しく聞きたいところではありますね。はい、お願いします。 では、かいどさんの開発したツールの方もちょっとお伺いさせてもらってもいいですか。
@odiak
はい。僕が作ったのが、っと、ルートアナライザーという名前のルーティング定義を解析するツールです。 リアクトルーターのバージョン5を、ま、一応、対象にしてるんですけど、ソースコードの解析 して、ルーティングの一覧、パスの一覧を出力したりとか、あとは、その、どの、どのページ、そのパスに、どのコンポーネントが使われているのかっていうのを調べて、その、依存関係を解析したりっていう
@odiak
と、してます。で、そこから、ま、例えば、ブルーリクエストとか、ま、大きなビーチャーブランチ 単位とかで、そのブランチで、どのパスの画面が変更されたかっていうのを、検出したりっていうことが、できるようになってます。
@potato4d
なるほど、なるほど。まあ、あれですかね、あの、コンポーネントの依存関係を明確にして、影響範囲とかを洗い出すしやすくするみたいな。
@odiak
そうですね、ま、それが1つと、あとは、そもそもアプリが大きいと、ルーティングのなんか一覧っていうのは、結構把握できなくなってることがあるんで、それをそもそも可視化しましょうっていう 面もあります。
@potato4d
なるほどな。 なんかこう、新規参入者であったり、一部のページを中心に開発している開発者とかの人が、ま、新たにページが増えたり減ったりしたのっていうのも、こう、常にトラッキングできるようにしたいみたいなモチベーションがある ですね。
@odiak
まー、あのエンジニア以外の、あのqaの方とか企画の方とかにも役に立つかなと思ってます。あー、
@potato4d
なるほどなるほど。確かにこう開発する、その時以外にもいろんな人に共有するドキュメントを生成するっていう意味でもそうですね。こう使えるっていう ところですね。これ、そもそもなんかモチベーションっていうのはあれなんですか、あの画面のモーラがちょっとどっかにあげようと思った時に大変だだったみたいなところからのスタートなんですかね。
@odiak
そうですね、まあ、あの、なんですかね、リグレッションテストっていうのはよくやっていて、で、そのテストをどこをやりましょうっていうのを 結構調べるのが大変だったので、そのツールでラックできないかっていうモチベーションがありました。
@potato4d
なるほどなるほど。じゃあ、テスト範囲をこう明確化するために、行動の影響範囲を洗い出したいっていうのが
@odiak
1番ね。はい、
@potato4d
肝だった感じっすね。 なるほど。じゃ、結構あれなんですかね、このルータライザーの使い方としては、実際のプルリクとかからコンポーネントを洗い出して、そのコンポーネントが使われてるページパスを一覧で出力して、うんうん、それを見せてるみたいな感じですかね。
@odiak
そうですね、はい、そういうイメージです。
@potato4d
確かに結構なんかこう、せっかくなんで一応ちょっと確認、全体確認しといてくださいとか、こう、ちょっと影響おっきめのコンポーネントではあるんで、全ページ見といてくださいみたいな感じにすると、 基本的にこう、大井側、多く多く広く広くる、太るようになってしまうんで、それをこう、できるだけ最小限にしたいみたいな、
@odiak
はいところに
@potato4d
繋がってるっていうとこですね。
@odiak
そうですね、うん。
@potato4d
じゃ、あれですかね、ciとかで使うのを結構想定して作ったみたいな感じ
@odiak
ですかね。あ、そうですね。ちょっと、あの、まだciには組み込めていなかったんですけど。はい、そういう使い方を想定してやりました。お、あとは、その、各ルーティングに対して、そのーなんです。 このページはどういう内容のページですよみたいな、こう、ドキュメンテーションを書いておいて、ま、それを、そのルーティング一覧だとか 影響を範囲一覧みたいなところと付き合わせて、人間が読みやすい結果を作るみたいなところも、ちょっと一部作ってました。
@potato4d
なるほどなるほど。じゃあ、もう、なんか、人間向けと、こう、システム的にこう、分かりやすくする向け、両方こう兼ねるために、
@odiak
そうですね、はい、
@potato4d
活用していたって感じですね。結構、なんかあれですね、利用用途も広くて良さそうですね。ありがとう。ありがとうございま では、次にですね、今、結構ツールを使って、実際の業務に関わるようなところで、tsm使ってツール作ったみたいな話をしたかなと。 ですけど、ちょっと技術的な部分、あのコンパイラーapiであったり、tsmのこの技術的な部分に触れていきたいかなと思うんですけど、
3. そもそも Compiler API を直接使ったことはある？
@potato4d
そもそも2方、元々、この、今回ts毛布を使う前に、コンパイラーapi、直接使った経験とかはあったんですかね。
@kazushikonosu
そうですね、僕は、 ま、ツールを使うにあたって、コンパイラapiとかts毛布とかを、こう、初めて、こう、見てみて、ま、検証のためにコンパイラapiまで少し触ったんですけど、ts毛布、ts、タイプスクリプトコンパイラー、
@kazushikonosu
あの、ネイティブesmを扱うトランスフォーマーとかもコンパイラpiで入ってた。
@potato4d
そんな。じゃあ、初めに、ま、同時に使い始めて、こう、ts毛布で慣れたところもあるんで、ま、こう、コンパイラpi使う時は使うようになったみたいな、こう、同時に使い始めて、使い分けるようになったみたいな感じですかね。 そうですね。そんなかいどうさんの方はどんな感じですか。
@odiak
はい。僕の方は今まで何度か、あの、コンパイラfiの方を使ったことがありました。で、tsmfの方は。割と最近知って 使い始めたんですけど。はい。で、今までなんか、 ここまで大掛かりではないんですけど、ちょっとしたツールを何回か作ったことがあって、そこでコンパリアを何回か使いましたね。
@potato4d
あー、なるほど。あ、これまでずっとコンパイラpi使ってたところから、なんか今回ts毛布使ってみようかなって思ったモチベーションって、なんか、どんな感じなんですかね。
@odiak
そうですね、その、なん生の、今回はapiを使うよりも結構記述が短くなるというか、ボイラープレート的なところがこう吸収してくれる役割がありそうだなと思ったんで、ちょっと使ってみるかということで 試してみました。
@potato4d
なるほどなるほど。ま、ここ社内ツールなんで、別に依存関係増えてもいいから、作るときの生産性を重視
@odiak
来たみたいな感じ。はい
@potato4d
ですね。なるほどなるほど。なんかコウノさんは今回初見で、あの、両方使ったみたいな感じかなと思うんですけど、あのts毛布を1回目使うことにした理由みたいなのって、 なんかこう、初見での比較で言うとどんな感じだったんですか。
@kazushikonosu
そうですね、も最終的には、カイドウさん言ってるんですけど、コンパイルapiって結構ドキュメントが少なくて、ツールを作って 早く運用したいっていう、その目的を最短で果たすはちょっと微妙そうだったみたいなのが います。なんか少し話が出てきたんですけど、コンパイラpiは結構コイルプリボイラープレートが多くて、例えばtsコーフィンを取り込んでプロジェクトを初期化するっていう、そのステップだけでもなんかいくつかこう
@kazushikonosu
ステップが必要で、結構な量のコードになるので、なんかその辺をこう、いい感じにまとめてくれるts毛布はありだなっていう。
@potato4d
確かに結構tsコンヒグ読み込んで、あれですよね、こう、astを触るところに行くまでがもうすでにめんどくさいみたいな感じありますもんね。コンパイラpiに関して。そうですね。
@kazushikonosu
さらになんかそこもドキュメントがあるわけじゃない。そこもなんか調査しながら書かなきゃいけないので、そこをやりたくない。
@potato4d
こう、資料もそんなに信頼性というか、がっつり触ってる人が多くないのもあって、結構こう、コンパイラpiを使ってるossを読んで理解するみたいなところからのスタートになりがちっていうのもありますもんね。 コンパイラpiに関しては。ま、そうですね。その辺、ts毛布だとあんまり考えなくていいんですかね。
@kazushikonosu
そうですね。なんかtsfは結構ドキュメントがしっかりしていて、 tsポフが提供してる各apiについて、どういう使い方をして、ま、どういう例があるかみたいなものまで書いてあるので、あ、その辺はすごいしっかりしてるな。
@potato4d
なんかこう、努力して走り出さなくていいっていうのがある感じですね。
@kazushikonosu
ですね、こう、ツールを作るっていう意味では、最短で達成できるかなっていう。ありがとうございます。
@potato4d
なんか今の段階でちょっと、これももうすでに、ts毛布のなんか良かったこととか利点、使う利点の1つ、走り出しがいいっていうのも、こう、利点の1つからなのかなと思うんですけど、おさかさんも使ってみて、あの、ts毛布自体のその、例えば機能であったりだとか、まかきこ とかでもいいんですけど、なんかやってみてよかったみたいなところってあったりしますか。
@odiak
先ほどもコウノさんがちょっと話されてたことと 重なるんですけど、コンパイルapiそのまま使う場合は、ソースファイルとかタイプチェッカーとか、その辺のオブジェクトをま、よく使うんですけど、 それを、あの、自分で持ち回さないといけなくて、その辺が、やや、ちょっとめんどくさかったんですね。
@odiak
っと、ts毛布だと、その辺が、その、内部で参照を持っているので、あまり気にせずに、その辺のapiを呼べるという メリットがありましたね。ま、あとは、その、よくよく書くような処理がメソになってるんで、コードが短く区切るという、
@potato4d
よく書く処理っていうと、例えばどういったものがある感じ
@odiak
ですか。っとー、その、nstのノードの種類が、この、その、種類を、あ、タイタイプじゃないや、カインドをアサートするっていうのとか、あとは、その、 ま、子孫のノードを全部探索しますみたいな処理とかですね。はい。
@potato4d
あー、確かに結構こう、毎回書かないといけない系の処理を全部こう、上手いことやってくれるって感じ。そうなんですね。はい、 特にそうですね。なんか、ルートアナライザーのカイドさんが開発されたやつとかだと、子孫ノードの探索とかは、こう、自分でやるよりも、こう、ネガワバライブライがやってくれると嬉しい領域ではありますし、 結構重宝しそうですよ。
@odiak
はい。あの、ts毛布のメソッドには、なんかその、探索に特化したメソッドがいくつかあって、で、なんか途中で探索を、あの、打ち切ったりとか、 1個上に上がってまた続けてくださいみたいな、そういう仕組みが用意されたりして、結構便利ですね。
@potato4d
確かに。結構その辺、自分で書くってなると、こう、ダーティーな処理を書かざるを得なくなりがちな部分はなんで、そこまで含めて面倒見てくれるのはめっちゃ良さそうですね。 ありがとうございます。 なんかもう少し広い意味で言うと、あのー、tsモフ自体、その、っとー、ま、これはテイクスクリプトコンパイラapiも一緒かなと思うんですけど、なんかaseで、tsのastで処理するみたいなアプローチに
4. ts-morph を使ってよかったこと
@potato4d
なるかなと思うんですけど、なんか今回このアプローチとったことによるなんか良さみたいなのもあったらそこも聞きたいなとか思ってるんですけど、なんかお2方あったりしますか。
@potato4d
あー、多いですね。
@kazushikonosu
使うことが多いかなと思うんですけど、依存関係のグラフを元にこう、ファイルを編集したりするみたいなのは、タイプスクリプトのatじゃないとできないと思うので、
@potato4d
これしかなかったみたいな気は。確かになんかesintだともうこのファイル単位でのあれしか見れないんで、 こう、そういうことやろうと思うと、なんでしょう、気合でどっかに情報を一時的に保存して自分で組み立てるみたいな感じのことを やる。なんか途方もない作業が必要になりそうですし、なんか、そういうところがちゃんとこう、あの、機能として提供されているっていうのは、
@potato4d
こう、現実的なアプローチになるんで よさそうですね。多分、あれですよね、イエスリントとインポート文とかを、こう、自分で見て、頑張って依存か解決してやるみたいなことしかできないんですよね、おそらく
@kazushikonosu
ですよね。そ、そうなっちゃうと思うので、それもほんとにともないさ。
@potato4d
そうなると、なんか、それこそ、あれですよね、既存のソリューションが、まライブラリー、それこそtsプルーンであったら、tsプルーンであるのであれば、もうそれ使う方がコスパがいいみたいな話になってきてしまいそうな ところでもあるんで、こういう風にちゃんと機能として提供されてるんでもない、作業にならないっていうのはよさそうですね。あかいとさんの方は何かありますか。
@odiak
まそうですね。僕もあの、同じく依存関係をあのたれるっていうのはすごくありがたかったですね。 で、あとは、えっとーまタイプスクリプトならではのポイントとして、っと、型情報を使えることっていうのが、結構嬉しくて、 ま、今回、ルーティングの解析に、ま、型情報をちょっと使って、うまく組み込んでいます。
@potato4d
なんか、具体的には、どんな感じで、型情報を活用。はい。
@odiak
ルート定義のパスの部分なんですかね、動的な文字列になることがあって、そこを解析するのに、型情報を使いました。 っと、ちょ、もう少し具体的に言うと、文字列テンプレートが使われることがあって、で、そこの型を見ると、なんか、その、例えば、文字列 リテラル型のユニオン
@odiak
が、あのー、文字列テンプレートに埋め込まれていた場合に、ま、その、全パターンを列挙したものを型から引っ張り出せるっていう、ちょっと 音声でうまく伝わるかわからないんですけど、そういうことをしています。
@kazushikonosu
これ、あれですよね、なんかこの、なんか文字列リテラルの中で肩が狭いやつって、なんかタイプスキップで名前ありますよね。
@potato4d
それで、なんて言うんでしたっけ。テンプレートリテラルのプレートリテ。
@kazushikonosu
そうそうそう、数字とかがある。
@potato4d
なんか普通にテンプレとリテラルタイプすな。
@odiak
そうですね、
@potato4d
あ、その、ルーキングの解析にか、情報が役に立ったっていう部分があったかなと思うんですけど、それってなんか具体的にどういうふうな感じで、こう、役に立ったんでしょう。
@odiak
ルート定義のパスの部分って、その、ただ、なんだろ、決まった文字列が入る場合 と、とー、ま、動的にテンプレートリテラル型を使った ような定義が入ってくる場合があるんですけど、その後者の場合に、ま、ソースコードを見るだけだと、どういうパスが実際に入ってくるのかっていうのはわからない。ちょっと
@odiak
解析するのが難しいんですけど、型情報を使うことで、ま、ここに、ファスのこの部分には任意の文字列が入りそうだなとか、ここにはその、決まった いくつかのパターンの文字列が入りそうだなとか、そういうのを方から抜き出すことができたので、ルートの解析にすごく役立ちました。
@potato4d
あ、なるほどね。 や、結構、あれっすね、あの、id、idとかの、こう、動的にあらゆるデータ、データベースにあるデータを引き引き回すために、こう、任意の値が入る感じのパスじゃなくて、なんか、いずれかのパスがユニオンで定義されていて、ま、どれどれかしら にアクセスできるみたいな型定義をしてる部分があって、ま、そこまで含めて、ちゃんとタイプの恩恵を受けて開発ができた、みたいな。そうですね、はい、なんですね。
5. ts-morph を使って悪かったこと
@kazushikonosu
そうですね。なんか、イエスリントンだったりとかだと、 フォーマットを維持したまま、また元のコードに戻すみたいなことも多分できると思うんですけど、タイプスクリプトのコンパイラapiはあんまりそういうことを対応してなくて、 でま、結果的に、そのtsボフで提供されてない機能を、よりこうひく薄いラッパーで操作すると、フォーマットが崩れてしまう
@kazushikonosu
みたいなのはありました。
@potato4d
最終的にフォーマットかけるみたいなアプローチするのであれば、まあ、一応、なんとかなれるとはいえ、まあ、そこが、こう、こだわりのあるというか、ま、な、なんかしらのフォーマットに沿って開発して、みたいな場合だと、どうしても崩れてしまうみたいなのは、 ま、ネックではあるっていう風なところですね。
@kazushikonosu
そうですね、なんか、大抵のサブは、フォーマットが、かけ直せば治るんですけど、あの、かの行と
@potato4d
消えてしまう。なるほど、
@kazushikonosu
カ行に意味がある時とかは、
@potato4d
なんか、コードベース上でしょ、処理を分けるために、意図的に、こう、処理を分けるというか、ま、挙動は変わらないが、家族性のために、意図的にか、あの、からを要してるみたいなところが、 バッサリ消えてしまうみたいなの、ちょっと不便かもしれないですね。
@kazushikonosu
ですね。なので、そのts毛布の提供してる関数で操作してるところはフォーマットが維持されるけど、実装されてない部分 について自分で実装を書くとフォーマットが崩れるみたいな、あんまりそうすると、じゃあもう最初から全部tscでタイプスケプトコンパイラapiで書いてもいいかなみたいな。
@potato4d
そうきました。なんかあれっすもんね、コンパイルipiって、シングルコートのデータ投げてもダブルコートで帰ってくるぐらいには 確か柔軟性がないというか、出力の柔軟性がないはずなんで、初めから使うならもうそこに関してはコンパイラapiが決めたやつを作ってもらって、 ま、後からフォーマッターで解決できるところだけ解決するっていうコンセプトにした方が、ま、一応一貫挙動の一貫性は担保される、みたいな
@odiak
感じなんですかね。
@kazushikonosu
あー、です。
@potato4d
ちょっと本題作れますけど、逆にts毛布って、その、環境の維持とかまでやってくれるんですか。
@kazushikonosu
あ、やってくれます。あの、多分、操作の方法が、トランスフォーマーapaみたいなのを使うのではなくて、各ノードに紐づいてるその行番号だったりとか、 その位置の情報を使って編集をするので。
@potato4d
あー、なるほど。されます。あ、コンパイラpi使うアプローチってなると、データかませてもう1回コンパイラapiに書き出させるみたいなんがありがちなアプローチに なるかなっていう印象がありますけど、そうじゃなくても、コンパラapiの持ってるそのastの解析だけ使っちゃって、実際のコードの削除とかの資料は自前で tsmf側が持ってるみたいな、そういう感じになるんですかね。
@kazushikonosu
そうです。内部リスよ。多分そんな感じになってましたので。ま、ソーマイペは使えないものなんだ。
@potato4d
いや、理解しました。結構頑張ってくれてますね。
@kazushikonosu
そうですね。なんかそのへ辺の編集の機能とかも、tsポフがこう外向けにはエクスポートしてくれてたらそれを使えたので、その辺が こう、外部に露出してないので、やっぱそういうところも
@potato4d
改善されたらいい。なんかts毛布だと痒いところに手が届かなかったりする時もあるが、まあこいつの機能だけは欲しいみたいなのはそこそこありそうですもんね。
@kazushikonosu
そうですね。もう少し抽象度の高いラッパーみたいなのが提供されてると、確かにまよりいいかなっていう風に
@potato4d
思いました。ありがとうございます。なんかいどうさんの方は。何かあったりしますか。
@odiak
はい、そうですね。あの、僕は、あの、ts、あ、コンパイラapiの方を使ってる時期が長かったんですけど、 ts毛布使ってみて思ったのが、コンパイラapiのapiと、ts毛布のapiが若干ずれてるというか、 tsスモーブの方が親切にうんとなんかapiを整理してくれてるのが、逆にちょっと混乱の元になったっていうことはありましたね。
@potato4d
具体的にはどんな感じで違う値さしてるんですか。
@odiak
的には。ちょっと具体的なところは忘れたんですけど、例えば、なんか ゲットネームノードみたいなのを呼ぶと、コンパイルapiとtsモードで微妙にその指してるものが違うみたいな、そういう状況がありましたね。
@potato4d
あー、なるほど。インターフェース自体は同じような形にしてくれてるが、戻ってくる値が違うんで、こう読む時に、コバラapiの行動を 使ったコードを読んで、読んだ後にtsmのよ方読むと混乱しやすい
@odiak
そうですね。なんか、例えば、なんかts毛布がそのノードを1枚、あん、アンラップしてくれてるみたいな、そういうのが、あ、ありがちという。あとは、まあ、ちょっとか、 あ、ちょっとこの方はおかしいぞみたいな。おかしいとまではいかないんですけど、ちょっと、 あのー、片付けがイマイチだなって思うところがあったりして。ま、若干未完成感はありますね。
@potato4d
あー、なるほど。なんか、型のイマイチの部分とかで、印象的だったところとかあったりしますか。
@odiak
っと、そうですね。な、カスタムタイプアサーションって言うのかな。っと、あ、カスタムタイプガードか。ノードの方を、 方というか、種類を判定する関数があるんですけど、それが、っとー、カスタムタイプガードになっていなくて。 で、まー、ちょっと自分でアサーションを書かないといけないっていうところがあったりして、そこに関してはちょっとプレリクを出して、で、文にマージしてもらうことができました。
@potato4d
おお、なるほどなるほど。なんかこう、あれですね、明示的に片付いてなくて、推論の結果が割と抽象度高めだったりして。うんうんうん。結構使う分には不便だった、みたいな。
@odiak
そうですね、はい。ま、ちょっとした修正で、あの、すごく使いやすくなる。
@potato4d
いいですね。ちょっとまあ、せっかくなんで、参考までに、あの、プルリクのurl、ション、ノートの方に貼っとこうかなと
@odiak
思います。はい、ありがとうございます。
@potato4d
なんか他にはあったりしました。
@odiak
あー、そうですね。ま、ちょっと細かいところなんですけど、ま、コンパイラapiは、ノードのなんかのオブジェクトに、ま、プロパティが生えてるプレーのオブジェクトなんですけど、 tsモブの方は、っと、プラスになっていて、で、ゲットほげほげとか、セットほげほげみたいな、メソッドを呼ぶ形のインターフェースになっていて、 ま、ちょっと、そこは、若干行けてないかなという印象はあります。
@potato4d
なんか、あれですね、むしろ、クラスで書かれたりしてる古めの資産を、こう、
@odiak
そうですね、まあ、その、なんだろうな、中に、 ま、継承環境をうまく使ったりとか、中に、色々オブジェクトを持ったりして、まあ、あの、使いやすいインターフェースを実現するために、プラスを使ってるって感じではあるんですけど。あー、はい。 ま、あと、コンパイラapiの方は、その、コンパイラに使われてるパートでもあるので、パフォーマンスを重視するために、プレーのオブジェクトになってるっていうのもあるかもしれないです。
@potato4d
なるほど。なんかこう、より使いやすさとかを、まあ、ブラックボックス的なインターフェイスも使いやすさを重視してくれているが、ま、そこがちょっといけてない感があるかな、みたいな、
@odiak
なんか、はい、そうですね。
@potato4d
行くみたいな感じですね。すいませ、 結構、あれですね、なんか、良かったところもありますけど、細かいところになると、まず気になるところもあるみたいなのが、2人ともに共通してるポイントな気はしますね。 まあ、でも、なんかあれですね、アクティブにプレクとかもましてくれてるみたいですし、なんかまだ、全然、こう、良くなってくれそうな気配はありますよね。
6. 次同じようなシチュエーションで使うか
@potato4d
あ、ここまで結構作ったものであったりだとか、ま、良かったこと、悪かったとこととか、色々話していったかなと思うんですけど、なんか、良ければ、ちょっと今日お聞きしたいなって思ってたのが、ま、ts毛布を今後も使うっていう選択肢とな、コンパイラーapiを使うっていう選択肢 あるのかなと思うんですけど、まあ、直接使うっていう選択肢もあるのかなと思うんですけど、 次、同じようなシチュエーションであったりだとか、ま、何かツールを作りたいみたいなシチュエーションが出た場合って、また、ts毛布使いそうですか。
@kazushikonosu
僕は、複雑なことをやるなら、もうコンパイラapiにも慣れてきたので、コンパイラapiを使おうかな。
@potato4d
こう、入りとしてはめっちゃ良かったから、まあ、これからは、コンパイラapi、ちょっと複雑でも、まあ、使っていけばいいかなみたいな感じですかね。
@kazushikonosu
そうですね。結構タイプスクリプトのバイラ周りってすごいとっつきにくい印象があったんですけど、ts毛布のおかげで すんなり入ることができたので、ライフスクリプトの入門編としてはすごい良かったなと思ってます。
@potato4d
なんかかいどうさんの方はどうですか。はい。
@odiak
僕は逆に、あの、今までずっと使ってたtsコンpapiをじゃなくて、今後はtsmpを使いたいなと思いましたね。なんだろうな、圧倒的に書きやすいので。 もしコンパイルapiの方触りたくなっても、tsmfの中にラップされてるので、 そっから触ればいいかなという印象ですね。僕は
@potato4d
確かに、なんかあれですね、あの、こう、普段から書いてて、コンパイライペあいかあい かきかれたからってスモで使いたいな、みたいなのと、まあ、せっかくだし、もっとこう、コンパイラピア使ってみるか、みたいなのは、なんかどっちの選択肢もありそうで いい感じ。
@odiak
視点が点が逆で面白いですね。
@potato4d
うんうんうんですね、 面白かった。でも、なんかむしろあれですよね、こうやってts毛布とかが使いやすいインターフェイスを提供してくれるからこそ、なんか、ま、もちろん色々制約はあると思うんですけど、本家とかも、本家のtscの方も、そんなにこう、 あのインターフェイスがその、まずっとそのままっていう話でもない可能性はあるとは思うんで、そういうところも
@potato4d
期待して両方見ていきたい感じはしますよね、逆流のというか。じゃあ、お2人とも結構長々と色々聞いてしまいましたけど、ありがとうございました。 では、クロージングいきたいと思います。というわけで今回は、ts毛布と社内通路の開発について話していきました。 lineのフロントエンド組織uitでは、このようなフロントエンドに関する、議論であったり、特定の日々行っております。
7. クロージング
@potato4d
これまでuitinsideで外部に出していた内容の中にはですね、社内勉強会などから始まったものもありますので、今後も、外部に出せる情報は、どんどん発信していきたいと思っておりま、 また、hpとキャストに関するご意見やご感想は、twitterのハッシュタグ、ハッシュuitアンダースコアインサイトにて受け付けております。ついていただいた内容に関しては、スタッフの方で呼ばせていただきますので、何かあればぜひぜひツイートしていただければなと思います。 というわけで、今回はts毛布についてでした。ありがとうございました。
@odiak
ありがとうございました。
@kazushikonosu
ありがとうございました。
