You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In Hydrogen architecture, client components are not imported directly in the browser, which means they are not included in the client bundle generated by Vite. However, we still need a mechanism to download client components from the browser on demand (from RSC responses).
Currenly, we rely on Vite's import.glob to discover client components in the client build and bundle a reference to them. This import.glob translates to a map of id: () => import('.../assets/xyz...'). The ids are provided in RSC responses, and are used to find the correct dynamic import for the component. Apart from that, import.glob also tracks each component's dependencies and downloads them in parallel when the component is requested (to avoid waterfall requests).
There are two problems with this approach:
We need to inform Hydrogen of every path where Vite should try to find client components. By default, that's the user project folder and Hydrogen itself (from node_modules). This is not a huge issue right now because there are not many 3P libraries out there that export client components but, as the RSC ecosystem matures, our users would need to add each of those dependencies to our plugin.
The import map included in the client bundle adds a reference to every component in the folders passed to import.glob regardless of wether the components are actually used or not. The references are not too big, but if there are many unused components this adds up in the client build.
Both problems are somewhat related. I think at some point we should run the server build first in order to discover the client components that are actually used and generate some kind of manifest file. This might not be possible because, currently, the server build depends on the client build (for the generated index.html), so perhaps we need an extra processing before building to generate this manifest.
Once we have a manifest or something that indicates all the client components that are used in the app, the client build should use this to generate the import map. Basically, instead of a generic import.glob('/path/**.*.client.jsx'), this would be replaced by specific components like {...import.glob('/path/C1.client.jsx'), ...import.glob('/path/C2.client.jsx')}.
The text was updated successfully, but these errors were encountered:
In Hydrogen architecture, client components are not imported directly in the browser, which means they are not included in the client bundle generated by Vite. However, we still need a mechanism to download client components from the browser on demand (from RSC responses).
Currenly, we rely on Vite's
import.glob
to discover client components in the client build and bundle a reference to them. Thisimport.glob
translates to a map ofid: () => import('.../assets/xyz...')
. The ids are provided in RSC responses, and are used to find the correct dynamic import for the component. Apart from that,import.glob
also tracks each component's dependencies and downloads them in parallel when the component is requested (to avoid waterfall requests).There are two problems with this approach:
import.glob
regardless of wether the components are actually used or not. The references are not too big, but if there are many unused components this adds up in the client build.Both problems are somewhat related. I think at some point we should run the server build first in order to discover the client components that are actually used and generate some kind of manifest file. This might not be possible because, currently, the server build depends on the client build (for the generated
index.html
), so perhaps we need an extra processing before building to generate this manifest.Once we have a manifest or something that indicates all the client components that are used in the app, the client build should use this to generate the import map. Basically, instead of a generic
import.glob('/path/**.*.client.jsx')
, this would be replaced by specific components like{...import.glob('/path/C1.client.jsx'), ...import.glob('/path/C2.client.jsx')}
.The text was updated successfully, but these errors were encountered: