Imagine a case - there is a datasource item, that has a Droplink field to pointing to another item, let's say a Rich Text with an address (as on an image below):
That means, in your rendering variant you simply use Reference Variant Field referencing an item behind Rich text droplink, and within that Rich text item you simply render a field, as normal:
Seems obvious, right? Let's increase complexity!
Scenario one
We change scenario so that Droplink would now point not to an item having the field to render, but rather to an item, containing other children you might need to display:
So instead of referencing a Rich text item, we'll reference Link list item, where you need to iterate child items (links) of a referenced Link List item, and show all these links on a page with a rendering variant:
Question: how do I iterate children of my referenced item?
Okay, that's where your new friend comes to help you. Welcome, Query Rendering Variant Field!
What it actually does is also switching a context to a single item / multi items, similarly to Reference Variant Field, but instead of taking switching context from a link-powered field, it uses Sitecore search query and switches context to its execution result. Here's how one can add Query Variant Field into a rendering variant:
So for my simple example with Link List children, I use a query to search all the children of a current item (Link List):
That does the job and withing this query item you may use fields related to items coming out from a search.
One more helpful tip: when working with references, queries or whatsoever changes the context, you would often wondering iа changing context worked well and referencing what you intend to. The trick I use is inserting a debugging template field exposing ID and/or a name of where we've switched to (or any other universal property all the items do have and that are accessible from NVelocity $item):
This takes only 5 seconds of my time to implement but immediately helps to visualise a context on output. Very helpful!
Second scenario
... where Query Field Variant helps me so much. I need to implement a Subscription Level identifier on every page, so that it shows which privilege a current user has (obviously, he/she will see an only single one of the labels show below at one time):
But there is a requirement for that labels itself to be changeable and kept somewhere under site's settings item - subject to alterations at a later stage. So I already have a separate folder with such items:
With using a Reference Variant Field one would need to have rendering having a datasource item with a field pointing to one of those subscription items, which is not an elegant scenario. And what if my rendering does not accept datasources? Or it simply breaks sense, as in a described scenario?
Since we know the IDs of these subscription items we can reference them directly and that's where Query Variant Template also helps us. Also, search query by an ID always returns not more than one item, and since we know item exists we can use it as direct linking. That's how I do that:
Works like a charm!
I have just shown only two real-life examples of using Query Variant Field, but the potential area of their usage is virtually unlimited - as much as you can query you indexes. This gives an ultimate tool for comfy switching context as much as you may need that, but I'd warn you from overusing it too much.