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
The @microsoft/fast-element is currently bundled with the html tagged template literal, which developers must use to create their templates. This approach is not friendly to SSR (server side rendering) or BTR (build time rendering). The current solution is a NodeJS solution provided by the prereleased package @microsoft/fast-ssr. Due to unknowns, such as what server tech might be used, we have decided to modularize the templating as a first step towards allowing any server stack to implement BTR/SSR.
Background
In order to provide the most flexibility, we are looking into a few changes that would allow a user to provide their own template interpretation. This would allow a few key options:
Templates could be loaded async, after the compose step
Templates may be written in a non-JS manner (JSON, HTML, etc.)
Directives can be selectively chosen for inclusion into the package which would allow smaller bundle sizes
Requirements
Modularize the template resolution
Provide a separate export path for a modular FASTElement
The modular approach will not take a dependency on the html tagged template literal and will allow any template resolver passed to provide interpretation of a template solution.
The text was updated successfully, but these errors were encountered:
Introduction
The
@microsoft/fast-element
is currently bundled with thehtml
tagged template literal, which developers must use to create their templates. This approach is not friendly to SSR (server side rendering) or BTR (build time rendering). The current solution is a NodeJS solution provided by the prereleased package@microsoft/fast-ssr
. Due to unknowns, such as what server tech might be used, we have decided to modularize the templating as a first step towards allowing any server stack to implement BTR/SSR.Background
In order to provide the most flexibility, we are looking into a few changes that would allow a user to provide their own template interpretation. This would allow a few key options:
Requirements
FASTElement
Example custom element definition:
Example
compose
with the currenthtml
tagged template literal:The modular approach will not take a dependency on the
html
tagged template literal and will allow any template resolver passed to provide interpretation of a template solution.The text was updated successfully, but these errors were encountered: