[GraphQL]Categories levels, Entry (entry)types work, just not yet in Graph(i)QL

[narration-sd]

Description

Simple one -- great to have Categories added as GraphQL is understood to be developing towards completeness, and they basically work in trying them out. The levels field is likely pretty key for many, though, and needs to be added there -- thanks.

Additional info

PHP version | 7.1.28
Linux 4.15.0-47-generic
MySQL 5.7.25
GD 7.1.28
Craft Pro 3.3.0.1

[narration-sd]

Sorry, Category levels are ok -- the problem was that these are one of several things the internal Graph(i)QL doesn't yet support.

Here some things apparently supported and not, just now:

• field categories { levels } is ok, but not in Graph(i)QL. Levels, probably essential to see.
• type, either as field or as query selector: actually again ok, but not in Graph(i)QL. This is pretty important as selector, to avoid empty records for non-intended entryType(s), thus lacking inline fragments defining them. As field, let's you discover values, as they're strings rather than enums...so only interpetable from other naming in Doc -- maybe something can be done about that in due course. I'm also considering making safety for empty records automatic in Live Vue.
• Category parent: not working in GraphQL yet; less important than levels, but should be there for function, on any entity that has hierarchy, would presume. Not yet on Entries, either.
• You'll notice I keep re-naming Graph(i)QL. I suspect it should have the name GraphiQL, in doc and as its left-hand icon-menu name, as that's standard and recognizable that you are going to get the interactive interpreter...

I'm changing the title to make this mixed issue more correct and more apropos.

A p.s.: Once again, I'm finding Insomnia essential for investigating such things with truth

[narration-sd]

updated again for one more field, tip on discovering

[andris-sevcenko]

Everything is exposed to GraphiQL. It's not very possible for something to work in one place, but not in GraphiQL, since it's just a web client pointed to the right endpoint.

Make sure you're using the right schema and have cleared your caches.

Category parent: not working in GraphQL yet

Yeah, I seem to have missed that.

[narration-sd]

Hmm.

• not seeing how browser cache should have to do with it, but it's a safe answer often enough...and could with very bad luck have to do that I was also comparing GraphiQL and CraftiQL there...

• [ this one now understood; see next comment post below ]

but actually I suspect that arrangement itself is in the nature of thinking 'type' not seeming to work in GraphiQL -- it doesn't exist in that Schema. typeId and typeHandle do, and they work on this thing of yours and parallel on Insomnia, so x that one.

• it's not that I don't trust GraphiQL, save in its recent rookishness...but what does function yet of the possible, appears ok

• parent -- not only on Category not working; also not on suitable parented entryType fragments. These are Structure, do query level ok, but parent isn't a Schema-allowable field for them, yet.
  I checked to be sure it's a normal Entry field.

• I'm confident you won't forget the GraphiQL standard naming, and that's enough for this time, anyway.

[narration-sd]

Ok, one more clarification, about 'type' issues.

• typeId is consistent -- we'll see what 'consistent' means
• typeHandle exists as field for queries: you can see the String representation of an entryType
• but as argument to an entries query itself, typeHandle doesn't exist, thus fails
• what does exist for 'entries' queries is type -- and this works as if it were typeHandle

Thus to be consistent, it feels the entries query argument ought also to be typeHandle. This should fix around lines 42-43 of gql/arguments/elements/Entry.php.

Then queries and fields will agree

[andris-sevcenko]

Thus to be consistent, it feels the entries query argument ought also to be typeHandle. This should fix around lines 42-43 of gql/arguments/elements/Entry.php.

typeHandle exists there to display what the entry type is, as there is no GraphQL entity for entry types themselves.

On the query, however, the type is there because that's how it is on the entry element query.

It's definitely good to align those, however, I'd propose adding a type field on the entry to keep the GraphQL query aligned with the element query.

[narration-sd]

Seems reasonable, and yes, the alignment with Element is good for clarity.

I had a look at the 'prior' implementation, and he uses type there. but sub-fields to query id or handle, and as usual, one of his Enums to identify for query. Which I think we are well enough without.

