Squiz matrix / github


(Gjboyd7) #1

It would be great if you could develop matrix code including keywords, push that to Github, pull into matrix via a GitHub Integration asset and nest the shadow asset in other assets in matrix, having the keywords render.

This would add a level of source control to matrix development, so could maintain a single source of truth for development teams, multiple developers to work on the same codebase without unknowingly overwriting each other’s work.


(chris.grist@gmail.com) #2

Hi Gavin,

I’m the product manager for Developer Experience at Squiz. One of the projects we are working on at the moment is a template deployment service that will do something very similar to what you described. We are building out the breadth of the Asset Management API (https://docs.squiz.net/matrix/version/latest/api/asset-management-api/index.html) to cover enough asset types, and creating a service that will export and serialise your Matrix implementation as a local set of folders, json files, and files. You will be able to edit the HTML of your parse file or paint layout in your local IDE, VS Code or whatever - including keywords or mysource tags etc. You would check that code into GIT, and run a CLI command to deploy it to Matrix to update the assets. It wont limit you from editing these assets in Matrix as well, you’ll just have to export the template first and merge it with your git copy of the code.

It’s at a reasonably early stage although the core solution works, and we have a subset of relevant assets built out, but it may be a little while before we can make the service available to customers.

If you want to know more I’d be happy to catch up with you.


(Gjboyd7) #3

Thanks Chris, that sounds excellent.


#4

We are using GIT to handle our component development. But just like you, we ran into some issues with keywords. To get around this, we have created our GIT components, along with ‘squiz helpers’ which are variables which are allocated to squiz keywords.

The squiz helpers have been separated from our GIT files, and is added as nested content before the git-component is added to the page.

Not 100% perfect/clean solution, but it gets the job done.