活動レビュー|OpenTiny: クロスフレームワーク フロントエンド コンポーネント ライブラリの技術実装と実践 (ppt コースウェアを含む)

OpenTiny: クロスフレームワーク フロントエンド コンポーネント ライブラリの技術的な実装と実践

HUAWEI CLOUD シニアフロントエンドエンジニア Kagol氏による技術説教

光を追うティーンエイジャーたちと一緒に未来に力を与えましょう

フロントエンドコンポーネントライブラリの使い方を教えてください~

全工程に乾物が詰まっており、

見逃せない素晴らしい!

活動背景

写真

今回、OpenTinyは北京工業大学のオフラインミートアップに参加し、誰もがオープンソースに参加する意義と価値を理解し、自分に合ったオープンソースプロジェクトを選択できるように、同校の学生を対象にオープンソース科学の普及活動を実施しました。オープンソースへの参加に興味がある。同時に、プロジェクトの現在の技術分野と組み合わせて、オープンソース技術を共有し、大学生が対面での技術交流を通じて現在の最先端技術の応用実践を理解し、理解が強化されるように支援します。フロントエンドの技術分野の知識。フロントエンド・オープンソース技術の導入+放課後課題により、オープンソース・フロントエンド技術への理解を強化し、現地合宿運営を通じて記憶力を強化し、オープンソース・フロントエンド技術の情報共有を実現します。大学生向けの技術プログラミング活動。

活動プロセス

(1) 活動スケジュール

13:30~14:00 チェックイン

14:00-14:10 主催者オープニング

14:10-14:40 トピック 1: オープンソースについて語る大物たち -- 大学生がオープンソースにどのように参加するか

14:40-15:10 トピック 2: データベースにおけるデータ構造とアルゴリズムの適用

15:10-15:40 トピック 3: Volcano の高度なスケジューリング機能によりクラウドネイティブ AI トレーニングが加速

15:40-16:10 トピック 4: クロスフレームワーク フロントエンド コンポーネント ライブラリの技術実装と実践

16:10-16:20 オープンな双方向コミュニケーション

16:20-17:20 トレーニングキャンプ -- グループ並行

イベントの詳細

Xiang Yu氏は基調講演「データベースにおけるデータ構造とアルゴリズムの応用」で、openGemini時系列データベースで使用されているデータ構造とアルゴリズムについて共有し、ツリー氏が重要な説明を行った。学校でデータ構造とアルゴリズムをしっかり学ぶことは非常に重要ですが、実際の製品やシナリオとの組み合わせが欠けており、パフォーマンスやアルゴリズムによるリソースの使用に重点を置く必要があると彼は考えています。Xiang Yu 氏は、「openGemini は 2019 年から進化しており、データ構造とアルゴリズムの最適化において多くの実践的な経験を蓄積してきました。学生はコミュニティに参加して、技術的な能力を学び、開発、向上させることができます。コミュニティは技術的な指導とサポートを提供します」と述べました。大学開発者向け 関連するコミュニティ開発トレーニング。

写真

Wang Yang 教師は、主にジョブ管理、高レベルのスケジューリング戦略とパフォーマンス、ドメイン フレームワークのサポート、リソース共有、ヘテロジニアス コンピューティングなどを含む、クラウド ネイティブ バッチ コンピューティング (HPC、ビッグ データ、AI) の開発の歴史と課題について共有しました。この課題では、Volcano のアーキテクチャ設計と機能実装を詳細に明らかにし、クラウドネイティブ AI トレーニング シナリオにおける Volcano の役割と価値を実証します。

写真

Zeng Lingka 先生は、フロントエンド フレームワークの 20 年にわたる開発の歴史を共有し、将来の課題に対処するために、非フレームワークのロジック層を抽出することによって一連のクロスフレームワーク コンポーネント設計アーキテクチャを考案した OpenTiny を導き出しました。フレームワークのアダプテーション層に相当するコンポーネントをレンダリングし追加することでクロスフレームワークを実現するこのアーキテクチャは、OpenTinyプロジェクトで実装され、多くの企業によって実現可能であることが検証されています。次に、TODO コンポーネントの具体的な例を通じて、レンダリングレス コンポーネント アーキテクチャを全員に理解してもらい、現場でクロスフレームワーク コンポーネント ライブラリの実現可能性を検証しました。 Vue/React マルチテクノロジー スタックでは、公開されている API が完全に一貫しているため、フレームワーク間のビジネス移行の問題が解決され、開発コストが節約され、真に未来志向です。

