f(d) = v
One of the ways, although an oversimplification, to describe how these libraries work is the equation of a function given data results in a view. The function for our purposes being the component library code you author, data being content coming from the Zesty.io CMS and view is the resulting HTML output of this combination.
Arguably the simplest and most common of these strategies. This is when source files are built into a *single bundle which is served to a web page that mounts it to a DOM element. Typically a root element such as a child div of the body tag. This is also known as a "headless" strategy.
<!-- Your pre-built app bundle -->
// App mounts to this element
With this strategy when the application is initially mounted it contains no data to render. It will make http network requests to the CMS API to fetch necessary data and then render out views.
A SPA can be used across all urls of a site or on a single path part. e.g. example.org/app/
There is not a hard requirement for component libraries that they are the only thing on a page. Usually the only rule is that anything nested below the mount element of the component is not interacted with externally.
This allows for combining static pages with embeded dynamic components.
<!-- Your pre-built component bundle -->
<p>Post content ...</p>
// This child DOM structure should not
// be interacted with externally.
This is a solution where you author component source code which goes through a build step which combines data with the source code and outputs the generated static files. These static files are then pushed to a host which serves them to consumers.
With this strategy usually you will have separate data, code and hosting management (read: third party providers). Whereas Zesty.io offers both data and hosting management allowing you to pick your choice of code authoring and build steps.
e.g. Zesty (data) + Gatsby (code) + GCP Bucket (hosting)
These strategies boil down to two main groups; is the server rendering or is the browser rendering. Both the SPA and in page components require the browser to render. While SSR starts with the server doing an initial render and eventually has the browser take over rendering.
Zesty.io does not offer custom server rendering environments. That is, we will not run a build script for your source code.
When rendering in browser, on Zesty.io, there are a few ways to deliver application bundles; globally, per model, per page and inline.
With all of these solutions there are a few implementation details they all must consider.
- How is the code built?
- How is the code delivered?
- How is data fetched?
Each strategy typically allows for multiple combinations of solutions to these concerns.
A single bundle is not a requirement. It's possible to build multiple bundles which are shipped independently.