9 つの Vue3 コンポーネント ライブラリを通して、フロントエンドの人気トレンドを見てみましょう。

TypeScript

人気度: 100%
この人気の傾向は必然となり、TS に関連したインタビューがますます増えています。

rollbar は異常監視プラットフォームです。2018 年、rollbar はフロントエンド プロジェクトの上位 10 種類のエラーをカウントしました:

ここでのエラーの多くは空または未定義です。 TypeScript を使用すると、これらのエラーを簡単に回避できます。

TypeScriptを使用すると、関連するエラーの 80% を回避できますが、もちろんanyScriptでは回避できません。 。

さらに、TypeScriptには、IDE のスマート プロンプト、プロジェクトのメンテナンスの容易さなど、それ以上の利点があります。まだ TS を使用したことがない場合は、今すぐ試してみることをお勧めします。

Monorepo

人気: 55%

vue、Reac、Babelなどを含む 詳細Monorepo

##Monorepo を使用し始めているプロジェクトが増えています。これは、すべてのコードを 1 つのコードにまとめることを意味します。 プロジェクト管理倉庫での戦略。

依存関係管理
• : 依存関係が共有され、すべてのコードが 1 つのウェアハウスにあります。バージョン管理がとても便利です。
コードの再利用
• : すべてのコードは 1 つのウェアハウスにあり、さまざまなプロジェクトに共通するビジネス コンポーネントやツールを簡単に抽出し、TypeScript を通じてコード内で参照することができます。
一貫性
• : すべてのコードが 1 つのウェアハウスにあるため、コードの品質基準と統一されたスタイルが容易になります。
透明性
• : すべてのコードは誰でも見ることができるため、チーム間での共同作業や貢献が容易になります。

パフォーマンス
• : ますます多くのコード、Git、IDEツールこのようにどんどん行き詰まってしまいます。
権限
• : ファイル権限の管理はより困難になります。Gitディレクトリには権限管理システムが組み込まれていません。プロジェクト全体を区別する方法はありません。どのプロジェクトが特定の部門に公開されているか、一部の部門は閉鎖されています。
学習コスト
• : 新人の場合、プロジェクトが大きくなるにつれて当然学習コストも高くなります。
Monorepo は決して特効薬ではなく、Monorepo 戦略は完璧ではありませんが、いくつかの側面では、一部のプロジェクトのメンテナンスと開発のエクスペリエンスを解決します。

プロジェクトに複数のウェアハウスが関連付けられている場合、または

を使用して複数のウェアハウスを管理している場合は、Monorepoを試すことができます。

には

を使用する55%があり、残りは45%ですどのようなパッケージ管理ツールが使用されているかわかりません。最も重要なことは、lockファイルがないということです。これは本当に理解できません。オープンソース プロジェクトとして、次のような必要はありませんか?統合された依存関係のバージョン?

第一世代の
• npm

  では、依存関係が繰り返しインストールされます。 A は C に依存しており、B も C に依存しているため、C は 2 回インストールされます。 (2 回ダウンロードではなく、2 回インストールされます。ローカル キャッシュにダウンロードされます。)

ツリー構造なので、
• node_modules

  のネスト レベル深すぎます (ファイル パスが長すぎると問題が発生します)

#モジュール インスタンスは共有できません。たとえば、React には内部変数がいくつかありますが、2 つの異なるパッケージで導入された React は同じモジュール インスタンスではないため、内部変数を共有できず、予期しないバグが発生することがあります。

とyarnから始まり、どちらもフラット経由で提供されます上記の問題を解決するための依存関係アプローチ。すべての依存関係は

ディレクトリにフラット化されており、深い入れ子関係はなくなりました。このようにして、新しいパッケージをインストールするとき、node requireメカニズムに従って、上位のnode_modulesを検索し続けます。同じバージョンのパッケージが見つかった場合、それは解決済み 多数のパッケージを繰り返しインストールする問題と、依存関係のレベルがそれほど深くない問題。しかし同時に、これは新たな問題ももたらします

• package.json

  に書かれていないゴースト依存パッケージも同様ですプロジェクトで使用できます。

• クローンの依存関係 - たとえば、A と B は両方とも C に依存しますが、依存するバージョンCは異なり、1 つは1.0.0、もう 1 つは2.0.0です。このとき、package.json内の A と B の位置に応じて、使用されるCのバージョンは1.0.0または2.0 .0 になります。 ＃＃＃ バージョン。

• タイル化してインストールを削減しても時間は節約されません。アルゴリズムのせいで、実際には時間が増加します。

npm v5/yarn

node_modulesUncertain を解決するためのlockファイルが導入されています設置時の要因。これにより、何度インストールしてもnode_modulesの構造を同じにすることができます。

yarn v2 PnP

yarnの 2.x バージョンは、Plug'n'Play (PnP) の起動に重点を置いています。ゼロ インストール モードでは、node_modulesが放棄され、依存関係の信頼性がさらに確保され、ビルド速度も大幅に向上します。

yarn 2.xnode_modulesを削除し、モジュールをすばやくインストールしてロードします。すべての npm モジュールは、複数の依存関係を避けるためにグローバル キャッシュ ディレクトリに保存されます。モード 依存関係は促進されず、ゴースト依存関係は回避されます。

resolverは、既存の Node エコシステムの外にあり、互換性が低いNode requireメソッドを処理します。

pnpm

pnpmには、高速インストール、ディスク領域の節約、優れたセキュリティという利点があります。その外観は問題を解決するためでもありますnpmとyarnに関する問題。

pnpmは、ハード リンクとシンボリック リンクを組み合わせて、yarnとnpmの問題を解決します。

• ハード リンク: ハード リンクはソース ファイルのコピーとして理解でき、pnpmはプロジェクトをグローバル ## に保存します。 #storenode_modulesファイルへのハード リンク。ハード リンクを使用すると、さまざまなプロジェクトがグローバルstoreから同じ依存関係を見つけることができるため、ディスク領域が大幅に節約されます。
ソフト リンク
• : ソフト リンクはショートカットとして理解できます。pnpm依存関係を参照する場合は、シンボリック リンクを使用して、対応するディスク ディレクトリ (. pnpm) 。
たとえば、A は B に依存しています。A の下には

はありませんが、ソフト リンクがあります。実際の実ファイルは、.pnpmの対応するA@1.0.0/node_modules/Aディレクトリにあり、グローバルstoreにハード リンクされています。B の依存関係は

に存在します。そして、A が依存する B は、上のアドレス
(B --> ../../B@1.0.0/node_modules/) へのソフト リンクを使用します。 B

node_modules ├── A --> .pnpm/A@1.0.0/node_modules/A └── .pnpm ├── B@1.0.0 │ └── node_modules │ └── B ==> <store> /B └── A@1.0.0 └── node_modules ├── B --> ../../B@1.0.0/node_modules/B └── A ==> <store> /A

-->

はソフト リンクを表し、==>>はハード リンクを表します

構造を使用する利点は、実際に依存関係にあるパッケージのみにアクセスできることです。これにより、ゴースト依存関係の問題が非常によく解決されます。さらに、依存関係は常にstoreディレクトリ内のハード リンクであるため、同じ依存関係は 1 回だけインストールされ、複数の依存関係の問題も解決されます。2. もちろん、

にもいくつかの制限があります。

pnpm-lock.yaml
• とpackage-lock.jsonは一貫性がなく、互換性がありません。一部のシナリオは互換性がありません (
Electron
• など)。さまざまなアプリケーションの依存関係は同じファイルにハード リンクされているため、依存ファイルを直接変更することはできません。変更しないと、他のプロジェクトに影響を及ぼします。また、インストール構造が異なるため、オリジナルの
patch-package
• やその他のツールは使用できません。
まださまざまな問題はあるものの、全体的には欠陥は隠されていません。

は、ロック ファイルを使用すると仮定した場合、パッケージ マネージャーのマネージャーとして理解できます。ni実行前に、yarn.lock/pnpm-lock.yaml/package-lock.jsonを検出して、現在のパッケージマネージャーにアクセスし、適切なコマンドを実行します。

