This blog post is the first in a series that dives into components, how they're defined and deployed into an Entando application, how they can be configured, and how they are rendered in your application. In this post, we'll cover frontend components.
Hey my fellow developers,
In the previous blog post of this bundle series, we learned what bundles are, how they are used and what goes inside them. We also learned that bundles are used to package components (or updates) to an Entando application.
This blog post is the first in a series that dives into the details about components including how they are defined, how they are deployed to an Entando Application, how they can be configured, and how they are rendered in your application.
We’ll cover frontend and backend components first, followed by CMS components, and finally page components, user management and internationalization.
This blog post is part of the Entando bundle series:
According to the official documentation:
“An Entando component - simply referred to as component - is a piece of reusable code that can be used in an Entando widget, page or application. Examples of components are widgets, micro frontends, content-types, labels, plugins (microservices), and static resources”
Entando bundles are made up of one or more components. We will cover all of the different types of components and how to define them in your bundle in the next sections.
The plugin component is used to deploy microservices. Each plugin is deployed onto Kubernetes and runs as a pod.
name: standard-demo-banking image: 'docker.io/entandodemo/banking:0.0.18' dbms: none healthCheckPath: /management/health ingressPath: /banking roles: - task-list permissions: 
The plugin is deployed as a custom resource into Kubernetes. This means you can check them with the following command with ENT cli or directly with kubectl.
ent kubectl get EntandoPlugin
code: credit_card_user_apply_form titles: en: Credit card user apply form it: Form di applicazione carta di credito group: free customUi: '<#assign wp=JspTaglibs[ "/aps-core"]>
configUi: customElement: my-widget-config resources: -
/static/js/main.js # The resources necessary to the custom element to render the configUI, like the code
Widgets are available under the menu: Components > Micro Frontends & Widgets
Example: This widget renders a form on the page.
A fragment is a piece of reusable code you can insert into your pages and widgets through a freemarker directive (e.g. a script import).
code: insurance_inclusions_footer guiCode: ' <#assign wp=JspTaglibs["/aps-core"]> '
It can be used like this in a page or widget:
<@wp.fragment code="insurance_inclusions_footer" escapeXml=false />
The widget is available under the menu Components > UX Fragments
You need to create a folder called “resources” and all the files inside this folder will be made available as static resources to your Entando application. This means you don’t need to explicitly declare each resource in the main bundle descriptor. In Entando App Builder, the “resources” folder is renamed to match your bundle id, you can access it in the Administration > File browser menu.
Static resources can be used like this in freemarker templates:
The files can be browsed in the menu Administration > File browser
Now that we’ve covered the Entando components to deploy and install backend services and micro frontends to an Entando application, the next blog post will cover how to deploy and install CMS components to your application using a bundle.
This white paper outlines how your organization can accelerate UX innovation by developing with micro frontends on Kubernetes, as well as how a micro frontend platform can help you execute this methodology more effectively.