コンポーネント ライブラリを、ビルド変数から完全に/独立して既にビルドされており、npm クライアントによって消費される準備ができている npm パッケージとして扱うのはどうですか?
ライブラリを、周囲のビルド環境と自然に多くの結合を持つある種の内部パッケージとして使用したくない場合は、おそらく従来の npm アプローチを採用する方が簡単です。そして、パッケージを公開したい場合は特に理にかなっています。インポートするアプリ プロジェクトでは、引き続きprocess.env.MY_VAR
. ライブラリ部分については、構成オブジェクトを渡すことをお勧めします。
process.env.MY_VAR
複数のコンポーネントを含むライブラリ全体にとって重要な場合は、パッケージの初期化手順から始めます。
import { init } from "my-comp-library"
const config = {
myVar: process.env.MY_VAR
}
const lib = init(config)
const MyComp = lib.myComp()
const App = () => <MyComp />
ライブラリ内の単一のコンポーネントにのみ関連する場合は、それを props として直接渡すことができます。
const App = () => <MyComp myVar={process.env.MY_VAR} />
MyAppComp
アプリでは、たとえば、冗長な初期化ロジックを回避するために、構成が既に含まれているラッパー コンポーネントを作成できますMyComp
。ここでの追加の利点は、ライブラリのパブリック API が変更された場合に、アプリ内でコードを変更する場所が 1 つだけになることです。
MyAppComp.js
アプリ プロジェクト内:
import { MyComp } from "my-comp-library"
export const MyAppComp = props => <MyComp myVar={process.env.MY_VAR} {...props} />
アプリとコンポーネント プロジェクトの独立したビルド管理により、結合が取り除かれ、保守が容易になります。