Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable data object carryover #83

Open
briandominick opened this issue Jun 21, 2019 · 0 comments
Open

Enable data object carryover #83

briandominick opened this issue Jun 21, 2019 · 0 comments

Comments

@briandominick
Copy link
Collaborator

LiquiDoc can presently write data to file using a parse action and then ingest this data in later actions. For performance reasons, the option to carry those objects in memory might offer some slight improvements. More importantly, however, we could eventually allow evaluations and other results within the config if the config could evaluate the results of parse actions.

For instance, _configs/build-docs.yml:

- action: parse
  data:
    - data/manifest.yml
    - data/versions.yml
  query: siteManifest # a GraphQL query that creates a combined object
  builds:
    - capture: site.manifest # store the combined object as a variable
      output: _builds/data/built/manifest.yml # write the combined object as a YAML file
      # no template is needed; all we are doing is morphing objects with GQL
# The following two actions are effectively identical:
- action: parse
  data: _builds/data/built/manifest.yml # reads the YAML file
  builds:
    - output: site-manfiest.json
- action: parse
  data: $site.manifest # loads the stored object
  builds:
    - output: site-manfiest.json

The capture: property would require the result be a proper data object or small-data format (JSON or YAML). This would work for any raw ingested data from one or more files, and including standard vars and data sub-objects, as applicable. It would also work for any data converted into a proper YAML file using Liquid. (Yes, in some cases it makes more sense to use YAML to manipulate data structures than GraphQL or any other query language, for that matter. I really need to blog this.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant