Combine multiple custom-types in single query

Developing with Prismic
,
1

Hello there,

I'm working on a project that uses the Nuxt 2 Prismic API client, and was wondering if there's a way to use the query filters to search for a UID that could be in multiple custom-types.

Here's the usecase:

I have a document that could be found on several types, and I'm querying by UID without knowing the type in advance.

so for example:

/news/lorem-ipsum
/event/lorem-ipsum
/release/lorem-ipsum

who worked on the project before me opted for executing three different requests, one for each possible custom-type, and filter out the successful one. The problem with this approach is that it generates a massive amount of requests, and we want to optimize that.

Would it be possible to combine all the possible types in one single query?

something such as

any(document.type, allPossibleTypes), at(document.uid, lorem-ipsum)

reading the documentation, it seems that when querying at a precise document UID, one has to know the custom-type in advance... I wonder if there's another way?

thank you : )

2

Hi Francesco,

Welcome to the community :slight_smile:

The only option based on what you want here would be to do any query on the IDs for these docs rather than the UID:

Although I'm not entirely sure of your use case of having the same page in different Custom Types, as the custom types should have different structures and, therefore, be rendered differently.

So, if you tell me more about your exact use case with context (What are your custom types for? Where are they queried? etc.), I will be able to guide you to a better strategy for optimisation.

Thanks.

3

Hey Phil,

thanks for your answer!

Indeed, the only option seems to query on the IDs, but unfortunately for how the frontend is structured I don't have these properties at hand.

As you said, in our use case the different custom-types serve to render different kinds of page. The specific configuration is something like this:

There is a page /news, where I get a list of different custom-types documents. For example events, webinar, conference, and so on.

Each element of this list is used to build a link to the related page, using its uid i.e:

/news/lorem-ipsum

The dynamic page /news/_uid uses the uid to perform a query on the UID for every possible news type and returns the successful one.

The way we are addressing this at the moment is to include in our query the info about the custom-type, that are available in the list of documents built in the news page.

We devised three possible ways of dealing with it:

  1. to use the internal state of our nuxt application to store the custom-type between the navigation between /news and /news/_uid
  2. to add some query parameters to our url, such as /news/_uid?type=event
  3. to rewrite the structure of the url, including a dynamic type in the url such as /news/event/_uid

the third option would solve most of the problem (also considering SEO and optimization) but unfortunately it will affect the structure of the website, and that's not small feat.

as a compromise we are now considering the first approach, using the Vuex state of Nuxt 2. It doesn't solve the server side problems, or the amount of requests on hard refresh, but it's almost invisible in the client side and doesn't affect the website structure.

4

If you're building a news page that pulls in multiple types, you should only do one query for all the types:

Then, loop through each result, as seen in our sample project:

Then, for each news item, you build a card component for which you only need to pass each result to the prismic link component, which use the link resolver to build your links:

The above will build your news page with one query. But yes, for each news item page, you'll need to do a query by the UID. I realise each one of these is an API query, but if you are statically deploying your website, this shouldn't create too many requests and help SEO. Unless you try the project state method you're suggesting above but it's not something that I've tried before.