[andris-sevcenko]

The parent field has been added as of 4c9f3ec

[narration-sd]

Good man. I'll pick it up, as I'm always composer updating on dev-master.

Just so you know, I saved both of us another request and possible PR by checking on something else within the weekend, and it's also looking good now; could have been something I had done as well, actually...but good is good.

[narration-sd]

I'm always composer updating on dev-master

err, dev-develop...makes a difference...

[andris-sevcenko]

It's definitely good to align those, however, I'd propose adding a type field on the entry to keep the GraphQL query aligned with the element query.

As far as this goes there's a decent chance we might want to expose structural elements of the site over GraphQL over time, so it's probably better if we leave the type (and similar) properties unoccupied for now.

[narration-sd]

Well, don't be impatient to close, please, as there's a quite concrete point here.

If you think you might want to go meta someday, sure, save type for it.

But then we'd need what I first proposed, which is to provide typeHandle. It's a clearer naming anyway, and it has an important job.

The reason (I am avoiding an outline for prose) I thought I laid out, but possibly too easily lost above) is that our Crafters can readily have more than one entryType per Section.

When they do, and in the usual way want to work with one or a subset at a time, they need to say which in their query parameters. If they don't, then records will come back of types that aren't served by matching inline fragment descriptions. The consequence is that they will end up with blank records facing them, or at least records bereft of any fields which are not native to the Element itself, which is the same situation.

What this means to the Vue etc. client code is that it can't really tell it's got a bad record, or would have to do a lot of flopping around to try to know accurately. For the same reasons, I can't head this off at the pass for Live Vue -- and your friendly homegrown SPA people will have the same arrestment.

Last, hoping to be thorough, typeID could be used, but that would be insensible in a post-COBOL age, wouldn't it, where we don't do abstract numbers for meanings (actually, COBOL used names also, which was of Admiral Grace's well-deserved fame). And even if we were so bold, we'd get cut down as soon as the ship sailed into foreign (dev vs stage vs live) waters, which can well according to database construction, history, etc. have different integers vs. (type) names.

Whew, huh? I guess I had a few other point-by-points in the now-passed day. That and busily reading beginnings of (the best) noirs, always to see those sets of workings, for use in quite another form...very instructive, and interesting besides, not least for the history of persons in them.

Cheers, Andris, and I know you're doing your best to think of all angles, that's clear.

[andris-sevcenko]

When they do, and in the usual way want to work with one or a subset at a time, they need to say which in their query parameters.

I'm not sure what you're talking about. You've been able to specify the entry types by handles or id's since the very start - https://docs.craftcms.com/v3/graphql.html#the-type-argument

It is called type to be consistent with element queries, as we've already discussed.

Just provide an array of strings as the type argument and then access the typeHandle field on the returned results, if you're not inclined to using the __typename meta field.

[narration-sd]

That's the trouble with trying to be attentive to not let these things fester over timezones, and getting messages as the one that sent me on this chase in hour late.

I'll try now to dig out what you were actually talking about in not having a type, when that's, yes, understood to have been our agreed critical name...

[narration-sd]

And yeah, I really don't get it. What do you mean by 'unoccupied for now'??

Or more apropos, can I and others depend that the type argument to an element interface query, entries in this case, is going to be dependably now and in future present?

Your last reply says yes, but then I don't grok what the interjected 'decent chance...leave type [...] properties unoccupied' statement intends to mean?

Maybe you mean you don't want to return 'type' (as typeHandle) as a result, a field in the query or fragment, is that it? My goodness. No bells go off just now if you hold that back, oh-dark-thirty, at least, but somebody might find a way to want it, such as to account the entryTypes available. So I think if you have this as the plan you were stating, maybe you want something else for your pre-proposed meta, leaving type as it is...like, say, craftType, or elementType, or elementMeta. Do concrete names jar thinking?

[narration-sd]

addendum: I'm not feeling the primitive __typename does the trick here, because it carries baggage of your enlongated namings, needing to be parsed down in strange ways to arrive at actual entryTypes such as would be entered for the query argument type, doesn't it?

Points if I miss something here, not firing up a vm at this hour.

[narration-sd]

All right. I succumbed, rather than lose more sleep over waiting for your coffee-break :)

