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
Copy file name to clipboardExpand all lines: src/posts/get-started.md
+20-95Lines changed: 20 additions & 95 deletions
Original file line number
Diff line number
Diff line change
@@ -3,8 +3,8 @@ title: Getting Started With Federated Modules
3
3
secondary_title: get up and running in 15 minutes
4
4
author: Jacob Ebey
5
5
date: 2020-03-29T16:04:26.000+00:00
6
-
---
7
6
7
+
---
8
8
# A Little Background
9
9
10
10
If you've worked as a developer long enough, you've ran into the inevitable problem of sharing components between teams. Let's be real here, how often does this lead to a good experience for anyone?
@@ -15,14 +15,13 @@ I think [Zack Jackson](https://indepth.dev/webpack-5-module-federation-a-game-ch
15
15
16
16
If you would like to learn more about Webpack Module Federation, you can head over to the [Learn More](/learn-more) page.
17
17
18
-
19
18
# What We Are Building
20
19
21
20
We are going to build out two separate Single Page Applications (SPA) that use Module Federation to share components during runtime.
22
21
23
22
`Application A` will contain a `SayHelloFromA` component that will be consumed by `Application B` while `Application B` will contain a `SayHelloFromB` component that will be consumed by `ApplicationA`. This looks like:
This architecture will allow each SPA to be developed and deployed independantly along with instantly recieving updates from other federated applications with zero deployments.
28
27
@@ -39,87 +38,27 @@ Start by creating a new project folder with the following `package.json` to allo
We will now create two folders for our SPAs to live in under a new `packages` directory called `application-a` and `application-b`, these will respectively contain the following `package.json` files:
From the root of the application, you should now be able to access your two SPAs on [http://localhost:3001](http://localhost:3001) and [http://localhost:3002](http://localhost:3002) when runing:
This specifies that `Application A` exposese it's App component to the world as a Federated Module called `SayHelloFromA`, while whenever you import from `application_b`, those modules should come from `Application B` at runtime.
@@ -201,27 +132,21 @@ We will do the same thing fro `Applicaiton B`, specifying that it exposes it's A
The last step before we can start to utilize the exposed components is to specify for the runtime where the Remote Entries for the Containers you wish to consume are located. We do this by simply adding a script tag to the HTML template of the remotes you wish to consume.
{`<head> <!-- The remote entry for Application A --> <script src="http://localhost:3001/remoteEntry.js"></script> </head>`}
225
150
</SyntaxHighlighter>
226
151
227
152
The remote entry files are tiny mappings for webpack to resolve the individually imported modules without trasfering unnessesary info. They are also responsible for enabling the sharing of libraries that the packages use, in this case, when `Application A` requests `Application B`'s SayHelloFromB component, we do not send the React or ReactDOM over the wire as `Application A` already has a copy of it.
@@ -235,15 +160,15 @@ Starting with `Application A`, we can render the `SayHelloFromB` component like
0 commit comments