N
Nakassony Bernardo
Guest
In this second part of the Microfrontend series weβre answering another posed question, we explore integrating Still.js with Next.js, focusing on using remote Vendor components. The video includes a real-world use case and a project built from scratch, follow the Design System for implementation:
What points will be addressed in the video:
Remote components
This approach is key in Microfrontends, as it enables embedding components from outside the project structure. It enhances feature sharing, increases decoupling, and reduces the size of the deployable package (e.g. bundle).
The idea behind remote component is for them to be served from somewhere which is not the embedding application itself, as we can see in the bellow architecture:
The above architecture promotes reusability by allowing the same component, available via NPM/GitHub, to be embedded across different applications built with various frameworks. Still.js can play a key role, serving as proxy as needed, by being embedded within these apps as well. Additionally, Still.js enables components to be written in Vanilla JavaScript rather than relying on framework-specific code.
Although NPM and Github are the approaches depicted in the architecture, Still.js adapts well with any other source for embedding remote components.
Self-contained components
This is the optimal situation in which a component can be used remotely, as the idea is that not external dependency exists so to avoid cascade importing, which can be harmful in terms of performance, also might cause JavaScript bloating issues.
Coding snippets specific considerations
Step1: The Still.js app is integrated into the Next.js project by placing it in a subfolder (weβll call still-mf/) inside the public/ directory. It is then loaded using the apploader with additional parameters:
Step2: Next.js listens to Still.js events via subscription. The Apploader SDK now supports init/on(βloadβ) event, improving memory and CPU usage, so no setTimeout needed:
Compared to part one of the series, the main differences in the Still.js app setup for Next.js is the need to specify PATH_PREFIX and, optionally, the framework version to define which Still.js version is used.
Embedding NPM remote component
The video tutorial demonstrates how the StillTreeView vendor component from Still.js is used in a real use case with Next.js + Still.js integration. The component is embedded directly from NPM as a remote as shown in the example below code snippet:
As conclusion:
While not a bulletproof, Microfrontends are highly effective for complex, enterprise-scale applications. Remote components further enhance this architecture by promoting decoupling, feature sharing, and scalability. Ideally, these components should be self-contained for optimal results. Also, don't forget to check the video for more details.
Whatβs Next?
Don't forget to check the video
Try implementing a more complex Microfrontend with Still.js including navigation/routing (routing documentation)
Try to compare different Microfrontend approaches with the way Still.js does disruptively
Share your thoughts and ideas in case you have any concerning to this topic
Bear for the next parts of this series
Se you next time
.
Continue reading...
What points will be addressed in the video:
Creation of Next.js project
Generating and embedding Still.js app inside Next.js App
Embedding remote component (straight from npm) into the application
Data exchange between Still.js and Next.js (React)
Remote components
This approach is key in Microfrontends, as it enables embedding components from outside the project structure. It enhances feature sharing, increases decoupling, and reduces the size of the deployable package (e.g. bundle).
The idea behind remote component is for them to be served from somewhere which is not the embedding application itself, as we can see in the bellow architecture:
The above architecture promotes reusability by allowing the same component, available via NPM/GitHub, to be embedded across different applications built with various frameworks. Still.js can play a key role, serving as proxy as needed, by being embedded within these apps as well. Additionally, Still.js enables components to be written in Vanilla JavaScript rather than relying on framework-specific code.
Although NPM and Github are the approaches depicted in the architecture, Still.js adapts well with any other source for embedding remote components.
Self-contained components
This is the optimal situation in which a component can be used remotely, as the idea is that not external dependency exists so to avoid cascade importing, which can be harmful in terms of performance, also might cause JavaScript bloating issues.
Coding snippets specific considerations
Step1: The Still.js app is integrated into the Next.js project by placing it in a subfolder (weβll call still-mf/) inside the public/ directory. It is then loaded using the apploader with additional parameters:
Code:
useEffect(() => {
const stillApp = new StillAppLoader();
stillApp
.cdn({ env: { STILL_HOME: '/still-mf/', PATH_PREFIX: 'still-mf/' }, version: '1.3.13'})
.load();
},[]);Step2: Next.js listens to Still.js events via subscription. The Apploader SDK now supports init/on(βloadβ) event, improving memory and CPU usage, so no setTimeout needed:
Code:
useEffect(() => {
// β¦. Above code
stillApp.on('load', () => {
stillApp.component.ref(ref1).variableName.onChange(newData => {
console.log(βStill.js updated the value of variableName to β, newData);
});
});
},[]);Compared to part one of the series, the main differences in the Still.js app setup for Next.js is the need to specify PATH_PREFIX and, optionally, the framework version to define which Still.js version is used.
Embedding NPM remote component
The video tutorial demonstrates how the StillTreeView vendor component from Still.js is used in a real use case with Next.js + Still.js integration. The component is embedded directly from NPM as a remote as shown in the example below code snippet:
Code:
<st-element component="npm/@path/to/package/ComponentNameβ></st-element>As conclusion:
While not a bulletproof, Microfrontends are highly effective for complex, enterprise-scale applications. Remote components further enhance this architecture by promoting decoupling, feature sharing, and scalability. Ideally, these components should be self-contained for optimal results. Also, don't forget to check the video for more details.
Whatβs Next?
Don't forget to check the video
Try implementing a more complex Microfrontend with Still.js including navigation/routing (routing documentation)
Try to compare different Microfrontend approaches with the way Still.js does disruptively
Share your thoughts and ideas in case you have any concerning to this topic
Bear for the next parts of this series
Se you next time
.Continue reading...