• yes, __typename will work, for purpose described or more nefarious
• the reason it will work is, that type as a query argument takes, not strings, like other Craft things like Sections, not actual Craft handles, but rather your own in-Craft-GraphQL Enums for ?types?. Should be a lot of ellipses here for nonplussment, but ok, there we are.
• I guess you can explain that, in future support calls.
• It's a feature, and I stand to rest on it.

In manner of apologia, you might understand my reaction above in that there could be a tiny bit of sensitivity left over, about things going bump in the night on somewhat obscure language. On the other face, you gain a little more trust from me here, Andris, bowing to the fact that some inconsistancy is pretty natural to always be present, and that you did have a logic for it.

Yes, 'somewhat obscure language' can be fun, someone would probably know that. It keeps things light, in its way, besides interesting. So you could say I floated away with tonight's balloon, for a little while...Priekā, by the wonders of Google...

[narration-sd]

And p.s., by the way, I don't think I've seen a software tool better named for its use as this evening, than 'Insomnia'.

[narration-sd]

True Parthian shot: type as Craft-GraphQL hieroglyphics will work...in the world confined to query internals. It doesn't for actually discovering Craft entryTypes, to knit together a troubleshooting, for example though, does it.

Human brains can reasonably cross that water, yes, if we didn't necessarily need to be adding to the current. And, I left out for a moment another due homage to Gödel, but you'll know where that goes. And applies just as much to perfectionism about naming, for sure.

[andris-sevcenko]

Or more apropos, can I and others depend that the type argument to an element interface query, entries in this case, is going to be dependably now and in future present?

Yes. As stated multiple times before, the queries align with element queries. Entry query has a type parameter. So does the appropriate GraphQL query.

Your last reply says yes, but then I don't grok what the interjected 'decent chance...leave type [...] properties unoccupied' statement intends to mean?

Queries don't have properties or fields. I was referring to the actual Entry returned. Which would allow accessing section or entry type GraphQL types if we had them. There's a good chance that we'll have them eventually, so it's better to leave the type field on the Entry available so that the entry type can be accessed from the Entry.

the reason it will work is, that type as a query argument takes, not strings, like other Craft things like Sections, not actual Craft handles, but rather your own in-Craft-GraphQL Enums for ?types?.

I have no idea where you're getting this from. Allow me to quote the documentation: "Narrows the query results based on the entries’ entry type handles." That's actual Craft handles, obviously. Just pass in an array of strings or a single entry type handle.

[narration-sd]

Boy, I am really near sleep, and I turned off that vm, commented somebody elses thought's a moment to wind down.

But, Insomnia is still displaying, so I can quote:

• I have a Craft entryType in play, whose name is Cards Site.
• its handle is therefore cardsSite
• the __typename Craft GraphQL returns is CardsCardsSite
• that's not a string, and it's not a string required in the query either:
• entries (..., site: CardsCardsSite, ...) being the query syntax, as I tested
• neither of these is in formation anything like 'the entries' type handle(s)', to quote
• which again, is the string 'cardsSite'
• such distinctions do kind of matter, da?

I'm not trying to quibble, Andris, I hope you can see that. Computers having always been pretty stupid, so far, and needing to know the one-syllable concepts they're fed.

Which puts us one up on them for the the foreseeable future, anyway, since in matters of categories, we know very well why we want to release, adapt, humanly forgive.

Now I am going to cheerfully rest, while wishing well, so you can tell me if I miss something for tomorrow.

[andris-sevcenko]

__typename is a meta field that I suggested you can use in case the entry type's handle was not enough for you. That displays the GraphQL type's name.

Just use entries(type: "cardsSite") and that will work.

[narration-sd]

