One thing that bothers me about most of the static site generators, is that they assume everyone knows how to use git. Git is a great way to maintain static files, because you can revert changes and see who made the changes. This makes it better than a database because a database has no changelog. The only way to revert with a database is to import a backup.
Github, Bitbucket and Gitlab, the three biggest git hosting providers, all have an api that allows developers to execute commit, push, pull and other git commands. This allows your application to stop burdening your users to learn git.
A few weeks ago I came in contact with Sanity. This is a content administration solution. They use CMS sparingly because most of the popular ones also take care of the data output. Sanity doesn't care about the data output. It only provides a query interface, much like a regular database.
This makes it perfect to build solutions on top of it.
Sanity configuration
The default sanity backend configuration provides three columns. In the left column you have a list of document types. In the middle column you see a list of the documents from the type you selected in the left column. And the right column is the document editor.
But you can change that layout. From now on i'm going to call document types page types, this is closer to the naming people use with static site generator solutions.
To create my sanity driven static site generator I had to think in pages because the static site generator needs to know which pages to create.
Most sites have one homepage and then one or more types of pages.
From line 11 to 18 is the configuration to show Homepage in the left column. And the editor of the homepage in the middle column.
Line 19 to 20 adds all the page types, except homepage, to the left column. This is almost like the default layout.
Now that the backend layout is created, it is time to create the page types. To create the body of the page types I'm going to use a collection of rows with columns. Sanity calls the configuration schema. In that schema there is a schemaTypes section which holds page type part and the page type configurations. To make it more readable it is best that the schemaTypes are split up into a file per schemaType.
Lets build the page type parts, row and column.
On line 4 you see the type of column is object. This allows the schemaType to be used in other objects and documents.
From line 5 to 7 you see the configuration of a fieldset. The name of the fieldset is added to the fields, as you can see on lines 32 and 38.
Lines 41 to 45 configure which field value is visible when the schemaType is in a collection.
On line 28 you can see how the column schemaType is used in this object.
Page types are almost the same, but instead of type object they have type document.
The main diffrerence between the page types is that the common_page type has a path field
This is the end of the sanity configuration. Now you can do two things, run the sanity backend, called studio, on your local computer or deploy it to sanity.io.
The static file generator
I read the Indexing in Agolia using serverless functions article. And the use of a scheduled webtask function gave me the idea to get the data from sanity, transform it to html and push it to a git hosting provider.
It is a lot of code. The two big parts are setting up the sanity and bickbucket connections. And transforming the page data to html.
From line 45 to 57 is the sanity query for both the page types. The thing that is missing from the query is the check for the timestamp that only gets the pages that are changed after the previous run of the webtask function.
Lines 90 to 105 commits the changed pages to the repository.
Next steps
At the moment the html tranformation doesn't add css or javascript to the pages. A real world application would also have navigation and forms.
The git hosting providers have a download the repository button and that allows you to place the html on the server of your choice.
Sanity has a third option for the backend, it allows you to create a static file version of the studio, and can also go on your public server. The imitation of common CMS solutions makes the step to a static site generator setup easier.
