I.はじめに
この記事では、フロントエンド全体でのインビボモールのマルチエンド統一された探索と実践を紹介します。
マルチエンドの価値、マルチエンドの統合を行う必要がある理由、マルチエンドのビジネスニーズを満たす方法、実践と革新から、マルチエンドの統合で行ったことを簡潔かつ簡単に説明できます。
2.マルチエンド探索がvivoモールにもたらす価値
マルチエンドの価値は、技術アーキテクチャのアップグレードと人的資源の解放という2つの側面に反映されます。
1.技術アーキテクチャの包括的なアップグレード
から
に
テクニカルアーキテクチャソリューションの統合を実現しました。統合により、開発コストとメンテナンスコストが大幅に削減されます。同時に、それは高い再利用と高い効率を持っています。
2.多くの人的資源を解放する
技術アーキテクチャスキームの統合は、ビジネスの水平的拡大のための強力な技術サポートと達成可能な保証を提供します。
下の図は、新しい技術アーキテクチャを使用した後の開発要員入力の比率です。
上の図からわかるように、技術アーキテクチャのアップグレードにより、かなりの開発リソースが解放されました。リリースされた開発リソースにもっと価値のあることをさせましょう。
3つ目は、なぜマルチエンド統合を行う必要があるのか
質問があるかもしれませんが、マルチエンド統合とは何ですか？
ここで私は最初に要点を売ります、団結については話さないで、それについてもっと話しましょう。マルチエンドとは何ですか？誰でも話せると思います。
マルチターミナルに関して、私は次のように絵を描きました：
上の図からわかるように、オフライン、pc、wap、APP、WeChat公式アカウント、WeChatアップルトなど、それぞれを端末と呼ぶことができます。マルチエンドの意味を理解した今、マルチエンドの統合を振り返ります。
完全なマルチターミナル統合には、次の側面の統合を含める必要があります
- 大きなフロントエンドのマルチエンド統合[フロントエンド+クライアント]
- サーバーのマルチエンド統合
- ビジネスのマルチターミナル統合
ここでは、フロントエンドのマルチエンド統合についてのみ説明します。
PCブラウザーから、モバイルブラウザー、APP埋め込み、さまざまな小さなプログラム、サーバーとクライアントまで。繁栄する生態学は、百の思想の学校が争い、百の花が咲くようなものです。しかし、繁栄の背後では、フロントエンドエンジニアへの課題は日々増加しています。
私たちはますます多くの端末を引き受けており、小さなプログラムや高速アプリケーションなどの新しい端末が出現し続けています。フロントエンドエンジニアは、次の人形の罠に陥ります。
- 既存のコードと新しいコードは、新しいエンド開発シナリオに適合させる必要があります
- 新しい最終開発シナリオに適合したコードが既存のコードになります
- 既存のコードと新しいコードは、新しいエンド開発シナリオに適合させる必要があります
- サイクル...
私たちはこの問題を解決し、現在の終わりと将来の終わりをカバーできる一連の技術アーキテクチャスキーム[コード]を達成したいと考えています。
素人の言葉で言えば、次の図に示す機能を実現したいと考えています。
フロントエンド開発のこのコンテキストでは、マルチエンドユニファイドが出現します。これはフロントエンドの将来のトレンドであり、上記の人形の罠を解決するための良い薬でもあります。
第四に、マルチターミナルビジネスの増大する需要にどのように対応するか
時間の経過とともに、小さな端末のビジネス、特にインビボモールのWeChat小さなプログラムが徐々に重要になっています。
ビジネス側の要件には、次の2つのポイントがあります。
最初のポイント：既存のvivoモールWeChatアップルトのコア機能をモールH5機能と一致させます。
2番目のポイント：バージョンの後続の反復、小型端末、およびH5端末が同期されます。
現実は次のとおりです。既存のモールWeChatアップルト、そのバージョンの反復はすでにモールH5バージョンの背後にあります。
ミニプログラムの新旧バージョンの購入プロセスビデオを比較して、誰もがより直感的に体験できるようにします。
オールドモールミニプログラム：ビデオ>>
ニューモールミニプログラム：ビデオ>>
上記の2つのビデオから、この2つの違いを見ることができ、私たちが直面している課題は非常に大きいです。
ビジネス側の要件に応じて、上記の2つのポイントを解決し、1つのポイントを追加すると、以下に示すように、合計3つのポイントがあります。
最初のポイント：最短時間で、モールH5の基本的な機能とプロセスがWeChatアップルトに実装されます
2番目のポイント：後続のミニプログラムとH5バージョンの機能が同期されたときに高い再利用と効率を達成すること。
- 3番目のポイント：将来の他のビジネスシナリオの実装を事前に検討し、スケーラビリティとマルチターミナルの再利用をうまく実行します。
ビジネス主導で、技術調査、デモ検証、mvp検証を実施しました。最後に、包括的な検討の下で、上記の2つの問題を解決するために、ユニアプリマルチターミナルアーキテクチャが採用されました。
ここで言及すると、優れたビジネス主導モデルは、おおよそ次の図に示すとおりです。
技術の最適化と変化を促進する事業を通じて、繰り返し適用の過程で、改善のためのリアルタイムのフィードバック、そして最終的に事業に戻る。この過程で、テクノロジーとビジネスは良性の閉ループを形成しました。
今。残りは練習することです。
5.私たちが行った実践と革新
有名なことわざは次のようになります：練習は真実をテストするための唯一の基準です。勝者の背後には、あなたが見ることのできない努力と粘り強さがあります。
1.練習
実践の過程で、以下にリストされているように、考慮すべき多くの要因があります。
- 既存の小さなプログラムのネイティブコードをマルチターミナルプロジェクトの記述に変換して、変換されたコードが読み取り可能で制御可能であることを確認する方法。
- 既存のアップルトの機能ロジックの一部を完全に保持する必要があります。ネイティブのapiやアップルトのロジックでさえ、これらをマルチターミナルプロジェクトとどのように共存させることができますか？
- マルチターミナルプロジェクトでH5コードロジックを最大限に再利用する方法。
- H5のさまざまなコンポーネント、設計パターン、エンジニアリング、およびツール手法をマルチターミナルプロジェクトにエレガントに適応させる方法。
- などなど...
では、これらの要因にどのように対処するのでしょうか。
以下に示すように、画像を使用して全体を要約できます。
これらの要因に対処する方法は次のとおりです。
2.コード変換
既存のミニプログラムのネイティブコードをマルチターミナルプロジェクトの書き込みに変換して、変換されたコードが読み取り可能で制御可能であることを確認するにはどうすればよいですか？
オープンソースコンバータのminiprogram-to-uniappを使用して変換を行い、変換プロセス中に不一致の問題を手動で解決します。解決策はとてもシンプルで気取らないです。誰もが解決策は簡単だと思うかもしれませんが、このソリューションを選択した後、オープンソースコンバーターの作成者とのWeChat交換を含む詳細な評価を行いました。作者とのコミュニケーションの過程で、コンバーターの過去、現在、未来を知り、その状況下では、これが適切で正しい解決策でした。
3.コードの共存
既存のアップルトの機能ロジックの一部は、ネイティブapiやアップルトのロジックでさえもそのまま保持する必要がありますが、これらをマルチターミナルプロジェクトとどのように共存させることができますか？
次の図に示すように、プロジェクトの合理的なカタログ分割によって自然な分離を実現します。
複数の端末とまだ互換性のないいくつかのコードをplatformsディレクトリに配置します。同時に、条件付きコンパイルを使用して、マルチターミナルに変換できないプラットフォームを分離します。以下に示すように：
4.h5の多重化と適応
再利用とは怠惰な言葉です。直接再利用できる場合は、断固として再利用してください。H5との整合性が高くなるように二次調整を行わないでください。
適応とは、変更に適応することです。H5コードを変更する必要はありません。必要なのは、H5ルーティング、一部の互換性のないコンポーネントの適応、さらにはウィンドウへの適応など、それらの適応レイヤーを作成することだけです。場所は大丈夫です。
上で紹介した解決策から、これらの要因に対処するための核となる秘密は次の2つの文であることがわかります。
最初の文：地域の状況に合わせて対策を調整し、バランスを見つけます。
2番目の文：再利用を改善し、変更を減らします。
5.イノベーション
このようなことわざがあります：偉大さは普通に考えられています。ここに置いて、別の言い方をしましょう。つまり 、イノベーションは実際に繁殖します。
実践の過程で、私たちは多くの問題を解決しました。問題を解決する過程で、私たちはいくつかの幸せな革新を行いました。
- vuexイノベーション
この革新は問題から生じており、その背景は次のとおりです。
モールH5の製品詳細ページでは、vuexを使用してデータを管理しています。vuexをミニプログラムの製品詳細ページに移動すると、次のアニメーションに示すような現象が発生します。
上記のアニメーションから、vuexを使用する場合、製品Aの詳細ページから製品Bをクリックして、Bの製品詳細ページに入ることがわかります。このとき、左上隅をクリックしてAの商品詳細ページに戻ると、この時点で商品詳細ページが商品Bに変わっている、つまり商品Aのデータがなくなっていることがわかります。
これは非常に大きな問題です。調査の結果、理由は次のとおりです。
vuexのデフォルトの名前名は1であり、名前名を自動的に追加することはできません。アップルトページのデータ管理にvuexを使用する場合、アップルトページのデータメカニズムにより、クリックして戻ると、ページデータは同じvuexデータを使用するため、上記の現象が発生します。
ここで、onShowのライフサイクルでは、データを更新することで問題が解決すると言う人がいるかもしれません。実際にはそうではありません。このシナリオでは、データを更新することは非常に不合理です。
それで、それをどのように解決するのですか？
vuexを使用した後、同じページを複数回入力すると、アップルトページデータの表示に問題が発生することがわかっています。その後、グループは、包括的な計量の後、vuexの使用を継続し、vuexに適応層を追加することでこの問題を解決することを決定しました。
その後、グループで話し合いを行い、総合的なバランスを取りながら、引き続きvuexを使用することを決定しました。この問題は、vuexに適応レイヤーを追加することで解決されます。
まず、vuexにアダプテーションレイヤーを追加して上記の操作を行った後、どうなるか見てみましょう。
以下のアニメーションに示すように：
上記のアニメーションから、vuexに適応レイヤーを追加した後、それを見つけることができます。同じページを複数回入力して戻ると、vuexを使用した後、小さなプログラムページデータの表示の問題を正常に解決しました。
この問題をどのように解決しましたか？
コアソリューション：vuexに名前名の自動拡張と自動キャンセルをサポートさせることで、よりインテリジェントなデータフロー管理ソリューションを実現できます。
コアアーキテクチャ図は次のとおりです
ストアに名前名を自動的に生成することにより、同じページが複数回入力された後でも、各ページのデータが確実に保持されます。ページが戻ると、親コンポーネントの名前付けを動的に収集することにより、親コンポーネントと子コンポーネントの名前付けの関連付けが完了します。
上記の技術的解決策を通じて、vuexを小さなプログラムで使用したときに存在していた問題を解決しました。ここでは、コアアーキテクチャスキームが示されているため、具体的な実装については詳しく説明しません。
6.イノベーションの分離
この革新は問題から生じており、その背景は次のとおりです。
現在、共通、スパイク、およびグループの製品詳細ページがあり、後で他の製品詳細ページがあります。これらの詳細ページでビジネスコンポーネントを再利用するにはどうすればよいですか？
上記の問題に直面して、誰もが次の考えを持つことになります。
-
ページが異なれば、ビジネスコンポーネントのデータ処理も異なります
-
ページが異なれば、ビジネスコンポーネントの埋め込みポイントも異なります
- ページが異なると、ビジネスコンポーネントに特定のインターフェイス要求がある場合があります
上記の考えは、誰もがそれを見るべきでした。ビジネスコンポーネント自体を再利用することは非常に難しいことであり、完全に分離したい場合はさらに困難です。
では、どうすれば可能な限り分離するのでしょうか。
私たちは次のことをしました：
- 上流の埋没点の統一を確実にし、コンポーネントレベルで埋没点を設計することにより埋没点の統一を実現します。
- コンポーネントレベルでは、特定のインターフェイスに対して条件付きの判断が行われます。
- ビジネスコンポーネントのデータは、ソースデータと派生データに分解されます。ソースデータはvuexレベルで一貫しており、派生データは実際の状況に応じてビジネスコンポーネントに適応されます。
- vuexを刷新して、ビジネスコンポーネントとページ間の通信を完全に分離すると、ビジネスコンポーネントはページのvuex名前を知る必要がなくなります。
モールプロジェクトを開発した学生は、選択した爆弾レイヤーのロジックが非常に複雑であることを知っておく必要があります。ここでは、選択した爆弾レイヤーのビジネスコンポーネントを例として取り上げ、ビジネスコンポーネントの再利用方法を説明します。
以下は、再利用された選択された爆弾層コンポーネントの構成です。
├── components
│ ├── sku-number
│ ├── sku-product
│ ├── sku-service
│ ├── sku-spec
│ └── ...
├── index.js
├── index.scss
├── index.vue
├── mutation-types.js
└── track.js選択した爆弾レイヤーコンポーネントのデータをソースデータと派生データに分割します。ソースデータは、次の図に示すように、vuexレベルで統合されます。
詳細ページごとにvuexを記述し、同時に同じ部分をcommon-detailに抽出します。その後、vuexで処理して、異なるページから提供されたソースデータが同じであることを確認します。これらのソースデータは、ビジネスコンポーネントに渡されます。
次のコードに示すように：
// 这是已选弹层业务组件
// 通过 @vivo/smartx 解耦组件和页面的通信
import { mapState, mapGetters, mapMutations, mapActions } from '@vivo/smartx'
// 获取源数据
computed: {
...mapState([
'spuInfo',
'skuInfo'
]),
...mapGetters([
'price',
'pageType'
]),
}
methods: {
fn() {
// 策略模式
}
}上記の処理により、同様のビジネスコンポーネントを異なるページから適切に分離できるため、コードの再利用性、保守性、およびスケーラビリティが向上します。
ビジネスコンポーネントを分離するという考え方は、次のとおりです。
データとビューを意図的に完全に分離する必要はありません。ソースデータと派生データを使用して、変更されたデータと変更されていないデータのバランスを取り、自己開発の@ vivo / smartxを使用して、変更がアイランドになり、変更がアイランドになります。孤立した島。
すべての革新はテストであり、それは常に不注意にあなたに困難をもたらし、それからあなたに自分自身を突破させて、より良いものを作り出すことを強制します。
最後に、vivoの公式モールのマルチターミナルWeChatミニプログラムが開始されました。あなたはそれを体験するためにvivo公式ストアをクリックすることができます。
6、まとめ
この記事では、WeChat applets invivoモールのマルチエンド統一道路を一緒にレビューしました。ビジネスニーズ、存在価値、技術的実践、革新に至るまで、私たちはテクノロジーを使用してマルチエンドロードをよりスムーズにすることを望んでいます。
Vivo公式ウェブサイトモールフロントエンドチーム