Post-webinar FAQ
1) Are these code elements hosted on a Squiz server?
Yes. The code can be built and tested locally, which is an important part of making it easier for developers to iterate faster. However, once the code is tested and ready, developers use a CLI tool to deploy the component code to the DXP. The DXP hosts the components, and makes them available to editors to use in Matrix, and renders the output on the web page.
2) Do I need to have Squiz CMS (Matrix) to use the Component Service?
Yes you will need to have the latest version of Squiz CMS (Matrix 6.29) to access the Component Service.
3) Do I need to use Squiz CMS (Matrix) to use Component Service?
No. You can use the Component Service for certain use cases without using Squiz CMS (Matrix). For example, you might use components directly with Squiz Search (Funnelback) to render search driven content or a search experience. To do this, you just need somewhere to embed and display the components. This could be on a Matrix site but could be on any other site, for example a static standalone site.
What you can’t use without Squiz CMS (Matrix) - is the editing experience. The schemas that are used to define the data model in a component are used to generate the editing experience automatically within Matrix, you won’t be able to do this part in another CMS.
However, creating and editing content happens inside Squiz CMS (Matrix).
4) When will the Component Service be available to use?
The Component Service is available now. You may need to upgrade or have an update to your subscription agreement to use it - so best to talk to your Account Manager if you are an existing customer. If you are not yet a Squiz customer, reach out to us at ask@squiz.net
5) Is Squiz Component Service a tool to let you use webcomponents.org?
No, webcomponents.org is independent from Web Components. Web Components is a specific standard or approach for using the web platform to create client side self contained components. This is just one front end component paradigm, you also have approaches like React or Vue, other JavaScript frameworks, and plain old HTML, CSS and JavaScript. The Squiz Component Service is agnostic to which approach you are currently using, and should work with any of these. The Squiz Component Service also implements both back end and front end code.
6) Following on from that integration piece, are we exploring a supported or baked in bridge / hook in for datastore?
There is not a baked in bridge feature - like we have for certain bridge assets in Squiz CMS (Matrix). Rather than using asset configuration to create a connection to Datastore, developers can write code that talks directly to the Datastore API. In the future we would like to further develop SDKs to make it even easier for developers to write code to interface with the rest of the DXP features.
Although, at first this might seem more complex, it is simpler for developers to write a small amount of code to talk to the API than using a bridge asset which might not be flexible enough to do the job you are trying to do. With a code based approach, developers can express their logic in a more direct and maintainable way, and the code can be managed in version control rather than configured through assets inside the CMS, which can be hard to track down.
One additional feature that will make integrations easier is environment variables - which can be used to keep your API keys separate from your component code.
7) Are component styles or scripts encapsulated in any way? (i.e. to prevent external styles from being applied to components, or vice versa?)
No. By default there are no attempts to encapsulate the components. By design the Component Service is un-opinionated about this. You can use global styling or build in an approach to encapsulate styling or scripts for your components.
8) If you use a JavaScript frontend library to build a component (i.e. React, Vue, Svelte, Stencil), will embedding that component multiple times on a single content page result in multiple copies of the required scripts and styles being embedded as well?
No - we have a feature for just that problem. The Component Service is un-opinionated and you can implement using any pattern, the two most common being:
Building global payloads for your CSS and JavaScript and managing it outside of the Component Service.
Packaging up your CSS and JavaScript inside your components.
If you package up your CSS and JS inside your components, there is a feature to deduplicate your static files - both in the local preview and your Matrix global parse file. This is implemented with a new design area in the parse file.
9) Can array input types feed in data from Squiz CMS Matrix listings (asset, search, etc.) instead of manually setting content for each item in the array?
They can’t be fed into the data model - which is purely for content input, however you can implement this kind of solution with components. You can make an API call to the Matrix API to load the asset children data of a root node, which would be the new equivalent of an asset listing. You could load the output of a search listing, or output directly from Funnelback in the same way - and use this data to render your listing.
For the data model, you might just allow a root node selection - and the content editor would select a root node to list under (or whichever other controls you want to provide).
10) How can we set up our own CI/CD process in our development cycle before we publish to DXP?
You can bring your own CI/CD pipeline to the Component Service. You can use the local CLI tools, installed by NPM, to test and deploy your component to the DXP from within your pipeline.
11) Is there an intention to launch any Matrix training course in Squiz Academy platform about this "component development"? So that we can onboard new developers faster?
- There are two courses available now in the Squiz Academy for getting started with components.
- ELM320 Introduction to the Component Service is aimed at Developers, Content Editors, and Site Administrators, and introduces learners to the new Component Service, including what it is, how these different personas can utilize the new Component Service, and the differences between this and the current components.
- ELM321 Creating your first component is a practical module designed for Developers who want to learn how to create, preview and deploy a component in the new Component Service.
- There is also documentation available: https://docs.squiz.net/developers/latest/component-service/index.html
12) Because the local development tooling is publicly available and free to use, you can get started with the first half of the ‘hello world’ training or developer guide for building components and test them out locally.
How can we test in a local environment with real data? Is there a way to load data from external sources? Or, I've noticed in Squiz you have a way to set up a Docker image. Is there a way for us to do that?
The Component Service is designed to have a much lighter, simpler runtime that can be run locally, rather than Squiz CMS (Matrix) instance, which runs in a local docker container. This does focus on mocking data locally for testing, however you can load data dynamically if your component is loading data from the API.
13) Is there a cost to use the Component Service?
Component Service is part of the DXP service solution, so if you are a Squiz customer and already on the latest subscription model, you should already have access to Component Service. There won't be any additional fee for licensing or implementation to use Component Service.
If you do not fit into the above category, the cost is determined depending on the level of consumption you require. You can talk with your Account Manager or send a request to ask@squiz.net, and our sales team can get you the right consumption size that will suit your organization's needs.
14) Do components support TypeScript? (e.g. Are type definitions included, or can they be generated based on the manifest.json)
TypeScript should work, although we don’t yet provide automated type generation from the manifest file. This is something we are looking to add in the future.
15) How do these JS driven components, especially alerts, comply with WCAG? Or is this all SSJS?
Components can do server side and client side JavaScript, so there is no need to use client side JavaScript if you don’t want the UI to be dependent on it. This means that for WCAG or any other compliance requirements where you need to have a non-JavaScript based experience, you will still remain compliant.
16) How about nested usage of components? Is it designed that way?
For now, components cannot be nested. This is something we are looking at in the future as part of some improvements to the overall authoring experience.
17) Will this replace internal Squiz CMS Matrix component templates?
The existing Matrix component templates will continue to be available indefinitely. While this is a replacement for the feature, we don’t want this to prompt customers to need to rebuild their implementations. The new components can be used side by side with the existing component templates. We would recommend new builds using the new feature.
18) Is there a limit of how many components can be used on a Matrix page?
For now - the limit is about 20 components. We expect to increase this limit in the future.
19) What are the minimum requirements we need to use these components? (e.g. Squiz CMS Matrix version)
The minimum requirements are Squiz CMS Matrix 6.28 in SaaS or 6.29 in Squiz Cloud. For Squiz Cloud instances, they must be behind Squiz’s CloudFlare. Customers must also be on the new subscription agreement.
20) Can we use Component Service to create multiple page assets? For instance, letting editors create multiple required pages using a single click.
You could implement a more complex component that handles transitions or multiple ‘pages’ as part of a single component. The method of describing the data structure is flexible enough to articulate a data structure that content editors can populate for multiple pages.
However, your multi page interaction will be contained to one single component that must be embedded on a page, meaning it would need to take up the bulk of the page. It can’t be served standalone from the Component Service at its own URL.
This may not be the best pattern for multiple page apps, although for certain use cases it may be suitable. For example, the course finder tool shown in the webinar demo is similar to this.
21) Does building components this way help with SEO? (E.g code versus content ratios.)
This approach should not impact SEO. If you are worried about too much client side code loaded with the page, you can use the Component Service to do all the work server side and output only html to the browser. You still retain full control over what is output to the browser.
22) What security controls are in place to access the Component Service?
Squiz DXP users and roles control which users are able to deploy components to the component service, and to add versions of components to component libraries. Component libraries are then added to site assets in CMS Matrix.
23) Is usage of components built using the Component Service dependent on the service being available? (Ie. if the Component Service is down, does this impact content editors?)
If the Component Service is unavailable, for any reason, it would impact content editors. However, the Component Service is a central part of the DXP Platform. There are additional availability benefits to the Component Service being separated out of Squiz CMS Matrix as it is able to be scaled much more effectively.
24) How will the metadata schema fields be maintained in a Component Service model? Will metadata fields be manageable through the Squiz CMS Matrix interface or can they only be added/updated through the JSON file?
For components only - the new JSON schema method replaces metadata schemas, and for now these are only editable by developers via code.
However, in the future we will expand this to look at content modeling more holistically. At this point we would look at optimizing the graphical user experience for content modeling for the content editor persona. This would likely lead to a more complete replacement for how metadata is currently used, with a better UX.
25) Will the traditional Squiz CMS Matrix still work if we don’t have the Squiz DXP?
You can continue to use Squiz CMS Matrix without the Component Service and other parts of the DXP. The existing Component Template feature is still available.
26) Is there a sandpit or docker/VM environment available to developers?
Developers can use the local dev tools for the Component Service as a sandpit. The instructions for this are available in the documentation. Click here for documentation.
27) How do components work with caching, particularly where components are pulling data from the API?
Components must be cached, and there is a minimum default cache expiry time of several seconds. So they can’t be used for completely uncached real time access to pass through data from an API. However, you can set individual cache times for your components, as well as global headers for a whole component library.
28) What is the limit of components per page? Are components that are part of an asset listing included in the limit?
Each page can have up to 20 components. The limit is per individual page request, so to add to the limit it would be necessary to make multiple page requests.
29) Does it work well with personalisation?
In further roadmap initiatives this year, we will be optimizing the Component Service to work well with personalisation, including with the segmentation tools in the new CDP (Customer Data Platform). CDP is due to become available in July/August this year.
30) Is there a limit on the number of components that I can create?
There are no limits on the number of components that you can create.
31) Is there an out-of-the-box Squiz component library? Plans for a Squiz community component library?
Currently, the Experience Accelerator team is working on creating new components using the new Component Service. Although no new components are available at the moment, their goal is to introduce them to the Squiz community component library as soon as possible. The team plans to follow the same successful model they have used with their current marketplace templates.
32) How does front-end JavaScript integrate with this component system? If you were to use a front-end framework (with the benefits of server-rendering), would teams need to roll-your-own hydration? Are any users doing this?
The component runtime allows for server-side rendering while giving you complete control over client-side scripts. It differs from other SSR frameworks like Next.js. This means you will need to set up your own hydration, but there are resources available to help. Some teams within Squiz are already rehydrating server-side rendered React components, and the Experience Accelerator team plans to publish component libraries using React with optional client-side hydration.
While a more prescriptive SSR approach may benefit specific projects, it can be unnecessarily complex for more straightforward use cases. Additionally, since the components are designed to operate and render independently, it was not the best fit.