Your site's use case might require you to render a field directly via Twig, rather than via the Views administration interface.

Typically, the views-view-fields.html.twig file would loop through each field, providing the same output and wrapper styling for each field. However, it's often the case that the markup and styling around specific fields in a View is customized to your site's use case. In this case, looping through each field to provide standard markup for each value simply won't do.

Drupal has a built-in method to resolve this problem, allowing you to target the markup for specific fields using individual field templates, but there are several disadvantages to using this standardized method.

For one, complicated layouts can be a struggle to achieve when managing the field output and surrounding markup using individual field template files, such as if you're trying to wrap several fields in a container div, but not others. One alternative method of tackling this is to use the Global: Custom text field directly within the Views administration interface, and place your overriding markup there.

With this solution, you'd be required to hide each field from display, and then print them using the strings/tokens that Drupal provides.

Another challenge with using Global: Custom text as a solution is that this field doesn't allow completely unfiltered markup; it'll often strip any overly-complicated markup and specific tags, such as iframes, or other non-typical HTML implementation.

So, in situations where your markup is relatively complex, and where you additionally require a high degree of control over the rendering and output of your View fields, the preferred solution would be to manage this via the views-view-fields.html.twig file.

It's entirely possible to render fields directly via the views-view-fields.html.twig file, and will usually be your first port of call if you're unable to accomplish your requirements via the Views administration interface in Drupal 8, or if rewriting or global custom text rewriting directly via Views won't accomplish your goal (cue the stripped HTML tags and markup filtering).

A common reason for this is the need for very specific markup, some of which Drupal won't parse even when rewriting a field via the Views administration interface.

In such a case, it's best to manually theme the field via Twig templates in your Drupal theme.

Of course, we all know how to theme an individual field using appropriate template naming conventions, but what if you want to control the markup of all fields at once, rather than creating template files for each field on an individual basis? ... that would be a huge inconvenience if you have a lot of fields, or indeed a lot of Views which share similar template markup.

The solution is the views-view-fields.html.twig file, where you can write markup for each individual field and render it from this single file.

Essentially, this is a more programmatic way of accomplishing a rewrite that you might use by excluding all fields from displaying via the Views administration UI, and then rendering them through a Global: Custom text field in your View.

Here's the code you'll need to be using to print and theme each field in the views-view-fields.html.twig file:

{{ fields.field_custom.content }}

To render the label of the field, you can use the following:

{{ fields.field_custom.label }}

And, if you have a label suffix defined for the field, and want to print that too, you can use:

{{ fields.field_custom.label_suffix }}

Since we're hacking it a little here, it's a bit messy to get the raw field value without using Twig striptags.

So, if you need to access the raw value, sans any markup added automatically by Views or inadvertently in a field template, you're going to need to use striptags, as shown here:

{{ fields.field_custom.content|striptags }}

Of course, striptags isn't the ideal solution, but for the sake of ease and keeping the code structure of your file clean, it's probably the best option here.

PRO TIP: Keep in mind, if you're rendering a path, URL, or URI (whether for an image or directly to a piece of content on your site), you'll need to use a slightly different syntax in order to prevent commented template suggestion markup, else your a href tag won't validate, and images won't display. In these scenarios, you'll need to use something like this:

{{ fields.uri.content|striptags|convert_encoding('UTF-8', 'HTML-ENTITIES') }}

If you have template suggestions turned off, however, there shouldn't be a need for this. In any case, it's helpful to include in the event that inline template suggestions are switched on at a later date, for debugging or any other reason.

Now, I'm sure you're going to ask how to check for empty fields here. My personal suggestion is not to get into this mess in the first place, and to stick to theming Views directly via the Drupal administration interface, or using a custom field template file.

But if the situation calls for a solution via the views-view-fields file... which I'm suggesting as a last-resort, here's what you'll have to do to check for empty fields:

{% if fields.field_custom.content|striptags|trim is not empty  %}

Again, the use of striptags, and now trim, is not ideal for checking the absence of a field value. But there are scenarios in which it's the only option; if the Drupal solution is highly customized and theming Views fields using a more standard approach is in itself unideal.

So in summary, your syntax might look something like this:

{% if fields.field_custom.content|striptags|trim is not empty  %}
  {{ fields.field_custom.content }}
{% endif %}

This will render a Views field directly within the views-view-fields.html.twig template file, but only if the field has a qualifying value.