写真

OpenTiny メインコンテンツの共有

1. フレームワーク: 固定されたフロントエンド フレームワークはありません

フロントエンドフレームワークの開発経緯を紹介し、未来志向のコンポーネントアーキテクチャを実現する方法を解説

過去、現在、未来に応じて、フロントエンド フレームワークの開発は簡単に 3 つの段階に分けられます。jQuery 時代の第一段階、jQuery の最初のバージョンは 2006 年にリリースされました。当時、すでに Dojo、Prototype、ExtJS など、多くのフレームワークが覇権を争っていました。jQuery は、2006 年に開始された Sizzle セレクター エンジンに依存していました。 2009 年、便利なチェーンをプラス 従来の DOM 操作によってのみ圧倒的な優位性を獲得し、7 年間の jQuery 時代に突入しました。2014年頃まではAngular、React、Vueが次々に立ち上げられ、2016年には三つ巴の対立が形成され、フロントエンドの開発モデルもDOM運用からMVC/MVVMの時代に入り、DOM運用が削減されました仮想 DOM と diff アルゴリズムによって可能な限りフロントエンド アプリケーションのパフォーマンスを向上させるために、3 つの主要なフレームワークの時代が今日まで続いています。将来的には、Svelte や SolidJS などの新しいフレームワークが登場し、開発者の間でますます人気が高まるでしょう。フロントエンド コンポーネント ライブラリの開発者は、将来の課題にどう対処するかを考える必要があります。外部要因が使用できなくなったときにどうやって生き残るかということです。アーキテクチャからビジネスの継続性を確保するにはどうすればよいでしょうか? OpenTiny コンポーネント ライブラリがクロスフレームワーク コンポーネント アーキテクチャを考案しているのはこのためです。

写真

2. アーキテクチャ: クロスターミナル、クロスフレームワークコンポーネントのアーキテクチャを設計する

コンポーネント アーキテクチャの設計アイデアと概念を紹介します。

左側の図から、Vue コンポーネントはレンダリング テンプレート、ロジック スクリプト、コンポーネント スタイルの 3 つの部分に分割できることがわかります。コンポーネントが複数のレンダリング テンプレート セットを持つことができる場合、たとえば、さまざまなシーンや端末に対応するテンプレートがある場合、このコンポーネントはさまざまなシーンや端末に適応できます。ただし、これらのレンダリング テンプレートがロジック スクリプトを共有できる場合、コンポーネント API インターフェイスの統一性が保証されるため、ユーザーは一連のコードを記述するだけで済みます。特定のシナリオでは、コンポーネントのデフォルトのロジック スクリプトが要件を満たせない場合、ユーザーはコンポーネントを展開して指定し、カスタム ロジック スクリプトを使用することもできます。コンポーネントのスタイルは、シナリオや端末ごとに個別に設計でき、CSS可変技術により、コンポーネントのスタイルを動的に変更することができます。

右の図は、OpenTiny の設計コンセプトが「ビジネスとフレームワークの分離」であることを示しています。ここでのビジネスには、UI コンポーネントの実装ロジックだけでなく、アプリケーションのページ ロジックも含まれます。UI コンポーネントとページは両方ともコンポーネントであるためです。 Vueで。したがって、アーキテクチャの最下位層がビジネス ロジックの核となり、上位層でどのようなオープンソース フレームワークが使用されても、あらゆる変化に対応するために変更されない必要があります。外的要因によりVueもReactも使えなくなった場合には、他のフレームワークに移行することも可能です。

写真

3. テクノロジー: React フックとレンダリングレス コンポーネント

将来性のある設計アーキテクチャへの技術的アプローチを導入する

OpenTiny は、composition-api を使用して開発されています。Vue が公式に提供している TODO コンポーネントの例です。左側のコード ブロックは Vue 2.0 で記述され、右側のコード ブロックは Vue 3.0 で記述されています。どちらも同じコンポーネントと機能を実装しています。右の図からわかるように、コードの関連部分は同じ色で表されています。Vue2.0 はより分散していて乱雑ですが、Vue3.0 はより整然としていて整然としています。

