Grow as a static data compiler for Vue/Svelte and such?

[OktarinTentakel]

Hi there.

I really enjoyed using Grow in the past for static site development, it's the bee's knees and maybe my favorite generally unknown project out here. :D

But since there's more and more dynamic frontend stuff going on (for us mostly Vue and Svelte) I was entertaining the idea of using Grow as a data aggregator, providing localized data as (static) json for said frameworks via inline json or json files, while also using the normal templating to scaffold the whole thing and load all the magic stuff happening in the JSXlike files.

In my mind, this would mean constructing complex data structures as JSON-flat-files or JSON-strings from all the normally available contents and possibilites and render them to a template or a non-HTML-file.

Does this sound like a terrible idea to you? Did you ever envision something like this? And do you maybe have a tip or two concerning how to effectively construct consumable data structures with all the tool present?

Thanks for this lovely project again.

[Zoramite]

Hi @OktarinTentakel ! Glad you are liking grow :)

There isn't really anything stopping you from using grow to template out data for the frameworks to use. Depending on what data you are going to be generating there are different ways that you can handle it.

• If you want to output inline json you can use the jinja2 filter tojson to convert it to json in the template.
• You could also do a similar thing in a template for a json file in the views if you wanted to make them separate but also do some custom generation from other grow content.
• Alternatively you could create a custom extension that would be able to do custom jinja filters processing on the data before it is written.

So, not impossible, just depends on how much you need to setup to get the json created and how you are storing the data. :)

If you have some specific use cases that you need suggestions on just let me know.

[OktarinTentakel]

@Zoramite

Thanks for the response. I guess I'll take a day to build a proof of concept and see how that goes. Any sore point that come up, I'll give you feedback about. I'm still not 100% certain that this is a brilliant idea, but more often than not, content editing for these apps is a rather simple thing, a dynamic backend seems out of proportion for.

[OktarinTentakel]

@Zoramite

Finally I've come around playing around with the whole concept.

What I stumbled upon, when trying to integrate data from a Google Sheet:

• there does not seem to be any in-depth documentation or example on using Google Sheets, or am I missing something?
• this would be a very important feature, I think, because this is simply the way Excel-people think and how the result in the collection should look like: Google Sheets Preprocessor for Collection in Single Sheet #718; the other options, except mapping the list unto a key, seem too techy or complicated for cooperative use
• apropros cooperative: is there any way to get around the oauth/verficiation code thing by allowing public reading on a document? (at least in the ui it let's me save/export the sheet without any further auth); the problem here: either I'd have to allow very broad access to my company google account, including sensitive stuff in my google drive to a "foreign" app (which is really problematic) or my customer would have to do that (which is not much less problematic). Apart from the security issue, this introduces manual steps when setting up the project for each person working on it. So, is there any way to use the preprocessor in a read-only mode for public sheets without oauth?

[Zoramite]

Hi @OktarinTentakel

So far the only docs we have on the Google Sheets is in on the docs site. I agree that there are probably a lot missing in that information, I need to go through and compare what is missing compared to the docs to update that.

I agree that I need to get back to the new format of the spreadsheet to make it available to work as a grid, I'll try to work on that soon.

With the document permissions, a lot of it depends on how you are planning on using grow.

• If clients run grow commands themselves, than just having them do the oauth flow works fine as is.
• If you are planning on running the commands manually to download the sheet then it is usually just easier to do the same flow and just share the doc with those that need to be able to edit it.
• I haven't tried using a public read document, I think that we only have it coded to do all sheet downloading as authenticated user. If you feel that you want to be able to use the preprocessor with public docs please open another issue with your use case.
• Often times we automate a lot of the sheet download into a CI build. Either a cron build that rebuilds the site periodically, a manual CI build that can be triggered using a custom dashboard using an API to the CI platform, or as part of the normal build process when changes are pushed out. In any of those cases we usually use a service account to provide the authentication to Google. So any sheets that you need to access in the build just needs to also be shared with the service account to allow for the build to download from the sheet. You can also give that service account read-only access and keep control over who can edit the doc.

[OktarinTentakel]

@Zoramite

The last option sounds promising and I recently read about oauth with a service account, but without further documentation for usage with grow I feel a little lost.

I'll try to document the public sheet case tomorrow.