 This session is about views, field plugins, and I am Jibran Jhaaz, I am from Pakistan, and I work for previous Next in Sydney, Australia. I'm a core contributor, I'm a maintainer of contact module and shortcut module in Drupal 8. I also maintain various Drupal 8 views plugins in core, in contribe. So who here doesn't know about views? No? So, if I ask what is views, how are you going to describe that? What is a views module for you? Yeah, so the best answer I always come up with is it's a Curie building tool, like you build a Curie and then you fetch the data from database and you just display it in different formats like blog, page, panels, or whatever display you can imagine, right? So it's kind of an awesome thing about views. So then there are field plugins in Drupal, views, field plugins in Drupal in views. So do you know about views, field plugins? Because if you are, you might have not known them but you have been using them for quite a while, right? Because if you are building a view, you are adding fields and you are moving fields. So this bit over here in the views UI, these are all views, field plugins. So these are the fields we get from the database and we display in a proper format using the views, field plugins. So this talk is actually influenced by the whole new entity API and field API because if you are working with views, views, fields are there forever from the beginning of time. So but in Drupal 8, it's a bit different for entity fields and it's bit different for the fields or all the other fields which we are showing using the data table from the database. So during the development cycle of Drupal 8, we created the whole new entity API system. Initially, we called it entity ng, the next generation and we then removed the old Drupal 7 entity API system and we built the fields API on that. During that, we were also porting views from Drupal 7 to Drupal 8 as well and it was kind of a straight port but when we completed the field API system, we improved the whole rendering of entity fields in views, field plugins. So this session is actually about that thing. So in Drupal 8, we have the concept of content entities and config entities and now the view modes are the config entities and you can create them run time, you can configure them run times and you can configure your displays and you can destroy them and you can add components to them, you can remove components to them, you can change the display of the components as you like. So view display was the main thing which was the reason behind we were able to tackle this views field display, views field differently. So I did a theoretical version of this session in Drupal Camp Sydney but it was pretty theoretical so I am trying to make it interactive here. So it's kind of, you know, interactive session so try to enjoy it. So as a kid growing up in 80s, I was pretty obsessed with Voltron. So this presentation is going to be about building a Voltron, okay? So who doesn't know about anything about Voltron? Oh, a lot of people. So Voltron was a giant warrior robot, it was the savior of the universe. So, you know, as a kid, we all loved it and it was the thing, you know, and all the comics and all the small little collectible items, we loved that. So it consists of five lines which are also a robot but they are also controlled by their pilots called Pelidons. So if I look at it as a 12-per-point-of-view, so I'll see a Voltron as a giant warrior robot and which consists of five different lines and the lines are the same but they have different qualities. So one line is, you know, for the core of Voltron, other two are for the hand and then the rest of the two are for the feet of Voltron. So then they all have the Pelidons as well, which are the pilots which are, which who controls the, they control the Voltron as well. So in Drupal terms, if we talk about this, like, Voltron is a view, right? Don't you agree? Yeah, so it consists of five nodes, like, you know, which are the lines, and it's because everything is a line, so the building block is a line, so it is a single, you know, it consists of single entity type, right? Or content type, right? So, and then we have entity reference or user reference to Pelidons or called Pelidon entity as well, right? So we build, we can build a view from these lines and we can build a Voltron out of that, right? So let's do that. So first of all, we add a simple line content type and then we wanted to create a field display. We can create an entity display as well, right? We have lines, we can render them as it is. But if we'll try to render them as it is, we'll end up with something like this. It is not a Voltron, yeah, right? So this is the raw entity view output we'll get when we display the view, right? Do you agree with that? Yeah, but we want something like this. So to build this, what we do is, like, let's start with the head of the Voltron, okay? So now if we go into the views UI, we build a proper query with all the fields and all the sorting criterias and we want to add all the filter criterias and relationship, whatever we want to add. So let's build a query and we build a query and the query is there. We fetch the data from the database for this query and we get five different sets of fields, right? Which we want to render. So each data set represents a row or an entity which we are getting from that line. So now we are going to render this Voltron step by step. So in views, when we try to fetch the query result, we also fetch the whole entity as well because entity caching is built-in in Drupal 8. It's not a big, costly operation because we are just fetching it from the cache directly. So then we try to render the head, which is the first field, and we call this class Entity Field Renderer. So I'm going to get in more details with Entity Field Renderer as well after this on the next slide. But Entity Field Renderer just gets that field and all five data sets which we fetched from the database. So after fetching that, Entity Field Renderer just renders everything, all the five data sets, not just the particular field. So it renders everything on the data set and all the entities in the data set and then just return that particular and then cache that render array. So it's a render array of fields and then you just cache it and return the first field. So the rendering, what we are doing here is from using the entity view modes and entity view displays, config entities, using config entities. So Entity Renderer is just a bridge between the view field plugin of entity field display between the entity field. So let me rephrase that. So Entity Field Renderer is a bridge between the field plugin of views and the display mode. So let's get into the more detail of Entity Field Renderer. So it just renders all the field values of an entity. It is there only for entities. So as I said, entities are a big concept interpolate and everything is entity. So you can almost render anything with this. And then these are all nodes, line nodes. So this is a single relationship. If we want to add a relationship with a user or a paladin, we have to initiate new Entity Field Renderer and it will render all the fields related to that specific entity type or entity. So if we are building a multilingual view, it will also handle the multilingual entity rendering as well because we just have to pass the language parameter to the entity display mode. So once we get a field, once you get the order to display a field, it just sends the field to Entity Field Renderer. And all the data set is also passed to Entity Field Renderer. And it is then classified by entity type base and then we render all the entity types all together. So if we want to render, let's say, a lines and a block post together, so we'll render all the lines at once and then all the block post at once. And we'll keep them in the static cache. And for all the other fields, this will happen on a single time in the field of use execution for per page or per display. And for the next time, we just use the static cache result and we just show that. So what we'll end up having is something like this because we have all the fields and they are in some form and we haven't properly rendered those, but we got them in a proper format. We are using a proper formator for them. So after passing them to Render API or Drupal, we'll end up finally building up Voltron, OK? So here are some quick FAQs about, like this is the main thing I wanted to cover about Entity Field Renderer in Views plugin because we are leveraging three subsystems, not one. Like we were leveraging Entity API. We are leveraging the Field API. And we are leveraging the ViewModes as well. So three subsystems are coming together and they are just displaying the output. So which use field plugins comes with Core? So all the Entity fields are rendered by one plugin, which is the field plugin, Entity field plugin. And other than that, all the basic data types, integer, boolean, text, whatever you call it, whatever you name it in SQL, they are the basic field renders that they are in Views and they are ready to use. All you have to do is just map your data according to that and you are ready to use them in Views UI. So you can also, because of this Entity field rendering, you can also use these four matters for Entity properties and even for the field properties. Like Entity properties are called base field in Drupal 8. Node has a status property and now it is a base field which is a status base field and it is a boolean. And you can render it as an actual field. So because we are leveraging the view modes and view displays, so it's nothing different for views as compared to the config field and as compared to the field property. So Entity properties. So when we think about field properties, like Entity reference has a field property target ID and Entity reference is a field property of Entity as well, which is a computed field. So we can either render the Entity which is a computed field in a proper format or we can render target ID as Entity as a simple ID as a string or in whatever way or whatever format we support. And if we want to add, use different other properties, like image field has FIDs and URIs. So we want to display the URIs so we'll create a new formatter which in core we already are doing. And these views for these field formators are only used by fields for views fields. No other field is using that. No other display mode can use that. You can only use them in views because you just want to show the URI, this particular information. So when to create a new field plugin? So whenever you are creating a new field or whenever you are creating a new data type which already exists, if you are creating a new field and it is relying on existing data types which exist in Drupal 8, you don't have to bother about this. You just have to create a mapping for that. That it's a field and this data type is this and views will handle that automatically because the data type already exists in Drupal 8. But if you are adding a new data type, then you have to add a new field plugin. Or if you just want a computed field, like you want to show another view as a field. So it's totally doable. So you can totally do that as well. You can show another computed field if you want to show just node link, which is not a property or node-based field or any field item. So you can create that as well. And core comes with that. But let's discuss about if I want to show a particular view in a row of views field. So what you do is you create a, I think the contrast is not good, can you see that? So you create a hook views data or views data alter and you create a mapping and you add a field to that. So the main thing to notice here is the ID of the plugin. So the ID of the plugin is view. So now we are going to add a views field plugin with this same ID. And we are going to drop that in our source plugin views fields in directory, views field directory. Because it is very important for the auto loading and PSR4 to have that plugin in the same directory. And then we define our namespace and we use our annotation views field to add this ID which we have defined in the mapping. So this ID is similar to this. And then we use the base class. This is the absolute beauty of object-oriented programming in Drupal 8 that you can use a base class. You can extend that and you can write your own class and you can override any method and customize your display. So if you want to see the whole code, you can go to Drupal.org and it's a contributed project. And this is a whole big class and it is overriding a lot of base class methods. So you'll get the idea how you can build a proper custom field plugin for views. So another question, how to leverage entity caching in the field plugin, views field plugins? So as I said, when we fetch the data from the database layer, we also fetch the entity and we also fetch the relationship entities. Like if we wanted to display a Paladin on the same row, we also fetch the information of that Paladin and we also fetch that entity, Paladin entity as well. So in this way, we are already leveraging the entity API, the entity caching system which we have in place in Drupal 8. So if you want to leverage that, you just have to use that particular data set and particular entity which is already there for you to use, whether it's an actual entity or the relationship entity you are going to use. So just don't try to do another DB queries kind of stuff or entity field query stuff. You can just use the existing entity and it's a proper entity. You can do any operation. You can access any information on that. So how to use views row caching? So in Drupal 7, the views rows are not cached properly and there was a Qtip module for that to handle that. So there is this concept in Render API of pre-rendering that in which we just, before rendering the actual stuff, we just send a placeholder. And after the rendering calls are called, in the post-ender, we just fill up those post-ender because those are the actual operation which are closely memory consuming. So views row caching allows us to send the placeholder for that row that in this row, we have these fields and we have this entity ID in this row. So we don't send index or anything related to that. And we also add the access parameter to row because if I'm an admin, I can see the first three entities on a page. And if you are a normal user, you can't see those. So we don't have to add the index of the row. We just have to cache the information in that row. So we just cache, we only cache the information in that row. And we use them in post-ender. So all the system was the idea in Drupal 7 which we are using, which we were using in Qtip. And a lot of people were familiar with that. But now in Drupal 8 what we did is we added that in the view render pipeline as well. So with cached tags and with our cached tagging system, we just bubble the cache data. And for that, we bubble from the entity view mode, we bubble the field values. And the field plugin bubbles all the data to rows. And then rows bubble all the data to display plugins. And then to view and wherever we are, we are viewing that view or showing that view. It will be added to page and so on, so forth. So in that way, we have already added the view row caching, which was a Qtip project in Drupal 8. And it is a huge improvement, performance improvement in Drupal 7 and Drupal 8. So how to integrate render caching in views field plugin? So render caching is a very important concept in Drupal 8 because we have a lot of database and memory consuming operations in the page display whenever we display a page. So render caching is very important in that aspect because we want to cache the response and we don't want to do all the cost repressions all over again and again. So as I said before, because we are using entity view modes, so we are getting the tags from the entity view modes, which are bubbled into the fields and then the fields are bubbling them all the way up towards the page. So if you are overriding any method in your custom field plugin, just make sure that you merge the cache tags, existing cache tags, and you bubble them all the way up as well. So for the performance regression, as I said earlier that you don't have to do custom queries, entity field queries, and stuff because they will be done for every row. And if you are showing five or 10 or 20, 30 rows, it will add overhead and it will be a major performance regression. So always try to use the existing data which you have been given with the views, rows, and views data set. So how to fix views field caching problem? Like I said before, if you are overriding anything related to the cache tags or message, you just merge them. You try to bubble them towards up and it will be picked by the display plugin and the view and you will be all right. But if you miss that, it will be a huge performance impact in your rendering and in your display. In your, it will be a huge impact. It will have a huge impact on your site's performance. So always use those very carefully or overwrite them very carefully. So any questions related to that? That's the end of it. You can join us for the contribute sprint on Friday. This is the information for that. And thank you. Please evaluate the session on this. If we're just displaying one field from an entity, it still renders every field on the entity? No. No, no, no. So what we are doing is we are just rendering. We are just rendering all the fields on the view. Yeah, yeah. On the first, whenever we call it for the first field. And then we just return them one by one for all the fields. And then views field plugins always does its work on that. Like if you want to do a advanced rendering, if you want to display as a link, if you want to trim something. So actually, it got rendered as a part of Formatter. And then we modify that during the rendering process of view. Anything else?