写真

レンダリング コンポーネントを持たない別のテクノロジは、コンセプトと呼ぶ方が適切かもしれません。この記事も TODO コンポーネントであり、レンダリングせずに機能のみを実現するという考え方のため、コンポーネントの見た目は異なりますが、機能はまったく同じです。この記事で紹介されているソリューションは当時のテクノロジーによって制限されており、Vue のスコープ付きスロットを通じてのみ実現できました。

写真

これら 2 つのテクノロジを組み合わせたこれらのコードは、Vue 3.0 の TODO コンポーネントです。左側はコンポーネントのレンダリング テンプレート、右側はコンポーネントのロジック スクリプトです。私たちのアイデアは、setup メソッドによって返されるオブジェクトを分割することです。ロジック スクリプトを、レンダリングに必要なデータとメソッドを返すスタンドアロンのレンダリングレス ファイルに変換します。たとえば、ここでの todo.vue ファイルは 2 つに分割されており、1 つは単純化された todo.vue ファイルで、もう 1 つはすべてのコンポーネント ロジックを含む renderless.js スクリプト ファイルです。

写真

4. 戦闘: クロスターミナル、クロスフレームワークの TODO コンポーネントを構築する

技術解釈によるTODOコンポーネントの実践的な開発

この TODO コンポーネントは、実際には、Vue の公式コンポジション API の例と、前の Renderless 記事の例から来ています。ここで行う必要があるのは、これらの例を、さまざまなシナリオおよびさまざまな端末での TODO コンポーネントのプレゼンテーション形式にすることです。この TODO コンポーネントの実行効果を誰もが体験できるように、ここに 2 つのリンクがあります。1 つはオンライン デモの URL、もう 1 つはこのプロジェクトのソース コードです。デモ URL を開くと、ページが左右に分かれていることがわかります。左側は Vue、右側は React で実装されており、どちらの実装も同じコンポーネント ロジック コードを共有しています。

TODO コンポーネントのサンプル全体では、3 つの関数が実装されています。1 つ目の機能は、コンポーネントの PC 状態とモバイル状態の切り替えを実現することです。具体的なポイントは、2つのボタンを用意することです。PCボタンをクリックすると、コンポーネントはPC表示形式に切り替わります。モバイルボタンをクリックすると、コンポーネントはモバイル表示形式に切り替わります。切り替えプロセス中、コンポーネントのデータと入力ステータスは保持されます。同期中。2 番目の機能は、コンポーネントがカスタム レンダリング テンプレートをサポートしていることを認識することです。例えば、開発者はTODOコンポーネントのPC表示形式が業務シナリオに合っていないと感じ、自分なりに調整したいが、既存のコンポーネントの機能がそのまま残っているため、新たにコンポーネントを書き換えたくない。彼らの要件を満たします。3つ目の機能は、コンポーネントのRenderless機能の書き換えを実現することです。同様に、開発者は、この TODO コンポーネントの機能ではニーズを満たせないと感じ、独自の方法で調整したいと考えますが、このとき、既存のコンポーネントのロジックをオーバーライドする機能を提供する必要があります。

デモ:   AUI 3.0 POC デモ

ソースコード:   GitHub - kevinmoch/aui3-poc-demo: AUI 3.0 POC デモ - コンポジション API + レンダーレス + CSS 変数

写真

5. まとめ: 建築の影響

アーキテクチャの長所と短所を解釈する

利点: 1 つ目は、ビジネスとフレームワークの分離です。コンポーネント ライブラリ自体をオープン ソース フレームワークから分離することに加えて、アプリケーション開発者がビジネス コードをフレームワークから可能な限り分離するように導くこともできます。2 つ目は、マルチ端末適応のためのワンタイム エンコーディングであり、このアーキテクチャで開発されたコンポーネントは、レンダリングレス ロジックを再利用することで、マルチ端末コンポーネント開発の作業負荷を軽減できることは明らかです。3つ目は、フロントエンドの技術スタックの統合であり、このアーキテクチャは柔軟性、包括性、拡張性に優れているため、複数のフレームワーク、端末、トピックをカバーでき、最終的にはさまざまな分野での技術スタックの統合を促進します。将来の道でやります。

欠点: 非同期コンポーネント、読み込みが完了する前にコンポーネント メソッドを呼び出すことができない、クロスフレームワーク開発、フレームワークに大きな違いがある場合の再利用性が低い、Web 側のみ、Android と iOS をサポートしていない、さまざまな小さな機能はサポートしていないプログラム。

6. 授業後の実践:クロスエンドコンポーネントライブラリのTODOコンポーネントにToDo項目を全クリアする機能を追加

写真

操作マニュアル: Wiki - Gitee.com


以上が OpenTiny の全内容です。OpenTiny オープンソース プロジェクトを利用して、フロントエンド技術の議論や共有に参加していただければ幸いです。

アクティビティのフィードバック

活動以外にも、学生からは「学校情報を表示するためのWebアプリケーションを作りたいと考えていた学生Aさんですが、以前はjQueryの技術スタックを使っていたため、手書きのコンポーネントが多く、開発効率が高くなかった」などのフィードバックもいただきました。彼は、Vue テクノロジー スタック + OpenTiny コンポーネント ライブラリを開発に使用できることを希望していました。

また、生徒 B もフロントエンド フレームワークに非常に興味を持っており、教師が共有した後、DOM とは何か、MVVM フレームワークとは何か、およびその方法など、フロントエンドとフロントエンド フレームワークについて多くの知識を相談しました。データ変更後に対応するビューを実現します。

また、Web アプリケーション構築の基礎となるフロントエンドがアプリケーション全体の品質向上に重要な役割を果たすと信じている学生もいます。しかし、現時点ではほとんどの学生がフロントエンドについて深く理解していないため、学校でフロントエンドの知識を普及させ、フロントエンドについての学生の理解を深めるだけでなく、学生の動員も可能にすることが非常に必要です。フロントエンドに興味がある。フロントエンド知識の普及は、Web開発の基礎の理解、開発スキルの習得、アプリケーションの品質向上に役立つだけでなく、市場の需要の理解や就職後のアプリケーション開発効率の向上にも役立ちます。

OpenTinyについて

OpenTinyは、HUAWEI CLOUDが開発したエンタープライズレベルのコンポーネントライブラリソリューションで、PC/モバイルなどのマルチ端末に適応し、Vue2/Vue3/Angularマルチテクノロジースタックをカバーし、テーマ構成システム/ミドルバックグラウンドテンプレートなどの効率化を実現します。 /CLI コマンド ライン 開発者が Web アプリケーションを効率的に開発できるようにするツール。

主要なハイライト:

  1. 跨端跨框架: Renderless 非レンダリング コンポーネント設計アーキテクチャを使用するコード セットは、Vue2/Vue3、PC/モバイルを同時にサポートし、機能レベルのロジックのカスタマイズと完全なテンプレートの置換をサポートし、優れた柔軟性と強力な二次開発機能を備えています。
  2. 组件丰富: PC 側には 80 以上のコンポーネント、モバイル側には 30 以上のコンポーネントがあり、高頻度コンポーネントのテーブル、ツリー、選択などを含み、仮想スクロールが組み込まれており、ビッグ データ シナリオでのスムーズなエクスペリエンスを保証します。業界の一般的なコンポーネントに加えて、分割パネル分割器、IpAddress IP アドレス入力ボックス、カレンダー カレンダー、画像のトリミングなどの独自の機能コンポーネントも提供しています。
  3. 配置式组件: このコンポーネントは、ローコード プラットフォームに適したテンプレートと構成メソッドの両方をサポートしています。現在、チームは OpenTiny を内部のローコード プラットフォームに統合し、ローコード プラットフォーム向けに多くの最適化を行っています。
  4. 周边生态齐全: Angular + TypeScript に基づく TinyNG コンポーネント ライブラリ、10 以上の実用的な機能と 20 以上の典型的なページを備えた TinyPro ミッドバックグラウンド テンプレート、フロントエンド開発のプロセス全体をカバーする TinyCLI エンジニアリング ツール、および強力なオンライン テーマ設定プラットフォームを提供します。小さなテーマ

お問い合わせ:

おすすめ

転載: blog.csdn.net/OpenTiny/article/details/132056181