 I'm going to go to the next speaker. Hi, everyone. Can you hear me? Thank you for coming to this session. Hopefully I won't make your 30 minutes go waste. I'm B.J. I'm part of the session. Before we start this, how many of you had any test run failure because config schema issue in the A? Also. So it's not a lot of people because, you know, otherwise they would hit me because kind of I did a lot of config schema stuff and probably you can't blame me for all. Alex did part of the strict test. So it can beat me half. Okay. So the structure is basically it's like a 20 minutes and we kind of doing like a lightning talk session type thing like just explaining what it is. And bit of disclaimer is I kind of extracted the type data bit from other core components. So you might not find exactly what we are seeing here in the core when you go and look at the code base. But just to, you know, make it more clear and, you know, abstract rather than putting everything together and, you know, we discussed further. So do I need config schema type data if you develop a project before we answer the question? A few examples. So this is a module called config translation module and it's part of Drupal 8 code. As you can see here, what it does is every configuration either your module specific settings or anything that you can think of config like fields, data type, everything, all the configurations you can, if you enable the module to get a tab, something like this or a drop down menu that says translate. And when you click that one, it just goes to a different form where you have a similar element but kind of a subset of it. And this is using the type data slash config schema that we are discussing today. So that's just to give you an idea of what it does in a, you know, not like a proper idea but kind of tells you it can do a lot of magical stuff. And it generated the whole form from the form that you created and the people who felt very bad about config schema test failure, the config schema is the one running behind this translation form and telling the system what are the fields I need to, I can be translated or it can be translated. So the type data is all about the metadata or metadata details about various, you know, sub components or content specific, component specific, config specific components in the code. That's one example. And this is a search API. So this is a contributed module search API which is used by solar and a few other searching providers. They use the config type data for defining our kind of mapping what are the different type of data that you are storing in the, you know, your solar. So this way you have a more clarity on, you know, what you are saving in the search system so that when you search for certain things, you know, you have a better understanding of the data stored in solar. And this is a core search API module implementation and all the other service providers like Apache Solar, they kind of use this API to extend it. Third one and this is, again, a contributed module called config views. What this module is doing is, as you can see, this module allows you to create views per config type. So the list that you see on the other side that tells you you can create a view of data format. You can create a view of, you know, custom block revisions. So this module provides a view plugin to all the configuration, config entities that you have in your system. So we are talking about creating views of views because views is a config entity. So we're talking about view-ception, you know, like you can go and create multiple views of views. And that's just one example and this module out of box replace something like a 12 admin pages as views, admin config pages as views. So, like I said, it's kind of a magic how we can do these things, but it's all possible because of the type data and config schema. And this is one of the kind of a use case or real, maybe not real real, but kind of an example how this could change your admin UI. This is a content type page where you have your content type and also a list of menus and also you have a taxonomy and content. This is a view and you attach view blocks because you can create a configuration views. You attach those blocks and imagine you have a department where they have a set of things they need to work together like a set of menus and set of content types and few content. This could be their landing page and because it's a view, you have all other goodies coming out like caching, permissions, role specific, restrictions and everything. So, you're kind of saying like you can create multiple view display. That means all the people will see the same URL but they get to see different, you know, different layout or different set of components in that page. So, now back to kind of, you know, theory part. So, these are all the things done by type data. So, now what is type data? So, this slide kind of gives you a simplest idea of type data. Type data in a very basic level is nothing but a data type. You remember we used to say like, oh, PHP is so cool because you don't need to know what type of data that you have in a particular variable. That's cool. Maybe if you're writing a one single PHP file but system like Drupal 8 or even Drupal 7, when you go to the level of creating a lot of object or a lot of different, you know, like a high complex system, it gets very complicated especially with performance and also with kind of your understanding of the system itself. So, type data is kind of an approach in Drupal 8 code to introduce data type to various components or various data. So, whenever we talk about data in Drupal 7, it kind of end up talking about entity or, you know, this is another kind of probably we need to have a session like what is data in Drupal world? Like, you know, up to say Drupal 6, we didn't have concept of entity, so notice kind of handled in a special way and user is a different, you know, special thing, block is a separate thing. When it comes to Drupal 8, we brought everything under, or Drupal 7, we brought most of them content under entity and the config becomes still a special thing. When it came to Drupal 8, we brought everything under entity and we just divided two categories, config entity, content entity. So, when you come to that level, then you need to know what type of data that you are dealing in different places because you are in a very higher level. So, this is the, you know, this is the problem that currently we have and type data trying to solve. So, if you have an entity and you are trying to save a status, the status field is a Boolean field, but the Boolean value can be assigned in a very, you know, like a thousand different ways. You can just say quotes one, you know, like that means true, and also you can just say one, or you can say true, or you can say it's like returning a PHP code function written value, or you can give something from your user defined value, and we know how we are able to define a function with, you know, Larry Garfield, like he had a session two years back explaining how you should keep each method or function to return, you know, try to return one particular type all the time. If it is an array, never return null or, you know, like a empty, just return empty array so that you don't need to check when you call that function place, you don't need to, you can do for each all the time. It doesn't fail. You can return a function, and that can return null or even a Boolean value, and then PHP kind of magically figured it out depending on the operation that you are trying to do it just to decide whether it, you know, Boolean value or not. So, but this is probably okay for one element, but if you think of an entity, you have a, you know, you have a big object entity, and then you have fields, and each fields kind of having their own type, like one is string, another one is image, having its own set of fields, which is a list type, and then you're just having each list type, each item in the list type, which is field, having its own type, right? So now we are trying to get, like, what is data type? So we are just defining basics types that is coming out of core, like a string, integers, and Boolean and other values, and then on top of it, because we are defining in a Drupal or, you know, framework level, or not language level, we have flexibility to extend to a complex data types as well, like entities, fields, or, you know, anything that you can think of in the core, or even in your custom entity, you can think of, you can define the type, and also it provides a way of saying certain things that we define differently. For example, phone number, it is still a number or numeric value in terms of type, but we, you know, we treat them differently. So this is how our, for example, iPhone keyboard appears, depending on whether it is a text field or a numeric field or a phone field, you know, like providing a context of same data type, but, you know, we treat them or we kind of handle them in a different way. So all these things are defined by the typed data, which is available in core. Okay, now back to, we kind of know what is typed data, okay? We are defining data types, but we are not stopping at very basic level. We are defining everything that's available in the core system that handles data. We're defining as a separate type so that we get more context of what it does and how it is implemented. This is another best part of Drupal 8 core. Everything that you see, everything that you hear in terms of concept, they all do different things, but the implementation point of view, they all follow same thing, plugin system. Data is nothing but a plugin. So you define the type data like a list, email, URI, they all define as a type data plugin, and then you have an option to say the definition class. The definition class is basically the data, how you handle the data inside a type, and then you can even add constraints, like a symphony constraint component, like the validation component. If you look at email type, it has an email validation on the type itself. Whenever you try to use the data, it automatically does the validation magically inside there. All you need to add is on this definition, you just say constraint, and you add a list of constraints that you want to validate with. So it's a plugin, and it has a type data manager, the type data manager, like any other plugin, it's a manager that can handle the different type data plus the data definition. It keeps them in a service so that you can consume anywhere you want to do various things. One of the example I didn't show in the previous one in the core is when you save a form, the one I showed you, like a settings form or anything, the form value getting validated by type data and it gets saved in your config file. Say if you have a settings file and the config data that you enter, the text will always sense as a string, but using the config schema we are validating the type and we are saving back with that type, using type casting type thing in a very basic level, but there are quite a bit of complex bit going on, but at the end that's what happened. We load the config schema, we load the config data and we just compare what data you're providing and we do a type casting to know what data you're providing and how you're doing it. So in this example, the UI is saying quotation one, but it is a boolean value so I'm going to make it as a true, so just save it as a true, so it keeps the more consistent config every time when you do the changes on your site. So like I said, you can define properties and you define validations and also data interfaces, so now you can think of your entities or anything that you're building on top of core, you can really differentiate or you can really define the type so that you will have a better understanding of your domain level, say stations or cities, then it can be a separate type and you can handle them in a different way. We have a few interfaces here so the type data interface is a interface that you implement when you need to implement a new type and that gets extended to complex data types, so the complex data types are examples, entities, kind of complex data types, you have a name to properties and you have get set methods, everything out of box coming from the complex data type and all you just kind of deal with it as and also because the complex data type kind of has a field, then the field is a list interface so internally entity knows it kind of dedicate the operation what field needs to do to its own type, it doesn't try to do everything by itself and then you have primitive interface which is kind of we spoke about handling URLs, it's a spring but you have a special treatment for URLs, same goes with the timestamp and then the list interface is more used in the application, you have multiple instance of data on a field and that's for the data type definition and this is for the data definition, same thing you have interface and you have a common interface and then individual item specific definition and those definition kind of define how your data is interacting, what kind of values are available for your type, so it just tells that type is more of a structural and the definition is more of how you interact with the data when you put it in the structure. So as of now whatever we discussed like most of the things we discussed are more content entities based like a field, entities, whenever we say entities probably we kind of meant content entities like the user entering data but for that you have a field level and you're defining the type so you kind of know what type that field or what type that entity so you get everything kind of as part of the different system like entity different system, field is a different system. What happened to config, so all the configuration in a way it's getting saved in the YAML file and then you use the configuration like the custom configuration or basic simple configurations like settings in the form right, config form you just save the data into the config get config set but under the system build like a field entities or like a block type or text on those things are kind of system handles it like they save it but still it's all flat YAML file configuration and we use different data storage like database or YAML depending on your needs but at the end of the day you have that configuration so how do we define or how do we tell that flat file metadata to the system so that's when the config schema come in place and I kind of gave a presentation about config schema and someone asking like I'm not sure what config schema is so I just try to come up with a kind of a simple example so if you have used the config schema in D7 you might kind of familiar with the site so you have a table and if you need to add a table then you define a hook underscore schema where you specify all the fields and the meta details about the field what that field is all about what it's holding and what is the length whether it can be null or not the config schema is exactly the same only difference is the configuration is defined by setting ml file where you have like a five different configuration like for anonymous user I think it's a label of anonymous user how it should say it and then the registration whether anyone can register or it should be someone something like that only admin can register all this configuration is defined like the config translation model using only one property here the type property the type label means it is translatable but type string means it's not translatable so string when we say string you can imagine machine names you know anything that you wouldn't like you wouldn't put it in a UI that's all kind of non translatable so if you see the register that's a string value so you won't use it but the label can be translated and then text we don't have an example for text here but the text also you know can be translatable but that's just a one bit that's just a core way of using it but it can be extended to whatever the use case that you are defining like you can add additional property to that to your use case which is again still open like what I'm talking about is something you need to think in this level and add some property that you can provide so that you can use it for your system so this is all about configs you know like more for the configuration in the system so this is why we started providing config schema so that if you look at the core you have all the fields and everywhere like it's not it defined individual part of the configuration in different structure so it may not look like this easy but the bottom line it just same it just get composed together and then it used for you know your translation and various other use cases we saw before right so benefits again this is very kind of a not a solid list of items we are talking about here the benefits more we are saying in a way what we know right now that is the benefit of config schema and type data it gives a lot of visibility of what you're you know like what you're dealing with and also it provides behaviors in terms of translation and developer experiences basically giving chain commands where you call multiple elements different methods when you talk about chain of entity, get type and then get value and then get element and stuff like that so that developer experience is purely depending on the type data and then the validation is another pure thing which is core doesn't have a lot of it so we have only for very few basic ones but you can add the symphony constraint like extend the components to individual use cases and validations and you would be able to provide your own type with the constraints so you don't really need to add a separate validation for your data once you define it in your type itself it automatically does the validation as part of saving the data so that's something we can look for and then the type has config one which is something I mentioned like every time you can't save a config form which could be any generic config or creating a field or type like that so it automatically typecast the value validating the config schema and then it just saves the data which provides a lot of consistency and also I think we do ordering as well like if you look at the YAML file the order also maintained using the config schema's order so that when you make changes it doesn't change the order and then when you try to move the config from one element to another environment you see a lot of things are changing but ideally just moved places so the config schema is kind of used for ordering the individual elements as well and then like I said translate the default configurations which is config translation model which is out of box and I put all the references especially the code references where you can see exactly what config schema used or type data is used on different projects I didn't add okay I have it the Lulabot article is amazing one if you want to and then the Drupal.org documentation is also very good for having a go through like I said the both type data config schema are kind of a massive powerful system that we have in core but I believe it's not explored that much I might be wrong here but if you explore it you would be able to do a lot of amazing things and like today's discussion like keynote Dries mentioned about creating a decoupled admin UI config schema or type data would be playing a big role on that so you can expose your configuration as an API and then that can be like that's all possible only by using the type data to provide the meta details about your API what you need to provide to save certain configuration as of now most of the decoupled or headless Drupals are like just exposing the content mostly read only some of them write as well but it's just a content entity level that can help to extend that API to more like making more Drupal fully headless and then you can have even whole admin UI as a separate javascript framework and I believe that's pretty much it and this is about generic code sprint stuff and take a survey and if you think it's good we will do it again. Thank you. Any questions? Seems like I would be the first one having 30 minutes for questions but Hi, is this one? It looks to me like this would be a great solution for what used to be in Drupal 7 your config form where you just say here's my configs please expose them would I build a form with form API and save them because you know how to save them I failed to find the API or the hooks that say given a schema build me a form it looks like that's available can you tell me where to find it? So this is kind of a future project like no one had tried. I was talking to Tim Plunkett this morning asking him if he can do and I don't know probably this week we can try. So ideally you should be with the config schema and config you should be able to generate the form without creating a custom config bomb by yourself and especially the saving part that you said so we could try having a say path in your settings itself saying this is the path I want to have a configuration and then use the config schema and configuration just to generate the form like if I say the type is label give a text field if I say type is text give a text box and you can have it. But definitely it is something that we can try like it's something we thought about it but I don't think anyone tried. Okay thank you it just looked so obvious I can see the pieces fitting together but it doesn't exist yet. It can go more than D7 right D7 you don't have only the submit handler right submit handler automatically taken care by saving to variables table I mean unless you need a type you know like a field set or something to group them together then maybe but all these things we kind of need to figure out but definitely we can do a basic one. Thanks everyone.