cnpmとnpmおよびyarnの最大の違いは、生成されるnode_modulesです。ディレクトリ構造が異なるため、シナリオによっては問題が発生する可能性があります。さらに、lockファイルは生成されません。ただし、cnpmはnode_modulesのディレクトリ構造を明確に保つため、ネスト モードとフラット モードの間のバランスが取れていると言えます。

store

に加えて、グローバルに 1 回だけインストールされるようにするため、ソフト接続## もあります。 # インストールが繰り返されないようにします。もう 1 つは、同じ依存関係の異なるバージョンをインストールする場合、異なる部分のみが再保存されることです。

どのパッケージ管理ツールを使用する場合でも、バージョン更新中にlockファイルを追加して依存関係をアップグレードする必要があります。より良いセキュリティのために。

esbuild

人気: 89%

esbuildはgojavascript および typescript言語で書かれたパッケージ化ツールは、webpackよりも100倍以上高速です。

vite、webpack、Rollupなど、パッケージ化ツールは異なりますが、最終的にはesbuild# が使用されます # ＃ パック。役に立たないvuetifyが 1 つだけありますが、vuetifyはまだ正式にリリースされていないため、後で変更される可能性があります。

ESM標準はますます普及するため、対応するツール チェーンもますます普及するでしょう。

vite は厳密にはパッケージング ツールではなく、フロントエンド ビルド ツールであり、実際にはパッケージ化に Rollup と esbuild を使用します。

SVG アイコン

人気度: 55%

アイコン フォントについて不具合について、このインライン SVG とアイコン フォントの記事を読むことができます。主な側面は次のとおりです。

• ブラウザはアンチエイリアス最適化のためにテキストとして処理しますが、得られる効果が期待したほど鮮明ではない場合があります。特に、システムが異なると、テキストのアンチエイリアシング アルゴリズムが異なると、表示効果が異なる場合があります。

• アイコン フォントフォントとして、表示されるアイコンのサイズと位置はfont-sizeの影響を受ける可能性があります。 、line-height、word-spacing、およびその他の CSS プロパティ。Iconが配置されているコンテナのCSSスタイルは、Iconの位置に影響を与える可能性があり、調整が不便になります。

#使いにくいです。まず、数百のアイコンを含む
• Icon Font

  をロードしても、そのうちのいくつかしか使用しないと、ロード時間が無駄になります。また、独自のアイコン フォントを作成し、複数のアイコン フォントで使用されているアイコンを 1 つのフォントに統合することも非常に不便です。

ブラウザのサポートを最大限に高めるために、少なくとも 4 つの異なるタイプのフォント ファイルが提供される場合があります。
• TTF

  、WOFF、EOT、および SVG 形式を使用して定義されたフォントが含まれます。

ネットワーク遅延により、
• Icon

  は最初にstringをロードします。

の利点は、コンポーネント ドキュメント

の説明を使用して、完全にオフラインで使用できます。必要はありません。 CDN からダウンロードするには、ネットワークの問題によりフォント ファイルとアイコンが正方形に表示されません。また、フォント ファイルをローカルに展開する必要はありません。
SVG はローエンド デバイスでの鮮明度が高くなります。
マルチカラーアイコンをサポートします。
スタイルをオーバーライドすることなく、組み込みアイコンを置き換えるための API をさらに提供できます。

互換性などの欠点。 (IE: 何を?)もちろん、全体として、

はパフォーマンスにそれほど大きな影響を与えません。たぶんそれが人気がない理由ですか？

8,

私は依然として前処理言語を使用して記述していましたが、最終的にそれをCSS var

W3C仕様の方が明らかに優れています。しかし、現時点では、多くの前処理言語関数やその他の関数はネイティブで十分にサポートされていません。したがって、前処理言語は依然として必要です。

元のアドレス: https://juejin.cn/post/7092766235380678687

著者: ARRON

(学習ビデオ共有:

webフロントエンド開発

基本的なプログラミング ビデオ)