search

fikaproductions / fika-gatsby-source-cockpit

This is a Gatsby version 2.\*.\* source plugin that feeds the GraphQL tree with Cockpit Headless CMS collections and singletons data. Actually, it supports querying raw texts (and any trivial field types), Markdown, images, galleries, assets, sets, repeaters, layout(-grid)s (currently only without nested images/assets), objects, linked collections and internationalization.
GNU General Public License v3.0
23 stars 22 forks source link

Support for hierarchical collections #12

Closed DigitalGoldfish closed 5 years ago

DigitalGoldfish commented 5 years ago

As discussed in https://github.com/fikaproductions/fika-gatsby-source-cockpit/issues/11 I added support for hierarchical organized collections.

It works as far as I can tell but I am not totally sure if I use the best way to add the child nodes to the GraphQL tree. Looking at the Gatsby Node APIs documentation I can see that there are methods to link nodes in a parent/child relationship however when I tried to implement this all i got in the Query result in the "children" field was an array of string ids, not the object.

DigitalGoldfish commented 5 years ago

One more thing that came to my mind just now ... would it be meaningful to add a field "depth" or "level" to the collection nodes? I am not sure if it is a useless addition or might make sense for some use cases ...

WhippetsAintDogs commented 5 years ago

@DigitalGoldfish, I think that adding a "depth" field might be useless since the GraphQL query will output the same hierarchy of nested objects/entries as represented in Cockpit and we're not flattening by any means the whole structure.

I didn't have the time right now to test it, but how the "All" version of the query behaves? Does it return all the possible subtrees of entries for a hierarchical collection or just the entries alone? (maybe a depth field could be useful if we would find a way to return the structured hierarchy for a direct query and flatten entries for an "All" query 🤔...)

DigitalGoldfish commented 5 years ago

The entries are already returned flat for an "All" query - since we only ask for entries of a given type and all of them share the same type this is standard graphQL.

Given my data structure from #11 a graphQL to allCockpitMenu would return all the menu items regardless of hierarchy in a flat edges array since the child items have the same type as the parent item and that's all we ask from GraphQL here.

After thinking about it a bit longer I should at least add a link to the parent item to the children to make it possible to query all children without getting their parent too. Still not sure about the depth field ... it would make it possible to query all items of depth x regardless of parent but I am not sure how common a use case that is ... personally I can't think of any right now for me but of course others might disagree ....

WhippetsAintDogs commented 5 years ago

All right, I agree with you, that makes sens.

Regarding your first comment, I just remembered a reason why you shouldn't use parent/children node relationship and continue your implementation like you are doing with foreign keys: these are made for transformer plugins, children are supposed to be derivated data from the parent and there is the whole notion of cascade node deletion with parent/children node links (if we delete the parent, it deletes the children also). I'm not 100% sure, but I tend to think that what you did is more appropriate for this use case.

DigitalGoldfish commented 5 years ago

I added a link from the child to the parent by adding a field "parent" that links to the parent node. I also added another attribute "level" that contains the hierarchy level of the current node.

One slightly weird thing I noticed is that the children are not only in the "children" field but also in the "cockpitChildren" field. I have no explanation why that happens (doesn't seem to be in the plugin) so I assume that this is some Gatsby magic. Makes me wonder though if i should use cockpitChildren/cockpitParent as field names to avoid any possible conflicts.

WhippetsAintDogs commented 5 years ago

Great!

@DigitalGoldfish, the answer for the "cockpitChildren/cockpitParent" is here under the API > Inputs section: https://github.com/angeloashmore/gatsby-node-helpers.