feat(babel-plugin): add initial draft by asantos00 · Pull Request #32 · asantos00/website

asantos00 · 2021-03-12T17:52:22Z

No description provided.

comoser · 2021-03-16T09:38:57Z

content/blog/handling-react-remote-modules-with-babel.md

+
+David is doing a great job documenting this whole process and architecture, and thus I'll not repeat myself here. [add-david-mfe-link]()
+
+As part of this initiative, we created a shared library (which works as any other MFE) and only contains the components that are shared across products. All of this lives on a single repo, and we're using Webpack's Module Federation to define this clear interface between products.


I'd probably introduce the MFE meaning before when you mention Micro-frontends. People may not read my articles, and thus wouldn't automatically associate that

comoser · 2021-03-16T09:39:45Z

content/blog/handling-react-remote-modules-with-babel.md

+However, some challenges came out of this, and one of them is the one I'm sharing here today.
+## The challenge
+
+We wanted to import components from a different MFE, and we wanted this to be _code-splitted_, meaning that it should only be loaded when it is needed. We'll refer to this components as **remote components** as they live in a different location.


refer to these --> not this

comoser · 2021-03-16T09:40:47Z

content/blog/handling-react-remote-modules-with-babel.md

+
+We wanted to import components from a different MFE, and we wanted this to be _code-splitted_, meaning that it should only be loaded when it is needed. We'll refer to this components as **remote components** as they live in a different location.
+
+Webpack allows to do this by using the _dynamic import_ syntax (`import()`). Here's what we needed to do to load a component that belongs to the **shared** library.


This is true for react components only, when importing other data types, there's no need to use the dynamic import

comoser · 2021-03-16T09:41:39Z

content/blog/handling-react-remote-modules-with-babel.md

+```js
+import React from "react";
+
+const Button = React.lazy(() => import("shared/components/Button"));
+
+const HomePage = () => {
+  return <Button />;
+};
+```


You should probably say that this code assumes there's a higher up in the tree

comoser · 2021-03-16T09:42:27Z

content/blog/handling-react-remote-modules-with-babel.md

+
+Then, when this `Button` component is used, it will be fetched from the remote source, and rendered to the page. This makes it possible for webpack to code-split our codebase, only downloading the Button when the user needs it.
+
+However, and even thus it works, we though it would be too much of a burden for developers to do. They shouldn't have to care if the component lives in a remote source or not, nor they have to remember of wrapping it in a React.lazy call. All of this would make it very error prone, and at the same time would get our codebase full of `React.lazy` calls.


even though?

comoser · 2021-03-16T09:47:31Z

content/blog/handling-react-remote-modules-with-babel.md

+    return {
+      visitor: {
+        ImportDeclaration: function (path, state) {
+          if (path.node.source.value.startsWith('sharedcomps/')) {


you mentioned the shared/components/.. before, here you should do the same

comoser · 2021-03-16T09:48:10Z

content/blog/handling-react-remote-modules-with-babel.md

+
+We knew that babel-loaders needed to use the `babel-config` `custom` function with a callback, and that they would need to register themselves as a plugin in the global configuration.
+
+As we skimmed through babel-handbook, we also noted that we'd most likely use the visitor pattern, starting by _visiting_ the `ImportDeclarations`, since our initial code was one of them. We decided that we wanted every import starting with `shared` to be a target for this transformation, and thus we added the code to do that.


And we don't want every shared component to do this, only the ones we register in the options

comoser · 2021-03-16T09:49:03Z

content/blog/handling-react-remote-modules-with-babel.md

+    visitor: {
+      const componentPath = path.node.source.value;
+
+      if (path.node.source.value.startsWith('sharedcomps')) {


same here on this line

comoser · 2021-03-16T09:50:00Z

content/blog/handling-react-remote-modules-with-babel.md

+    visitor: {
+      ImportDeclaration: function (path, state) {
+        // console.log('opts', state)
+        if (path.node.source.value.includes('sharedcomps/Button')) {


comoser · 2021-03-16T09:51:23Z

content/blog/handling-react-remote-modules-with-babel.md

+```
+
+The above code finds the `ImportDefaultSpecifier` and modifies the initial import declaration so that it keeps all except the default. Then it adds the code to do the dynamic import, together with `React.lazy`.
+## Conclusion


Before the conclusion I would add the piece of code that allows us to decide on what components we want this to run on. It's open on a PR for dashboard-ui

asantos00 added 5 commits March 12, 2021 17:52

feat(babel-plugin): add initial draft

7c08a98

fix(babel-plugin): add david link

d2b4234

fix(mentions)

72d6a2e

fix(headings): add sections

f8a0de1

chore(publish)

e97469f

comoser reviewed Mar 16, 2021

View reviewed changes

asantos00 force-pushed the master branch 3 times, most recently from d45f6c4 to 5271df1 Compare April 1, 2021 11:22

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(babel-plugin): add initial draft#32

feat(babel-plugin): add initial draft#32
asantos00 wants to merge 5 commits intomasterfrom
add-babel-plugin

asantos00 commented Mar 12, 2021

Uh oh!

comoser Mar 16, 2021

Uh oh!

comoser Mar 16, 2021

Uh oh!

comoser Mar 16, 2021

Uh oh!

comoser Mar 16, 2021

Uh oh!

comoser Mar 16, 2021

Uh oh!

comoser Mar 16, 2021

Uh oh!

comoser Mar 16, 2021

Uh oh!

comoser Mar 16, 2021

Uh oh!

comoser Mar 16, 2021

Uh oh!

comoser Mar 16, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants


		David is doing a great job documenting this whole process and architecture, and thus I'll not repeat myself here. [add-david-mfe-link]()

		As part of this initiative, we created a shared library (which works as any other MFE) and only contains the components that are shared across products. All of this lives on a single repo, and we're using Webpack's Module Federation to define this clear interface between products.


		We wanted to import components from a different MFE, and we wanted this to be _code-splitted_, meaning that it should only be loaded when it is needed. We'll refer to this components as remote components as they live in a different location.

		Webpack allows to do this by using the _dynamic import_ syntax (`import()`). Here's what we needed to do to load a component that belongs to the shared library.


		Then, when this `Button` component is used, it will be fetched from the remote source, and rendered to the page. This makes it possible for webpack to code-split our codebase, only downloading the Button when the user needs it.

		However, and even thus it works, we though it would be too much of a burden for developers to do. They shouldn't have to care if the component lives in a remote source or not, nor they have to remember of wrapping it in a React.lazy call. All of this would make it very error prone, and at the same time would get our codebase full of `React.lazy` calls.


		We knew that babel-loaders needed to use the `babel-config` `custom` function with a callback, and that they would need to register themselves as a plugin in the global configuration.

		As we skimmed through babel-handbook, we also noted that we'd most likely use the visitor pattern, starting by _visiting_ the `ImportDeclarations`, since our initial code was one of them. We decided that we wanted every import starting with `shared` to be a target for this transformation, and thus we added the code to do that.

Conversation

asantos00 commented Mar 12, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants