Java開発者にはJavaDocsがあり、UI開発者には何がありますか？
体系化されていないものを自動化するのは難しいため、長い間、この分野には価値のあるツールはありませんでした。 時間が経つにつれて、JavaDocに似たツールが登場し、同様の名前であるJSDocが登場しました。 彼の主な欠点には、特定のプロジェクトに常に適しているとは限らない、特定の方法でコードを書くことを彼に強制したという事実が含まれます。 コメントが豊富なためにコードが肥大化し、開発チームにとってコード自体の可読性が低下したことは注目に値します。
Reactの登場により、UI開発のすべてが変わりました。 すべてのインターフェイスが原子的な部分に分割され始め、そこから巨大なアプリケーションが組み立てられ始めました。各部分は分離され、必要なテストで覆われました。 各企業には独自のUIコンポーネントのライブラリがあり、開発者の間ではUIKitとも呼ばれます。
ただし、プログラム「Unified Frontal System」では独自のライブラリを開発しましたが、それを文書化する必要がありました。
私たちはドキュメントを書き始めましたが、手作業で準備するのは非常に面倒だとすぐに理解しました。 プロジェクト自体の開発に遅れをとりながら、ドキュメント作成に貴重な時間を費やしています。 このアイデアは、コードから直接ドキュメントを生成するために生まれたもので、新しいものではありませんが、試してみることにしました。 ReactとTypeScriptのプロジェクトがありました。 TypeScriptの不十分に文書化された機能を使用して、各コンポーネントに対して独自の生成を開始しました。 コンポーネントの各プロパティに関するすべてのコメントは、表示されるドキュメントの一部になりました。
どのようにしてこれを達成しましたか？
TypeScriptのルーツを深く掘り下げることはしませんでした。時間がかかりすぎます。 typedocを使用して、プロジェクト構造をjsonの形式で取得しました。この構造に従って、プロジェクトをミラーリングしますが、コンポーネント自体の説明は既に知っています。 ドキュメント自体に説明を簡単にロードするために、ミラー構造から説明を「プル」してページに表示する特別なコンポーネントを実装しました。 複雑に聞こえますが、実際には時計のように機能します。
もっともっと。 ドキュメント内の例を取得し、コードが記述されたコードのテキストを表示するためにコードをコピーしたくありませんでした。 例とこの例のコードの両方を表示する個別のコンポーネントを作成しました。 ミラー構造を使用して、サンプルとソースコード間の接続を実現することができました。
このソリューションを最大のGitHub共同開発ポータルに投稿したため、日常の業務でこのツールを使用できます。 投稿へのコメントでチャットできることを嬉しく思います。
つまり、ソリューションの改善に引き続き取り組んでいます：
- ライブ再読み込みを作成することにより、ドキュメント内の結果を確認するためにライブラリ全体が再構築されるのを待つ必要がなくなりました。
- JavaScriptのサポート：現在、多くのプロジェクトがプロジェクトでTypeScriptを使用していないことを理解しています。
- 設計の更新：ツールは禁欲的なように見えますが、これらはオープンソースの最初のステップであり、修正することをお約束します！