0:00
Put on this computer. So yeah, we are here for the hallway Hangouts. What’s next for data views and data form component? My name is Birgit Pauli-Haack, and we have Riad Benguella and André Maneiro to talk to us about the data views and the data forms component. Also wanted to just remark, we are not going to talk about any WP drama here. If you have any questions there, this is not the venue for it or the place for it. And we have also an announcement, if you want to there is the Rome core. Days are coming up in November, 8 and ninth in Rome, where it’s about core contributing and developing. And those who who want to contribute to core doesn’t have to be programming, though, and both, all three of us, Riyad Andrea and I, will be there, so we can kind of meet up there as well, if you want to. Is there anything else you want to announce before we kind of head into things? Anne, so it’s up to you. Riad, yeah, I hand it over to you and take it away.
1:16
Thanks. Birgit, hello. I’m Riad, developer on the Gutenberg Project. I’m gonna start talking about data views. I’m gonna start sharing my screen, and I’ll walk you through all the stuff that we were working on and some history, some context about the project. So the project started, like, about a year ago, I’ll say, when we started looking at the admin redesign. And so we looked at the different screens in WP admin, like the Post List, we have like taxonomies, we have forms and we have settings. And what we noticed is that most of these screens have something in common. Basically, they are screen that either render list of data or screens that need some kind of form to add data or to edit data. So to avoid creating all these screens ad hoc as we advance in the admin redesign, we decided to take an approach where we start to thinking about an abstraction around the screen. So like, this is not something new. This is like something that exists and people have thought about for a long time. But basically all these screens can be represented by thinking about them as UI on top of structured content. So for example, a post is a structured content. It has a title, it has a description, a status, etc. And then you have a generic component that says, render a list of posts or render a form for posts or things like that. So usually people call these like features API An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. or JSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. schema renders or things like that. So the idea there was, how can we implement these generic components, but without disrupting everything that without solving everything from scratch, is a big ask. So we started by taking a look at the site editor as a way to iterate on these step by step. At that time, when we started, we already had a template list in the site editor. We also had template parts and patterns, and we and we also, we were starting to work on the pages section of the site editor, but it was fairly new. And so for all these three items, we we had the room to iterate and build this reusable component and so and so. The way we started was like, Okay, let’s take a look at the pages list. We want to show a list of pages, so let’s define the structure of a page. And from there, we could say, Okay, I have the structure of page. I have the list of fields of my page. For example, I have the author, the title, the description, the status. And now I want to show these on a table, and which columns should I show on the table? So I have two main structures, the list of fields, and what we call a view is a description of the list itself. Like I want to the view could be something like the type of view is table. I want to render these fields like Title, Author status in this page. And I want to. To filter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. this list by the published for example, the published pages, etc. So all these represent an object that is called a view object, and the user can actually tweak that view object here, like if you take a look here, I can this. Can choose which field to show, which fields to hide, the sorting, the order and things like that. And this also adapts to the different layouts of the Data View. So for with the same view, I can switch just the layout type and render something completely different. As I said, we had templates that we wanted to show, the actual templates, and we had pages where we wanted more something more classic, like a table. So with the same component, you can switch the layout, and it just renders the same data, the same structure data with a different layout. But each layout can also have additional configuration that is specific to this layout. Let’s take a look at the grid. For example. You can actually define the Preview Size, which is specific to the grid, and things like that. So this component is built in a very, let’s say, extensible way. It’s basically composed of two structured objects that anyone can alter, add fields, remove fields, add layout types you can imagine in the future. This is this being used as as a base for the workflow phase of WordPress, for example, a calendar plug in or something like that. Could add a layout that is the show the different posts on a calendar or on a timeline, and actions like to approve or do workflow stuff like that. So, yeah, that’s about it for the data views, one of the this is already shipped. So whether I just show you these are like the data views for pages, the data views for templates as well. It uses the grid by default, as as you can see, and the data views for patterns as well. All these three pages, they support multiple layouts. For the page, we also support the list. This is a simple list data view, and for each item, for each layout, they also we also support actions. So let me talk a little bit about actions. So as I said, we have a list of items. So each item, you can apply actions to it. And so an action is basically a callback that receives the current item that is selected or applied, and it does something about it. For example, I can remove this. The move to Trac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. here is an action. The edit is an action. The view is an action, and the actions can support bulk editing by default. So if I select multiple items, you can see that I have three items selected, and I have the move to trash Trash in WordPress is like the Recycle Bin on your PC or Trash in your Macintosh computer. Users with the proper permission level (administrators and editors) have the ability to delete a post, page, and/or comments. When you delete the item, it is moved to the trash folder where it will remain for 30 days. action that is here. This is the exact same action that applies to one it applies to multiple elements at the same time. So that’s what we have. That’s what we shipped at the moment, but at the same time. I don’t know if you if there’s any question, feel free to stop me or anything. I’m happy to take questions and discuss these things, but if not, I can continue and show you what we have in progress. We have multiple experiments now in projects related to data views, one of them is the ability to create custom views. For example, let’s say I want to create a view page by admin. So I want to show a list of stages. Maybe I want a table instead, and I want to filter this list for with the author is admin. So every time someone comes here, creates a custom view, and I can save my custom view if I refresh the page. Now my custom view is here. So this is basically you can create admin pages as you wish. Later down the road, we want to allow the ability to actually customize also the menu, so you could create custom views and say, This is the most important views for me. I put it in a dashboard or something like that. So, yeah, this is an experiment, not sure exactly when it will land when on WordPress core, but you can try it now by going by installing the Gutenberg plugin and enabling the custom views experiment. So as I said. We have three experiments that aren’t going the second one is more related to admin redesign. So we are planning to advance and implement data views everywhere. As I said in the beginning, the post list here is basically a data view. The Categories list is the same thing. So we are iterating to our seeing whether we can use data views to replace these things. So you can enable an experiment in Gutenberg called the post data views experiments. This is very early, so it’s very buggy and stuff, but just want to show you what we were doing. So if you click on this post page, it’s actually the post list using a data view. So this is my post list. I can open the post editor, make some changes, go back to my list as also support custom views and default views provided by WordPress, just like the pages database.
10:59
This is still very early. Obviously, we cannot just replace this one. We still need categories, tags. We need extensibility to open extensibility. But yeah, that’s another experiment that is ongoing. And the last one, which I think is very interesting, actually a big project, is about the data forms. So data forms is, let’s go back to the site editor, to the page, to the table. So here we have a list of pages. As I said in the beginning, we have fields that define what the page is, so we can easily generate, let’s say, forms or panels to be able to edit these things, like to recreate the Quick Edit functionality we have in doubt the admin and so if You see here, I have another experiment that is enabled, which is called Quick Edit experiment. I can open this Quick Edit panel. I can select a page and make modifications here right away. So it’s like a Quick Edit. The interesting thing here is that this panel is actually not a custom UI. The idea is to be able to generate these automatically from the fields. And as you can see here, it showed like the panel, because the goal, like the design goal, is to be able to recreate what we have in the editor here, what we call the Document Inspector. It’s the exact same thing we want to recreate with this generic data form component, but also the same data form component has what we call layouts, just like the Data View, so you can use it to generate regular form. An example of this, I can show you on the this is the story book. If you don’t know what storybook is, it’s a tool we use to develop reusable components and to show them and to show how we can use them. We have stories for both data views and data form. I can open the data form one it’s here. So as you can see here, I can show you the code maybe first. So this is the code for that data form, story. I’m defining a list of fields, like a title. This is list of pages. So I’m defining the title the order a date I can like, this is random fields, basically an author just add a label for a field, a type, and some configuration, like, for example, the available elements or things like that. And then the next thing is to define what we call a form object. It’s just a simple JSON object where you can say, I want to render these fields in my form. I use the component here, data form. I pass my form object. I pass my data and the field so the structure configuration and it generates this form automatically, like I don’t have to recreate this UI manually, and if I want to, as I told you, we support multiple layouts for forms, so I can switch here for to a panel if I wanted. And this is the exact same form, but rendered as a panel. This is what we use for the quick end experiment. So guess that’s it for our current work. We are iterating right now. On this. So this is our main focus at the moment, like data form and Quick Edit, but Yeah, happy to take questions address whatever is related. Thank you.
15:20
Yeah, yeah. Well, it’s a, it’s a hangover from the from the pandemic. So I have two questions, and I put them in the chat. So one is, it was, it’s very exciting for me to kind of see that, because all of a sudden all the admin stuff really opens up to new development and to looking so much more modern, and helping a user doing all that what they need to do now, which is a that’s probably a 10 year old interface, right? Yeah. So one of the first questions that I had when you were looking for the well, going through the different layouts, like a table layout, the grid layout, are there any ideas on how to add additional layouts for that? Like you, you mentioned a calendar. That’s not possible right now to add a calendar as a layout function there.
16:20
So, yeah, it’s it’s not open. The API is not open because we are still iterating, and we don’t want to rush into opening an API that is not ready. But it is built in a way that adding layout is definitely something that we want, like it’s a possibility. Basically, you can think about it as a layout is a component, a React React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces.
https://reactjs.org component, your register, and it takes a list of items that your data. And it takes also the configuration, like the available fields, what I don’t know, what the description of each field, the label of the different field, lecture, and you can actually render the list the way you want, exactly. So it’s just a separate, generic component. And yeah, at the moment, it’s not possible to register this, but this is definitely one of the extensibility APIs that we want to offer. As I said, I didn’t mention too much extensibility, like when I was showcasing but there we are. We built this to be able to, like, extend it in all ways possible. So the basic way is adding and removing fields, right? So you want to add a field and you want to remove it. But there are also other things we thought about, like adding actions. You can add an action, you can add a bulk action, you can remove an action. The other extensibility API is at the form level. Like you can say my feed title. I don’t want to use the regular string data type to be able to edit the title. I want to use my separate control that is a select box, or then I’m going to fetch titles from a lot of places, and like using the REST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”)
https://developer.wordpress.org/rest-api/, or something like that, just coming up with stuff. But this is also an API that we want to offer registering controls. Let’s see like field types, okay, right? And the other one that you mentioned is layouts. Yes, layout is an important one. Like, through, like, you can imagine, like, Canva and layout, or like a calendar or a thing. Like, it shouldn’t be that hard, like it just registration based API. So, yeah, at the moment, it’s more like about the timing. I we’re not sure yet when we will think like a data views API is stable enough. You can already use it in your plugins, because it’s an NPM package. So you can install the NPM package in your plugin and bundle like in your own pages and things like that. What you can do yet is hook into the existing data views that are in core and, like, add your own fields and things like that. But this will come, like, fairly soon. Yeah.
19:11
So
19:12
about extensibility Ria, if I might just say something. Can you talk a bit about how you think about sensibility in terms of, well, you wrote and published a post recently about some of our practice, and you mentioned semantic sensibility. And I think the actions showcase is a good example of how you know about this, how you raise your own action. And it shows everywhere, if you just condemn that, I think that might help people understand how you think about sensibility.
19:47
Yeah, yeah, that’s a good point. So yeah, in Gutenberg, basically, we have this principle that we don’t want to when we build extensive. APIs, we have to be as semantic as we can. What that what does that mean? Exactly? It means that we don’t like API that says, add the button to this area of the page. That’s not a semantic API. That’s an API that is very specific to the current design of this page, like if I move this side bar, for example, to a header The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes. later, or something like that. The the plugin is going to break because the API was specifically meant to render on this part of the UI, and this part of the UI doesn’t mean doesn’t exist anymore. Or what can this create? Is also it can create a frustration, because for core we won’t be able to actually make changes anymore to that UI, so we’re kind of stuck in the UI. That might be not ideal because of some new use cases. So what we prefer is more like semantic APIs. Is like registering stuff. So when you register an action, you register something, then it’s meaningful or an action. What is an action? An action is like something that can happen on an Item. An Item can be a post or a site, or like a template. So an action, whether you render it in a menu, as I showed, like in the drop down for each item of the table is gonna work the same way, whether I render it there, whether I render it into both editing tool bar in the button, or whether the grid view decide to render it on top of the of the preview, or things like that. It’s it’s just gonna work regardless of how the page is being built. So, yeah, that’s the point about semantic APIs.
21:46
That’s very interesting. Yeah. Thank you so much. So I had another question, and it might not fit right in there, but I have seen quite some feedback from people that want to create also meaningful category The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. pages and what they would need So, and you were thinking that, okay, so we are going through the post datas, which is also categories and tags and all that. Are you planning to also add the block Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor to the description fields? When you do that to allow blocks in on those pages or content, or are you kind of more strictly? Okay, we want the text information there, rather than also block markup.
22:37
So I’m not sure, like if I understand the question probably like, people want to be able to design their categories pages as like using the block editor. So I’m not sure if that means adding block editor to the description of the categories, because a lot of people think about that. I think for me, it’s more like about allowing the site editor to create templates for these categories and, like, render them properly there, which I think is kind of already possible, but maybe we like the UI is not as optimized for that, and maybe It’s just some small tweaks to allow that, yeah,
23:22
okay, yeah, no, I can see that, yeah, yeah. So any other questions that are telling me you have any questions can be, yeah,
23:33
I’ve got a question on the data, views, field types. Currently, there’s just a single field type, and they used to be an enumeration field type, but I believe that’s been deprecated in because we already have the options you can apply to the field. But I was just wondering, do you have any plans on providing like a default set of field types instead of having to register your own React component and use that instead. I
24:06
want to take this Andrea, maybe this
24:10
area Sure, I just was trying to find a link to share. So yeah, we had enumeration enum type at the beginning, but it was fairly limited. It was only for you to create a filter, so we deprecated that, and now use elements so you provide a list of values for the filter to be created for you. But we are working now on defining field types, and we have, I’m going to find the link here. We have, we have three, I believe, integer, text and date, yeah, finding the link and and the idea is this field types is that if you create a field and say, Hey, this is your type, text. It creates for you a set of functions, like the sorting is auto generated. Validation for the Quick Edit Form is auto generated, and other things, right? As a fill, also author, you will still be able to override, overwrite those definitions, right? So this is a long way to say, yes, we are working on field types. They are not yet mandatory, but we are trying to make them so, and I’m gonna find the link and share in the chat for you,
25:37
just to add something there. I think what’s important, like, and that was not mentioned before, is that we are working with the assumption and with the constraints, basically, that all these configuration objects, we want them to be serializable, like for 80% of the use cases. What does that mean? That means that, basically, ultimately, we want PHP APIs to be able to create these things like register fields and like register actions. You obviously have to register a callback, but really not actions, but most of the rendering, you should be able to do it in PHP, but for special cases where you want some special interactivity and things like that. You have to go into an override the default field types and the default renderings and provide your own components. But for most use cases, you won’t have to care about that at all. The user could, you could do it with the UI, and you could a developer can do it with PHP.
26:41
Yeah, if and if I can just share my screen just for a bit and show you my editor. This is the story that we had showed before about data form, and you see the type being used here. This auto generates all the things that the field needs for you, right? As I said, is not complete. It doesn’t it’s not mandatory yet, but, yeah, we are working towards having that available,
27:13
right? So, but that’s more for data forms, or, sorry, data the form of data forms, I don’t know. Yeah,
27:20
it’s for both, because at the end, so the fields are shared between data form and the Data View, okay, are the same so they they have, they share the same API, all
27:34
right, what’s true is that, at the moment, the field types don’t offer, like, a tail or rendering, default like, for example, when you say, I have a date field type, you should expect to define the format somehow and have it rendered without having to actually write a component for it. I think that’s use case we want to address. It’s not it’s not there at the moment, but it’s definitely use case we want to address.
27:58
Yeah, because that was one of the things that we ran into when we want to reuse the same components multiple times or the same layout site of the column, for example, that there was no feedback on which field you were currently in. So we had to do some querying, create an extra function around it that got the field ID injector so we knew what data to get from the data source. So if there are in the Future Ways to register your own field types that can still find their own find their own data in the data source, that’s, yeah, that would be amazing.
28:37
What I haven’t seen yet is and what forms always brings into my mind is, how about validation? Is that also something that is kind of built in into the API? I haven’t seen it. That’s why I’m asking.
28:54
There is actually a very light validation implementation in the data form component, but obviously, like as with everything else, what our approach there is, let’s implement the use cases we need for core. Let’s get some feedback from the developers and then add the features that we need. We We are certain that we need some kind of validation library built in into the component, or like something that connects with the component easily, but yeah, right, right now we’re just not there. Okay,
29:35
cool. There was one question, and I’m not quite sure how the context about it that I saw on Twitter multiple times that was, is there a way to use the data views also on the front end? Right now, it’s all in the admin section. But is there something that could be on the front end? Yeah. Or is there thinking about it?
30:02
I actually saw recently, like, maybe, like a week ago, an experiment of a block called connected data use block. So it’s actually a table block, or, like a grid block. You connect it to a custom post type WordPress can hold and display many different types of content. A single item of such a content is generally called a post, although post is also a specific post type. Custom Post Types gives your site the ability to have templated posts, to simplify the concept. or to a REST API that serves JSON or something like that, and it just renders in the front end that lists. You know, I think there is obviously a need for that. My small like demo was like, data views is a React component. It might be a bit heavy for some front end. So, like, in terms of vendor size and things like that, I think it’s actually good for, let’s say application type of website, like, you know, like some websites do, a lot of this is a list of events, or, like, people interact with them and things like that. I think it can be good for this kind of use cases, for more regular websites and things like that. I would discourage it personally, but I think it’s very doable to have, like connected data form or connected data views or things like that.
31:19
Yeah, it’s probably easier to just kind of read out the data in JSON and then render it through a table, table block or something like that, yeah, and build a separate component about it. Yeah, I can see that
31:32
quickly flag. I WordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. us. I actually talked to a gentleman about this, and he has a plug in or a site called Data kit here, I’ll just put the link in the chat. Oh, that’s you.
31:46
Yeah, you probably know security, yeah, sorry
31:53
about that. Well, there we go. I remember, yeah, exactly.
31:57
I just wanted to say that we are indeed creating a plug in currently called Data kit. You can find it at data kit.org and it’s it’s a PHP software develop kit around data views, and it also has a WordPress plugin. So the idea currently is that you can basically hook up any type of data source. So we have some connectors for CSV files. Since we are a gravity forms based company, we also have a Gravity Forms connector, just a plain old array could be the data source. So we’re currently looking into ways to expand that. We also connected ws form for example, which basically you just create the data source, and you set up the form or the view with some PHP code. So you don’t need to know any react. You don’t need to know any JavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser.
https://www.javascript.com. It’s just your PHP. You register it, and then you can place it somewhere with a short code or a blog. So yeah, that’s and then you can use it on the front end. It works pretty well.
33:07
Yeah, excellent, excellent. So any other questions, ideas? Yeah, we got them. I will share a few links with the recording that rihan kind of helped me put together about extensibility, about the issues on GitHub, about extensibility, the data use, the data forms, tracking issues and how quick edit works, and Data View supposed, and then the documentation link. And then I really would suggest, recommend for anybody who wants to kind of get the hands dirty with it, two articles on the Developer blog that are written by Juan Juan Margarita, and it’s two parts. One is how to set up the data views on your own plugin or your own page, including how to set up a React app on your for your plugin. And the other one is how to register and execute some actions with the data views that you had. And it’s actually a very nice example on on reading some images from from a third party so source, bring it in, into your admin, and then decide on the pick the pictures that you want to add to the media library. So that’s kind of a whole it’s that’s a great use case that gives you a lot of big range of how to act with the data views and and for your plugin, yeah. So
34:43
go ahead, yeah. Just wanted to, like, encourage people to, like, try and give us the feedback, because we actually need the feedback. Like, we cannot release this API publicly on WordPress. We. Without proving it, because it’s a very big API. It’s a very impactful API. So it’s like, it’s for me, in my mind, it’s very similar to, like, a block API. It’s kind of same level. So I think we need, like, as much feedback as we can get there. And yeah, please do share.
35:18
Yeah, it’s also a very big component. Yeah, are you having plans to kind of slice it out into smaller components, or is it something that’s it needs its complexity as a whole?
35:32
Now, that’s a good question. Like it’s actually two components right now. So data format, data view, but the data view itself can be a composed component. So right now, when you render a database which renders the list, but also renders like the Filters area, it renders the configuration area, and all of these actually can be composed. We we probably will split it into smaller, composable components if you want more advanced use cases?
36:01
Yeah, I think it will be good. Yeah. Nick, did you have another question?
36:08
Yeah, this might be going beyond this conversation, but there’s just, I’m very excited about data forms, mainly because there’s so many, you know, custom plugins authors out there that have, you know, Custom Settings pages and, you know, just things that are all different, right? They’ve all rolled their own solution for various things. And I am excited about having kind of, like, a standard solution that people can, like, adopt and use, and then everything feels very uniform. It’s not like you go to different sections of the admin and it’s just looking, you know, completely different. So long term, maybe you covered this. Sorry, I arrived late. In terms of, like, a rough time frame, at what point do you all think that the admin or the site editor kind of interface will be ready to start allowing for people to add additional content types, you know, custom post types or whatever, into that, we think in like a year, two years, you know, what would be the back of the envelope? Guess?
37:26
Your feet to the fire. Yeah,
37:30
it’s obviously very hard to give an answer there. What I will say that we just landed the new private API, which is gonna probably open on Gutenberg, plug into for experimentation to add new pages to the site editor. Like you can add register pages to the site editor, but like you mentioned, custom post types, I would say custom post type is something that should be baked in. Like you register a custom point type. It just appears like the data used for it disappears and things like that. And about timelines, my hope is a year. Let’s say this is very quiet, but it’s also not, I guess it’s depends on the priorities of, like, the road map and the project. Like, if we want to accelerate there, we will accelerate there. And it’s just yeah, I cannot give you like, yeah,
38:31
no, I understand Yeah. From, from a from, like, a workflow perspective. Let’s say you’re, like a custom developer and or in plugin developer, and you want to start exploring this, but you also don’t want to necessarily kind of waste time. And I mean that in that like you, let’s say that you incorporate data views and data forms into your custom admin whatever. Will that work be relevant once the ad, you know, once core progresses, like, will that be able to you? Will you be able to translate that work that you did in incorporating data views, once the extensibility APIs are ready and you can bring that into, yeah,
39:19
that makes sense. It makes sense. Yeah, I think it will. So basically, just right now, if you want to build Settings pages with data forms and like these APIs, you will probably have to register a new page or new script and render that script on that page or something like that. So the difference will be instead of registering a new page, and like in PHP and like in queue, the script, your own script, you just remove the bootstrapping, but you keep the UI the same, and you just register a page into the whatever pages API we offer. But I will also say that May. It will mean, it will mean also removing code, because some of this might be abstracted even more in PHP. And you could say, okay, these are my settings, and that’s it. Do what you want with it, you know? So I think, yeah, it’s probably food future proof, if you start doing today, like rendering a data form in a custom page, but it might be easier in the future,
40:28
awesome, and I think that was kind of my expectation, but I think that there’s some hesitancy among I’ll speak for myself, I have a plug in with a massive Settings page, and I need to sit down and convert it out to data form. But it’s like, you know, understanding that the work that you do, putting into it, you know, is somewhat future proof, and you can migrate that once the core is ready. And so if anybody’s listening to this, start experimenting now. So you’re somewhat future proof.
40:56
Yeah, we
40:57
need you to start the experiment now.
41:02
Hmm, alright, yeah. So any other things that you want, apart from get your hands dirty, get in, experiment things and yes, tell us what other field types you would need and all that that would probably help too, because right now you only have three field types here, so there might be a need for others as well. Yeah. Any other thoughts at the well, we’re not at the end, but we could kind of close it here. I think it was a very good demonstration and a good discussion. Any other thoughts from read or for Andrea or so?
41:45
I have a naive question, because I have not looked into this enough, and so forgive me, but with data forms, can you have the like I’m looking at the story book now, you know, with text fields and radio and so on and so forth, can you add your add other components into that?
42:05
So, yeah. So right now the data form is you choose a layout and you you choose the fields. And we are thinking about changing that a little bit, instead of choosing the layout and choosing fields where we’re thinking about for each field. You choose a layout so you can mix and match, right? So you can say, this is a regular form, this is a regular form field. This is regular form. This is a panel, which means, basically a drop down when you to open the form field. And I guess ultimately, the same way we think about registering layout for data use, I can see as opening an API to register custom layout for forms. And you could say, I want to render this in tabs, or I want to render this in like a field set, or I actually think we will probably absorb a lot of that in the component itself, like tabs and fields that feels like common enough that we should absorb them, but it’s always the same approach, have the default baked in and allow registration like semantic APIs to extend it, so I think it’s going to be possible. Okay, yeah,
43:25
extending, extending a bit of that that was for the layout, for the controls, is the same thing, like disconnect with the conversation we had before about types. If you provide a type for a field, it creates a control for you, but you you have a few ways to override that. You can say, hey, I don’t want this control. I want this other that is also register. But what if it is not register? Well, you can create your own by providing an edit function as well. So it’s the same as we had mentioned. Provide a good default, and then people can override in a variety ways.
43:59
Okay, so just to take that little further, so let’s say that I have, using a real, real world example, I have in my settings page, I have, I’m using the color picker component that allows someone to, you know, choose a hex code or whatever. So in the context of a data form, is it? Would it be possible to render, for example, a color picker component?
44:32
Yes, I can share my string. So the idea is that these are the fields. And as I mentioned, you know, you provide a type, but you can also provide an a function. And this is a way to say, hey, the component for this type was an input control, I believe, but I want to show a radio here. However, you can just write here your own function component, so if you have color. Pick it wherever that you can reuse from somewhere else. You can just write here your function component and use that color picker that you wrote. We don’t have that like bundle. You can say, hey, this is a color. We don’t have that yet, but we can just, you just can write your own in a function. So, yeah, awesome. Very cool.
45:25
Cool. I guess I should start building something.
45:30
Yeah, the idea, the idea is that, you know, this is providing the basic plugs that we have been using in some pages in the site editor. So it doesn’t aim to be super complete yet, just cover our user cases. But also, you know, letting others implement their own thing.
45:50
Yeah, absolutely. I think that there’s definitely going to be some edge cases of getting something custom, yeah, but yeah, it’s cool that you can do
45:59
it. So at WordCamp cars were there was a developer from Yoast called Lars gersman, and I think you know him, and he had the idea about a Jason schema, to give an kind of a set of properties, and then automatically, kind of create the form and everything. Is that something that you have been look I know you have been looking at it, but how do you think that that actually could make it into the data user, data forms? Is it something, or is it a completely different direction,
46:43
and it’s actually very related. So we actually discussed with Lars for some time. I think it’s the same idea, basically, for of data form, like the JSON schema, render is the same idea as a data form. You provided a JSON schema, which is the list of fields that we have, and you provided a render configuration, which is the form object for us. So it’s the same idea. There is the reason we didn’t go full on JSON schema approach, because these are existing libraries that to test in schema and they don’t adapt well to the data views. And we wanted to share the exact same structure, the exact same configuration between the data views component and the data form by allowing the extensibility so but yeah, it’s basically the same idea, and I think we discussed with Lars and his expertise would be actually very helpful here.
47:44
Yeah, alright, cool. No, I’m looking forward to that, but it was really neat, fun from his demonstrations, yeah, but he was, his examples were a little further than Yeah, so it was very cool. Anyway, I’ll share the link to, oh the Yeah, the presentation from Laos was unfortunately in German. So I think there might be an English one out there to be a more inclusive for everybody else as well. But yeah, to kind of think about it. So Nick, you got your questions all answered that you can think of now
48:24
I was, I was hoping for them to tell me like it wasn’t possible, and then I wouldn’t have to go do build now that it is possible. No, I got some work to do. Yeah, so how about
48:38
you? Yeah, I have one question, will the forums support conditional logic like I want to for data kit. I want to be able to register data views so people can show them in the in the front end. And I really want to use data forms as the backing admin, because it just makes sense to create data views within data form. So just to complete the world, but one of the things that is important for us is like, if I want to have a CSV data source, for example, I want to be able to pick that first. Like, what type of data source I want CSV, and based on the selection I made. I need a different form input, like I need the media library, for example, to be able to pick the file, or I need to be able to provide a URL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org to an online version of that of the same file. Or if I want to provide a gram reforms data source, I want to be able to pick the form, and I want to be able to pick the fields I want to show. So, yeah. Basically, the question is, will the data forms component support these like conditional logic things,
49:55
yeah. And do we also, I was thinking of. About Next plug in as well, like block visibility, which is, I think also rules plug in, they kind of ties into that. I think that’s a good use case that you’re bringing. And actually, we have also some friends from move that are bringing the same use cases to us, like, for like, they want to try data form in product editor, and they have a very similar use cases. So yeah, my hope is, yes. My hope is that we will have like, rules engine baked in into the data form component somehow. Yeah, come and help us build it.
50:39
Yeah, one thing, one thing that I can share is that I don’t know if we’ll cover all the cases that people mentioned about conditional, but there are some basic ones that we need to cover in terms of the form. Like, imagine the typical situation where you have a con a country input control. So depending on the value of that control, you need to show other values in other controls, like region or the city, that that kind of experience is not there yet. But yeah, that’s the kind of thing that we are hearing from, from you also, yeah, yeah. Cool.
51:13
That’s also a use case that quite a few form plugins haven’t really solved yet easily. Yeah, all right. Nick, next question,
51:24
no, I’m sorry. I was just you’re done.
51:29
All right. Well, this was wonderful. I learned quite a lot. And thank you so much for the time, Maria, then Andrea, and thanks for coming to the show, Nick. And what’s your name? Again, I’m I know, but Duke, yeah, Duke was close there. And yeah, and thank you
51:50
for the pleasure. My name often, so
51:54
yeah, we’ll have the recording in in a couple of days on the core make blog, including all the transcript, of course, and the links that you all shared in the chat and Well, thank you all, and you all have a great day. Was wonderful.
52:13
Thank you. Thanks. Bye.
52:16
Bye.
You must be logged in to post a comment.