I'll validate that in the morning, which I'm sure it also will at this point. If memory seems to say it didn't - which is why I had that useful query lying around in Insomnia in the first place. But probably I made some kind of mistake.

It remains that there's no way to discover "cardsSite", given what you prefer tonight/today for withholding type.

I'm not inclined to belabor it; you can respond when someone of proximate reason has the need.

This is the sort of thing I mean, though, in observing per Gödel in maths, and more certainly even in linguistics or other culture, that we never achieve true fully consistent systems, even if we are convinced we 'could' -- and should therefore smile a bit and relax, adjust, when the inevitable arises.

...🐟

[andris-sevcenko]

It remains that there's no way to discover "cardsSite", given what you prefer tonight/today for withholding type.

Again, the documentation is quite explicit about this - https://docs.craftcms.com/v3/graphql.html#the-typehandle-field. I have also mentioned this before.

[narration-sd]

Ok, Andris. This has gone enough circles, all because of inconsistency between the naming in the query arguments, and the naming in the field list. I hope you will see that.

Thus I lost track of what I myself said up front.

Yes, typeHandle present, as a field. Yes. For query arguments, I can use its result. However, by another name only, type. Apparently as a string, yes. Where it seems a kind of Enum, which is not a typeHandle or a string, can also be used, otherwise. And by the way, type while not deemed present in present field names, will be be present in future, but then mean something/s entirely different when it then appears, from its meaning in arguments.

Years are having me enjoying just quietly ghosting a smile, nodding my head, knowing we will muddle with muddles, and survive this, by that time fully with a smile, to all degrees wise...

with more than a ghost, Andris,
and a pleasant perhaps nonsequitor again, 🐟
and btw, that's a very nice picture of you, presuming Dace took it...

[narration-sd]

It's 'morning', after the last of these wee-hours sprints it's going to be sensible to do, and you're going to love the results of a fresh look.

• First, I was making a mistake with tired eyes, so some of the identities have changed
• ...it turn out that I had actually been querying CraftQL on the machine during last night's final session, not Craft GraphQL. An example, anyway, that they're composer-compatible after Brandon's donated upgrade.
• I've now convinced Insomnia to name-difference queries on the same base url, to keep this straight

Thus:

• yes, entries(type: "cardsSite") is the working incantation for a limiting query argument
• any kind of value returned from __typename isn't
• type: ["cardsSite", "cards"] properly GraphQL-List accesses both entryTypes, etc. Good.
• what __typename returns is yes, string, but e.g. "cards_cardsSite_Entry". This is not useful except as naming, if not as a string, for an inline fragment detailing the cardsSite entryType it refers to. That's probably reckonable, in due course, by most.
• It is possible to list __typename only on the base Entry, not within entryType fragments. That's same as CraftQL, so.
• field typeHandle does return the correct string entryType handle. It will also work inside an inline entryType fragment.

Conclusion for these facets:

• what you have now is functional, yes
• it will need some particularly clear, well thought out hand-holding, both in description, and in daily support, for persons translating over from CraftQL, or especially, using both on apropos sites
• CraftQL feels likely to stay in there, due to pricing difference, due to no GraphQL w/o Craft Pro fee, so such support won't vanish.
• the fundamental mismatch between 'typeHandle' as (proper Craftwise) field, and 'type' as query argument is, well, 'there'.
• when you actually employ type as a field the way you say, it will be apt for increasing this confusion, one would suppose
• this is probably a better substitute for the description of conceptual spirals above

Suggestions:

• I don't think I'll make any further, as I reckon by now that you prefer always to do on your own
• it's not a crime, but is kind of a block to progressive conversation, too commonly prevalent in software sides of life, one would feel
• and yes, it's hard, to have your own good cut at an order of things questioned. Experience doesn't make this feeling less; just ameliorated by wider consideration. As I observe it, anyway.
• thus, mea culpa here as required, and of course conversation itself and good, also entertaining moods for it, will go on, be assured....
• as always, also due consideration for the challenges you are placed in, just as assured.

Thanks, Andris,
Clive