[{"data":1,"prerenderedAt":467},["ShallowReactive",2],{"footer-primary":3,"footer-secondary":93,"footer-description":119,"request-review-conditional-fields-nested-relations":121,"request-review-conditional-fields-nested-relations-next":198,"sales-reps":215},{"items":4},[5,29,49,69],{"id":6,"title":7,"url":8,"page":8,"children":9},"522e608a-77b0-4333-820d-d4f44be2ade1","Solutions",null,[10,15,20,25],{"id":11,"title":12,"url":8,"page":13},"fcafe85a-a798-4710-9e7a-776fe413aae5","Headless CMS",{"permalink":14},"/solutions/headless-cms",{"id":16,"title":17,"url":8,"page":18},"79972923-93cf-4777-9e32-5c9b0315fc10","Backend-as-a-Service",{"permalink":19},"/solutions/backend-as-a-service",{"id":21,"title":22,"url":8,"page":23},"0fa8d0c1-7b64-4f6f-939d-d7fdb99fc407","Product Information",{"permalink":24},"/solutions/product-information-management",{"id":26,"title":27,"url":28,"page":8},"63946d54-6052-4780-8ff4-91f5a9931dcc","100+ Things to Build","https://directus.io/blog/100-tools-apps-and-platforms-you-can-build-with-directus",{"id":30,"title":31,"url":8,"page":8,"children":32},"8ab4f9b1-f3e2-44d6-919b-011d91fe072f","Resources",[33,37,41,45],{"id":34,"title":35,"url":36,"page":8},"f951fb84-8777-4b84-9e91-996fe9d25483","Documentation","https://docs.directus.io",{"id":38,"title":39,"url":40,"page":8},"366febc7-a538-4c08-a326-e6204957f1e3","Guides","https://docs.directus.io/guides/",{"id":42,"title":43,"url":44,"page":8},"aeb9128e-1c5f-417f-863c-2449416433cd","Community","https://directus.chat",{"id":46,"title":47,"url":48,"page":8},"da1c2ed8-0a77-49b0-a903-49c56cb07de5","Release Notes","https://github.com/directus/directus/releases",{"id":50,"title":51,"url":8,"page":8,"children":52},"d61fae8c-7502-494a-822f-19ecff3d0256","Support",[53,57,61,65],{"id":54,"title":55,"url":56,"page":8},"8c43c781-7ebd-475f-a931-747e293c0a88","Issue Tracker","https://github.com/directus/directus/issues",{"id":58,"title":59,"url":60,"page":8},"d77bb78e-cf7b-4e01-932a-514414ba49d3","Feature Requests","https://github.com/directus/directus/discussions?discussions_q=is:open+sort:top",{"id":62,"title":63,"url":64,"page":8},"4346be2b-2c53-476e-b53b-becacec626a6","Community Chat","https://discord.com/channels/725371605378924594/741317677397704757",{"id":66,"title":67,"url":68,"page":8},"26c115d2-49f7-4edc-935e-d37d427fb89d","Cloud Dashboard","https://directus.cloud",{"id":70,"title":71,"url":8,"page":8,"children":72},"49141403-4f20-44ac-8453-25ace1265812","Organization",[73,78,84,88],{"id":74,"title":75,"url":76,"page":77},"1f36ea92-8a5e-47c8-914c-9822a8b9538a","About","/about",{"permalink":76},{"id":79,"title":80,"url":81,"page":82},"b84bf525-5471-4b14-a93c-225f6c386005","Careers","#",{"permalink":83},"/careers",{"id":85,"title":86,"url":87,"page":8},"86aabc3a-433d-434b-9efa-ad1d34be0a34","Brand Assets","https://drive.google.com/drive/folders/1lBOTba4RaA5ikqOn8Ewo4RYzD0XcymG9?usp=sharing",{"id":89,"title":90,"url":8,"page":91},"8d2fa1e3-198e-4405-81e1-2ceb858bc237","Contact",{"permalink":92},"/contact",{"items":94},[95,101,107,113],{"id":96,"title":97,"url":8,"page":98,"children":100},"8a1b7bfa-429d-4ffc-a650-2a5fdcf356da","Cloud Policies",{"permalink":99},"/cloud-policies",[],{"id":102,"title":103,"url":81,"page":104,"children":106},"bea848ef-828f-4306-8017-6b00ec5d4a0c","License",{"permalink":105},"/bsl",[],{"id":108,"title":109,"url":81,"page":110,"children":112},"4e914f47-4bee-42b7-b445-3119ee4196ef","Terms",{"permalink":111},"/terms",[],{"id":114,"title":115,"url":81,"page":116,"children":118},"ea69eda6-d317-4981-8421-fcabb1826bfd","Privacy",{"permalink":117},"/privacy",[],{"description":120},"\u003Cp>A composable backend to build your Headless CMS, BaaS, and more. \u003C/p>",{"id":122,"slug":123,"vimeo_id":124,"description":125,"tile":126,"length":127,"resources":128,"people":132,"episode_number":142,"published":143,"title":144,"video_transcript_html":145,"video_transcript_text":146,"content":8,"status":147,"episode_people":148,"recommendations":177,"season":178,"seo":8},"b2b01569-d8c6-49a7-adaa-429fe84f204f","conditional-fields-nested-relations","916080169","In this recording of our live event on February 22 2024, Rijk, Jonathan, and Daniel discuss the support of nested relational values in conditional fields to build more flexible content editors","4764c83c-2464-4764-8ef3-9d310502315d",55,[129],{"name":130,"url":131},"GitHub Discussion","https://github.com/directus/directus/issues/8228",[133,136,139],{"name":134,"url":135},"Rijk van Zanten","https://directus.io/team/rijk-van-zanten",{"name":137,"url":138},"Jonathan Wagner","https://directus.io/team/jonathan-wagner",{"name":140,"url":141},"Daniel Biegler","https://directus.io/team/daniel-biegler",4,"2024-02-29","Conditional Fields & Relational Values","\u003Cp>Speaker 0: Love it all.\u003C/p>\u003Cp>Speaker 1: Yeah. Hello. Welcome everybody once again. Thank you for joining us again in our biweekly, bi monthly. I always forget the difference between the 2, but they're also interchangeable.\u003C/p>\u003Cp>Our bimonthly, twice a month, session where we go over, you know, feature requests and try to go in deep, find all of the edge cases, think about everything that we possibly wanna support ever of the universe, and then bring it back down to number 42. Today, we're talking about supported nested relational values in conditional fields, which feels like a, oh, just support nested relational values. Easy. Until you start thinking about it for real, which is what we're gonna do today, and realize that it's probably not as easy as it sounds because that seems to be far from the course for these sessions.\u003C/p>\u003Cp>Speaker 0: As it always So\u003C/p>\u003Cp>Speaker 1: before we dive in on the every single time, before we get in too deep on the technical problems, you wanna, outline what what this is all about, Daniel?\u003C/p>\u003Cp>Speaker 0: Yes. So, just for anyone that has not used this feature before, it's pretty, I think it's pretty niche. I mean, I have not extensively used it in the past, but, a little bit here and there. And I think lots of people, share this experience. But, if if you use this feature, conditional fields, you will eventually run into this little problem.\u003C/p>\u003Cp>So it is about the ability to conditionally render, for example, or hide or show or change fields inside of your collection edit or your item edit page depending on other fields. So you open up an item and you have a couple of groups depending on how much information there is inside of your item. It might be useful for you as a user or for, you know, to make it easier for actual users of your directus instance to hide a couple of fields, for example, so lessen the, you know, initial information overload, for example. Or you could also make use of it to actually enhance the visual, the the user experience. There's lots of stuff that you can do.\u003C/p>\u003Cp>Also, you know, require different fields if a different field has a specific condition, if it meets a specific condition. So lots of interesting stuff that you can do and, like, really, really customize how your editing experience looks, how it feels, and improve it for your users. And, so this is just the overall, like, high level description of what this does. But this issue that has been opened for a little bit, a little tiny, tiny, tiny while. So, it is about this exact scenario.\u003C/p>\u003Cp>So where you want a field to have a new, let let's say you want to hide something depending on if this item has some type of property in in a relation. I don't think I, describe this very well. But, so you want the to apply these conditions depending on some nested property. And this currently is a little bit tricky, for us because this stems stems from an architecture standpoint, like, how our forms work as of right now. So this is not like, you know, we're just missing a little if statement maybe, and then we could enable this.\u003C/p>\u003Cp>It's a little bit more more involved, but we'll explore this a little bit. So, yeah, this is what this issue is about. You want to, you know, conditionally style or, you know, change your existing fields depending on the nested property. And it's currently a little problematic because if you open up a form or your item page, I mean, we currently do not load every single nested relation because, you know, that it could be bad. It could be good.\u003C/p>\u003Cp>It could be bad depending on how large your item is. So, technically, if you open up your item page, we do not have that type of information as of right now. So you can't actually apply conditions because we don't have that information inside of the form, which is the root of the problem. So how do we fix that? Good question.\u003C/p>\u003Cp>Speaker 1: Problem number 2 is we might not even have access to the info that you're trying to use, which makes this a heck of a lot more tricky to think.\u003C/p>\u003Cp>Speaker 2: Yeah. Tack tack on permissions, and suddenly this gets very, very complicate. I mean and how deep is this? Right? So in my case, right, where many to any, this can this, I've seen clients with anywhere from 5 to 18 levels deep in this relational model.\u003C/p>\u003Cp>How much data do you load up into the current view? Right? This can get very\u003C/p>\u003Cp>Speaker 1: first, Gary, you know, this\u003C/p>\u003Cp>Speaker 0: can get a little bit of hands in from the chat. You know? Let's involve the chat a little bit. So So just\u003C/p>\u003Cp>Speaker 1: to just to summarize this to, those three main Please,\u003C/p>\u003Cp>Speaker 0: let's\u003C/p>\u003Cp>Speaker 1: problems at first. Right? So right now, those conditional fields are just using the information that is visible on the form, right, with the edits applied because it needs to be reactive to what the user does. Then once you go relationally deep, we have a bit a problem because that information just doesn't exist in the context of that page at present time. Right?\u003C/p>\u003Cp>So that in and of itself could be easy enough by saying, okay. Let's just fetch all of the paths that are used within the conditional fields, and then at least we have that data. But we fetch it separately from the actual form content just for conditional fields purposes. That would solve part of this. Right?\u003C/p>\u003Cp>But then the second problem that makes that part a little tricky is that we have to merge it with the edits made by the user in the form. Right? So now we're dealing with differences in data types and how you configure them, which is one of the the sort of bigger the the second issue. Because theoretically speaking, you know, conditional fields check against the staged value of the form. So therefore, if you select, you know, a many to one item, you could check against the ID that you have selected.\u003C/p>\u003Cp>If you make a nested update, you could theoretically, through the rules, check for the nested value and and change it. The difficulty is, like, if you select an existing item, now the data that is staged is just a UUID. Right? It's not a nested object of values. So if your conditional field says, author names or nested name and author has to be reg, then it becomes tricky if you select the existing author because now you're checking the rule is nested field name has to be reg, but you're checking it against the u a d string.\u003C/p>\u003Cp>Right? Because that's the actual data that you're about to save. So that's that's another big big mismatch there. And that problem compounds the further down you go, obviously. Right?\u003C/p>\u003Cp>So the other thing is when you update, a one to many, we have that difference in syntax where you can provide an array of all the items or you can provide, you know, the create update, delete statements individually, which is what the app uses because it's still easier to manage for larger datasets. But that again also means that you now have to check against 2 data types and it works a little bit unlike you would expect. Right? That's kind of the the the TLDR for this. The 3rd major issue is permissions.\u003C/p>\u003Cp>Right? So as an administrator, you could set hide, a certain set of fields if a hidden field for this user, like, that's something they can't see is enabled or disabled, which for the end user is invisible and therefore the app can't actually run the check against it because it doesn't even know that the field exists. Right? So that needs a totally different solution where the check doesn't even happen on the app client side. The check happens on the server side.\u003C/p>\u003Cp>So it can check against data that the client user might not even have access to in the first place. Right? So those are the 3 major sort of problem spaces that we have with this particular feature. All of which need some sort of specialized solution for conditional fields. And hopefully, we can find some sort of direction that is 1, you know, one endpoint that rule them all, so to speak.\u003C/p>\u003Cp>Speaker 0: That's a top order. I guess. We we have some interactions. Yeah. Exactly.\u003C/p>\u003Cp>So we have a little bit of chat. How about having a field, that just show calculated data from other columns? So it's not a column in a database, a column just for showing some calculation.\u003C/p>\u003Cp>Speaker 1: So if I'm understanding correctly, to summarize that, what we're saying is instead of trying to use the nested values like an actual nest of the tree, why not have one alias field that just pulls up the relevant bit of data? So it's always just the string name, for example, from an author, and then you can conditional fields against that. Right? So instead of trying to dynamically do it against the whole tree, you're just pulling out the data that's relevant, and then the conditional fields check only runs on the top level.\u003C/p>\u003Cp>Speaker 0: Alright. But lots to think about. There we go. I've done it in. Fit this problem before, so what I do is to just create another extra foreign key.\u003C/p>\u003Cp>Speaker 1: It can\u003C/p>\u003Cp>Speaker 0: be used to filter the current items onto many drop down. Problem is that the user need to do another selection to enable this filtering.\u003C/p>\u003Cp>Speaker 1: That's kind of a similar idea. Right? Yeah. Where it's like instead of trying to nest it deeply, you just pull the value back up in some sort of way, either automatically or by having the user chip choose it, and then you operate against the static value of that field. Now the the interesting thing here is that one of the problems that we're seeing is that the way it works technically makes sense.\u003C/p>\u003Cp>Right? You you validate the conditions against whatever the third stage value is with the user's changes applied. Where it falls on its face is that the expectation is that it will do nested relational lookups and then dynamically apply the changes in that tree and then check against that. Right? So that could potentially solve for the first two.\u003C/p>\u003Cp>Right? Where we're saying, okay. We can make some sort of utility function that says, what is the conditional field rule? What data do we need for that? Then apply the current edits on top of that in a way that fits the model, right, the model for the conditional fields.\u003C/p>\u003Cp>So, therefore, if you selected an an ID for many to 1, we have to go fetch the nested data for that so not the permission. I saw it on the screen. It's in a different order now. So it's for the the app data context and then the nested relationships. For the permissions piece, though, we have an issue.\u003C/p>\u003Cp>Right? Because at the, like, the end of the day, we cannot run that in the app. That's that's basically the long story short. So those for for those who have been eyeing the GitHub repo like a hawk, there was actually a PR not too long ago with an issue, in a in a similar vein, but about the permission checks. Right?\u003C/p>\u003Cp>So some users were running into some issues where the application would allow you to change fields that you didn't have update permission to, for that exact reason because the update permissions were using a field that the app cannot read because you didn't have read permissions to those fields. So, therefore, the app couldn't know if you had access or not. So it would just default to, like, okay. You can do it. And then once you hit save, the API would just throw an error and be like, no.\u003C/p>\u003Cp>You cannot do it actually. Right? The way we solved for that is with a new endpoint in the API that basically say, hey. For the current user, am I able to update this particular item in this particular collection? Right?\u003C/p>\u003Cp>And it will return, like, these are the fields that you can edit, as far as I understand. I I'm a little hazing the execs, you know, IO, but that is effectively the gist of it. Right? And it feels like It feels like this feature will probably go in a very similar direction, where we need to have some sort of API endpoint where the app can say, okay. Here's the current about to be safe changes.\u003C/p>\u003Cp>For the for the current user, what should the conditional state be, I guess? Right? Because that's the only way. If the the app cannot read fields that are used in the conditions, it's kinda game over. Right?\u003C/p>\u003Cp>However\u003C/p>\u003Cp>Speaker 0: Interesting. How how would how would that endpoint look like? Like, what type of payload how would that translate all of the different requirements that we have? Interesting.\u003C/p>\u003Cp>Speaker 1: So I'd imagine I I know the requirements generally are, a, we need to fetch all of the data that is used in the, conditional fields rules. Right? So we just have to look up what are all the fields and what is the whole tree that is used within the conditional fields and fetch just those in the exact same structure so so we can run the checks against it. Right? Then we need to dynamically apply all of the staged changes from the user because one very important use case for conditional fields is things like, you know, you click a toggle and you show and hide fields conditionally.\u003C/p>\u003Cp>Right? That's kind of one of the major use cases for this. So it needs to be real time. And then the last thing right now, I'm pretty sure that's, it just returns. I I think what we do right now is we effectively just loop over and and then merge the field's configuration for the current item with the conditional field result, sort of smash them together.\u003C/p>\u003Cp>Right? So if, like, the default field is hidden in your conditional fields, you have field that's visible, then that takes precedence, and we merge them together by by field key. Right? So we dynamically update the area of fields that exist within the form based on that logic. So to translate that into an endpoint, you would most likely have to have an endpoint that takes what collection are we in, what item are we in, because that might affect, you know, the the IDs and all that kind of stuff.\u003C/p>\u003Cp>And then what is the changes that you've currently made so we can dynamically merge those and then do all of that logic on the server side and effectively return a new list of fields that should be visible in the app. Right? That's theoretically possible. Tricky thing, performance. Right?\u003C/p>\u003Cp>Speaker 0: It it is exactly. Like, I was already, like like, inhaling and just to, you know, finish your sentence so I can say that. Exactly. So, yeah, that that would probably then lead to, you know, some delay because, let's say, you type a name pretty quickly, you know, like, example, whatever. Now you made, like, I don't know, 6, 7, 8, whatever it is that you're typing.\u003C/p>\u003Cp>The key presses, alright, do we debounce those? Then, alright, we have another little delay. So we then have to contact the API, which gets the stuff back, and then we have another little delay. And then the whole experience might suffer depending on how exactly we do it. Because, like, even if we now if we now, start, like, debouncing, that could lead to other problems.\u003C/p>\u003Cp>You know? Like, if if we want something to change, if the the the the text field contains a specific substring or something. Yeah. Then then that won't trigger fast enough, basically, which, you know, is kinda not the point.\u003C/p>\u003Cp>Speaker 1: That is that's really hitting it on the head because this has to be you click a toggle, stuff shows up. That's that's the goal. Right? So it needs to be immediate and interactive. So if you debounce it for a second or something, to your point, the experience is gonna suck because you click a button and then Yeah.\u003C/p>\u003Cp>You're already looking somewhere else and then magically stuff shows up.\u003C/p>\u003Cp>Speaker 2: Right? This, it's instant. Right? Because the app has all the context and data and permissions and things that it needs, so this is instantaneous for this to show or hide. Mhmm.\u003C/p>\u003Cp>You know, make required, do whatever. The the toggle here, the app side is doing all that, and it's almost instantaneous where you go server side now if you're having to send back to server. I'm wondering, does WebSockets' real time kinds of capabilities help at all in this space if we work towards I mean, again, we've always wanted to make the app real time so that we can do, you know, multi multi user editing of records and things.\u003C/p>\u003Cp>Speaker 1: Yeah. I think, realistically, the main it it would reduce the network latency a little bit, but I think the main time spent on this is re fetching the existing item data and then merging on the changes. Right? Now\u003C/p>\u003Cp>Speaker 0: this is a\u003C/p>\u003Cp>Speaker 1: nice segue because I just read it in the chat. Does it have to be solved dynamically on the fly? Question mark. I think the answer is yes, unfortunately, because it's based on the current user changes, so it's always have to be dynamic. Is it possible to require users to save the query somewhere, save like a SQL stored procedure kind of thing?\u003C/p>\u003Cp>If so, would that make it easier to resolve? Yes and no. I mean, it's again, because it's based on the current sexual users changes, we can't really have that prepared because you don't know what those changes will be. That being said, you know, if the item that you've just read, we could cache that for a little while. Right?\u003C/p>\u003Cp>The tricky bit is just when do you invalidate that cache? That's been a bit of an issue before, right, where right now we have to sort of auto purge the whole thing and it's kind of inefficient, which is a very high on my personal wish list item, but let's not psych sidetrack too much on that in this one. So so the the problem is we can cache that particular call to the database and just be like, oh, in the last, you know, 10 minutes, we already fetched this. It's probably the same. But if some other user changed it in between, you know, it gets a little bit tricky.\u003C/p>\u003Cp>But we could cache the database call for sure for sure. If so, would that make it easier to resolve? Yeah. It would make it a little bit faster. We still have the network latency though.\u003C/p>\u003Cp>Right? Even if the API would just respond immediately from all the caches and skips all the execution, just by the nature of it having to go over the Internet, you know, you might have your the the API that you're talking to might be in a different region or something that might be, you know, a 100 200 milliseconds latency just from that. And then it's just the experience is gonna suffer a lot. Like, a lot. Right?\u003C/p>\u003Cp>Yeah. To a point where, oh, I see our own team here in the chat mentioning a similar thing where it's like, maybe conditions should just not support fields you don't have the permissions to. Because that way, you know, all the commissions, because then then you have this issue where it has to be on the API side. Right? So maybe one of the requirements that we're learning here now is that it kinda has to be on the app just to be able to keep that instant, feedback loop going.\u003C/p>\u003Cp>And then to mention for conditions not to support fields you don't have permissions to though, you have to configure it on a sort of per role basis what those conditions are because only on the role do you know what fields are available in the condition, Which is true, although that makes configuration hack a lot more annoying. Because if you just have you know, I wanna show an email field when you click, subscribe to newsletter or something. Then now you have to reconfigure that for every single role. Right? Yeah.\u003C/p>\u003Cp>Chicken. There's always plan c, which is just aggressively saying no relational fields and conditions. That's kind of what we've been doing so far. You know? It it sucks.\u003C/p>\u003Cp>Speaker 2: Does Paul is does the new policy system maybe allow us some better flexibility so that it's not on a per role? It's configured, but\u003C/p>\u003Cp>Speaker 1: Oh, don't get me started.\u003C/p>\u003Cp>Speaker 2: But, again,\u003C/p>\u003Cp>Speaker 1: it's a lot of and no.\u003C/p>\u003Cp>Speaker 2: It does require, I think I think this I I think the the idea is this really has to be either real time in some way, you know, WebSockets implementation, the app itself. Goal longer term is to have that kind of capability anyway. But with a policy based, you know, if we are able to, you know, walk the conditional tree and we can we can see that and pull the data necessary. Now it might be that we wanna limit, you know, number of conditions that you can apply or number of levels deep you can go with a conditional. Right?\u003C/p>\u003Cp>Because I don't know that we can have an you know, the infinite depth capabilities. You know, I can go 18 levels deep in a condition that seems insane to kinda try and cash all that, or even manage\u003C/p>\u003Cp>Speaker 1: all that in front end.\u003C/p>\u003Cp>Speaker 2: But is it you know, maybe it's a 1 or a 2 level deep is what is allowed, from a conditional rules perspective kind of thing where it's manageable, controllable, and sustainable.\u003C/p>\u003Cp>Speaker 1: The the thing to me though when it comes to conditional fields, to me, that is more a form builder type of thing than an access control type of thing. So having to configure how the form behaves on a policy to policy basis feels hard to manage, if that makes sense. Because now you're the output form is just it's hard to expect what it's hard to know what to expect once you have, you know, multiple different policies doing multiple different things when it comes to form building. Now this is a complete sidebar. That's also the beauty of these sessions.\u003C/p>\u003Cp>Right? Divergent thinking.\u003C/p>\u003Cp>Speaker 0: Love it.\u003C/p>\u003Cp>Speaker 1: Here we go. Strap in, folks. It's there's there's another singer, Annette. See I see you nodding over there. But one thing that we have been sort of, you know, floating the idea of is this idea of, like, what if we decouple the data model from the form.\u003C/p>\u003Cp>Right? So it's decouple the actual actual how you interact with the data from the data model itself. So therefore, you could have multiple forms for the same database table. Right? And then in a policy or in a role or whatever, you would choose what is the form that we wanna use for this particular table, for this particular set of users.\u003C/p>\u003Cp>Because the one of the other known I mean, issues might be a bit of a big word, but one of the other downsides that I've on my personal wish list, it's kinda like if you have read access, we we show and hide fields that you'd expect. Right? You don't know that a field exists. It doesn't show up in the form. It also means that if you're doing a form building exercise where you have, like, multiple columns, like, 2 things side by side, and all of a sudden one disappears, you know, the form kind of reflows, but it it results in a bit of an unexpected state.\u003C/p>\u003Cp>Right? Mhmm. So by having, you know, that form, having that form decoupled from the data model, now you could just say, okay. We're gonna make a form that we know will look exactly like this. Like, what you see is what you get for the form or the role that we attach it to.\u003C/p>\u003Cp>This is, again, a way bigger discussion than just a little brain fart dumping out into the world here. But that is that is, you know, one of the ways around this because then you do have conditional fields per role or per policy group or whatever you wanna call it.\u003C/p>\u003Cp>Speaker 0: Alright. Many, many different things. I'm trying to I'm trying to find a way where we can, you know, like like, define a little pathway for us right now, but it's it's very hard because there's so much so many different things that we could do, technically. So yeah. Yeah.\u003C/p>\u003Cp>My initial feeling, like, when I read about this was, yeah, it sounds very reasonable, like, in the naive way, you know, the very naive, first understanding of the of the problem. Very similar or basically what you said in the beginning. Alright. So we do know when we open the form, what people used inside of the conditions. Alright.\u003C/p>\u003Cp>How about we then fetch those things, all of the related stuff to separately from the table? Alright. So far so good. Then the permission issue comes in. Alright.\u003C/p>\u003Cp>Are they allowed to read this? Yes. No. Alright. What do we do if they and, and then it gets tricky, and then it starts to spiral.\u003C/p>\u003Cp>Alright. Goddamn. Okay.\u003C/p>\u003Cp>Speaker 1: We got we got\u003C/p>\u003Cp>Speaker 0: a couple. Yeah. We we got a couple of steps that sound like alright. Alright. Maybe maybe yes.\u003C/p>\u003Cp>Yeah. And okay, permissions.\u003C/p>\u003Cp>Speaker 1: There's there's always the point where we could put limitations in place. Right? It's like, we like to think with the least amount of limitations as we can while keeping it fast. But to Tim's point earlier, we could make a line in the sand and say, okay. You know what?\u003C/p>\u003Cp>Nested relational data is only allowed if you have read access to those those data points. Otherwise, it's just not intended to work. Because that way, we can remove the server component, keep it on the app site, and make it work the way you'd expect to make it work fast. But we put a ceiling in place to make that happen. Right?\u003C/p>\u003Cp>That is a very real, a very real in between. I'm I'm still been noodling on that that idea that you had, Jonathan, to, like, could WebSockets potentially help with this? And the more I think about it, the more I'm like, maybe, just maybe. Because if that database call is heavily cached and we send, you know, a message of, like, here's the stage change ID such and such, and then the API will just respond as fast as it can with, like, the the combined change and the new form that comes out of that. If we can heavily cache it enough, we can make that work.\u003C/p>\u003Cp>Now I see Tim typing in the chat. I'm curious if he's gonna say the same thing. I knew it. That was exactly what I was gonna say. He put in the chat, WebSockets are great, but we cannot rely on them for stuff like this as they're not a hard requirement to run direct this.\u003C/p>\u003Cp>Speaker 2: Not yet.\u003C/p>\u003Cp>Speaker 0: And this is this is a\u003C/p>\u003Cp>Speaker 1: different question, of course. Like, should it be a hard requirement or not? Right? Because and this is again a a bit of a sidecar sidebar from from this, this particular discussion. Because the way we implement the WebSockets right now I mean, first and foremost, we haven't really used them in the app yet, for very similar reasons to this actually, which is, like, we have to be careful with relying on stuff, maybe, yes, no, and then tricky tricky.\u003C/p>\u003Cp>The the the real question is, you know, WebSockets are not supported everywhere like regular HTTP requests are. Right? So for example, there's there's a couple of platform as a service providers that just will not work with WebSockets in your container or something. Right? Because there's so many hoops you could jump through.\u003C/p>\u003Cp>You gotta go from, like, you know, the CDN to, like, some sort of load balancer to some sort of proxy container to some sort of, you know, container that has the actual connection. Yeah. And to to Tim's point in the chat now too, if you wanna do snazzy things on the edge, like scaling back to 0 containers or something, you cannot have a persistent connection at all. Right? Which is another very good point.\u003C/p>\u003Cp>I know there was another this another discussion thread that has seen some activity recently around, being able to run directives in a serverless environment, which, oh, boy, is a whole different session of one of these. I'm sure. But if that were ever, you know, a deployment target that we wanna officially support, then WebSockets are just out. They're just unavailable to rely on, right? And then the question really becomes like, okay, what what is more important to us supporting serverless environment scaling down to 0?\u003C/p>\u003Cp>Or are we gonna say, well, Directus is just a a a tool that is intended to be a long running server because with cron jobs and hooks and all that kind of stuff. And therefore, WebSockets are just enabled just like the API and you can use them and we can heavily rely on it in the app to make it faster and a better experience. Right? That is gonna be a difficult call to make, because it's it's it's, at the end of the day, a little bit of a subjective one. I know it's it's, we haven't really done all the pros and cons of research and all that kind of stuff.\u003C/p>\u003Cp>But it's like, you know, people have very strong opinions on this kind of stuff. Very strong opinions.\u003C/p>\u003Cp>Speaker 0: We have to be careful, with Tim. He probably has one of those.\u003C/p>\u003Cp>Speaker 1: Like, one of those nasty opinions.\u003C/p>\u003Cp>Speaker 0: One of these nasty, nasty opinions. Oh, no. No. No. No.\u003C/p>\u003Cp>Alright. Yeah. Yeah. With the angel emoji. Alright.\u003C/p>\u003Cp>So far so good. Then let's maybe, you know, do the little, exercise. Alright. Let's say we go down that route that we mentioned with alright. You can't put conditions on stuff that you can't read or that this specific user can't read.\u003C/p>\u003Cp>Alright. This would have a couple of repercussions. Right? Like, then alright. You have multiple different different user roles.\u003C/p>\u003Cp>Do you then, as an admin that is configuring this collection, do you want to? Probably not. But do you want to actually configure then these things between different roles all the time. That sounds like a big pain, to be honest. Like, very annoying.\u003C/p>\u003Cp>Would we? Yeah. I mean, we do have to attach it to some kind of role. Right? Because, as of right now, you know, there can be, like, unlimited different types of user roles.\u003C/p>\u003Cp>Yeah. And some of them can read those fields. Some of them don't. We don't know that. Would we like to share this then with some type of diffing between those?\u003C/p>\u003Cp>But oh, man. This this just sounds like spaghetti, like, the largest bowl of spaghetti that you can think of. Weird. It doesn't sound enticing to go down.\u003C/p>\u003Cp>Speaker 1: Yeah. I think the the the conflict that we're finding ourselves in is that we know you can configure conditions for fields that you might not have access to and then it doesn't work. Right? So what are we gonna do to help the admin user in that situation? Like, we need to educate them on this.\u003C/p>\u003Cp>We need to educate them on the, on the on the limitation there or show it somehow or prevent them from making that mistake in the first place by connecting it tightly to a role somehow. Because once you connect it tightly to a role, we know what fields are available, and we can only service those in the conditions. Right? Mhmm. I agree with your earlier sentiment when you were, like, configuring that on the role and having to reconfigure it for every single role that might access this thing feels like a nightmare.\u003C/p>\u003Cp>That feels like so much extra work. Mostly because and and I briefly touched on this before, but mostly because I really see this as a form building tool, not so much an access control thing. Right?\u003C/p>\u003Cp>Speaker 0: Yeah.\u003C/p>\u003Cp>Speaker 1: It's to me, it's similar that you wanna have 2 fields side by side. I wanna have one show up and hide based on the value of the other. That's that's all sort of form building magic, not so much access control magic. So I I kinda strongly feel like we don't wanna conflate those 2 and and put, like, too much form building stuff in access control. Because it Right.\u003C/p>\u003Cp>Speaker 0: It just makes me context. Yeah. Thanks. So, similarly alright. How about then we reverse this a little bit?\u003C/p>\u003Cp>So, let's say, as of right now, you know, the admin goes into the collection thingy into the conditions and configures, you know, how it's supposed to look like, all of the different conditions, you know, height depending on this checkbox, make the title red. And then we attach a roll to that filter and we can now check, you know, is this role can this role even apply this filter? And we can immediately just say, oh, no. This role is not compatible with this filter because it can't read x and y and z. And this would also solve, like, solve let's let's in big big big quotation marks, solve that problem of, you know, like, having multiple user problems having multiple user roles that you could, you know, just say, alright.\u003C/p>\u003Cp>But this filter is, yeah. I I'm already, like, thinking while I'm talking. So then you come into this whole thing. Alright. Maybe you want to have different conditions for different user roles.\u003C/p>\u003Cp>Maybe.\u003C/p>\u003Cp>Speaker 1: Here we are again.\u003C/p>\u003Cp>Speaker 0: Here we go. Here we go.\u003C/p>\u003Cp>Speaker 1: Love it. That's the moment where it starts spinning again. Tim, just in the chat, does not make sense to build your forms based on what fields you have access to? Which, yes, I think that is kinda closing closing in on the the sort of wild wicked idea of saying, what if you can just configure multiple different forms and you can just make a form that is dedicated to, you know, one one role? So that way you can you know for a fact that all the conditions exist and all the fields exist, and the way you configure the form and the layout is tailor made for that role because the only fields that exist are the ones that exist for the, for the item.\u003C/p>\u003Cp>Speaker 0: Yeah. I can I can feel I can already, like, feel the pain through just thinking about this of, you know, the then, like, synchronizing between different types of forms between different types of user roles and oh, man? It's getting it's getting a little bit of rough. Let's say let's say rough. Alright.\u003C/p>\u003Cp>Tim has another thing. You effectively already do that using access control as the form will not render fields you don't have access to. Yeah.\u003C/p>\u003Cp>Speaker 1: Which I think might become an issue at some point in the not too distant future. Because one other thing that we've sort of been been noodling about, Jetta the Jetta, is the idea of a little bit more flexible grit for forms. So right now, it's it's a 2. Right? You can either make a full width or you have 2 side by side.\u003C/p>\u003Cp>That's it. We also just been thinking about, like, what if we make that just a configurable number with some with some responsive breakpoints potentially. You could make it a 12 grid. You could make it in the 8 grid. Whatever.\u003C/p>\u003Cp>Right? At that point, if the field in in column number 6 disappears because of redexes, we cannot we can no longer sort of cleverly reflow it, to make sense. Right? Because now we legitimately just don't know where things are supposed to go anymore on the page because it just it it just has to be become a a gap, basically. At that point, we might end up having to just show, like, there used to be a field here, but you don't know about it.\u003C/p>\u003Cp>Right? Because otherwise, the whole form layout is\u003C/p>\u003Cp>Speaker 0: tell anyone.\u003C/p>\u003Cp>Speaker 1: Because otherwise, the form layout is just gonna look either broken because you're gonna end up with blank spots all over the place, or, you know, if if we're trying to I I think it's safe to say that we're trying to sort of reorganize it on the fly. It will break, because we just don't know what needs to go where at that point. Because it would be a multidimensional grid. Right? That will be 2 dimensional because you can have things go 2 rows or 2 columns, etcetera, and then you have a problem.\u003C/p>\u003Cp>Right? Kinda like, I think of dashboards basically in terms of just positioning stuff all over the place. But if we go that route, if if that ever comes to fruition, right, again, it's just a random thought. It's not actively being worked on or anything. But, if we're going in that direction, I think we need to have some sort of way to have a form per role anyways.\u003C/p>\u003Cp>Because otherwise, you know, you're gonna either have a form with a bunch of holes in it or with place holders that you're like, hee hee. You can't actually see this. Or, you know, or it just needs to be per role because that way you can just make one that is, you know, tailor made for for that particular role.\u003C/p>\u003Cp>Speaker 0: Well, whether or not, we're actually, you know, looking into this, we already have our first customer. Then he said, I'm sold on the option to build a form per roll.\u003C/p>\u003Cp>Speaker 1: So good.\u003C/p>\u003Cp>Speaker 0: Sold it already. It was fast.\u003C/p>\u003Cp>Speaker 2: I like it. So if we can inherit, like, a global so it inherits the the default kinda data model form that you configure, and then allow you to adjust that on the specific role, I think that's actually pretty freaking cool because we do have those kinds of use cases where, you know, this particular business and especially if we could apply specific conditionals on that form, it means that, you know, my business user versus my consumer user could have a very different form experience intentionally and different conditionals. Right? The the default conditional for the business user presets those conditions and organization. I I kinda love the idea.\u003C/p>\u003Cp>Whether or not again, this this comes back to whether or not this actually we we decide to allow additional depth, you know, conditionals. Just having that particular feature seems kind of amazing. As long as we can inherit the default, then if I don't need that kind of capability, I can just use the default and manage the default that we'll get. If I've got a custom reason for adjusting the form. Pretty brilliant.\u003C/p>\u003Cp>I like it.\u003C/p>\u003Cp>Speaker 0: So there's a question by Benny Wade. Could we make groups configurable per row rather than making a whole form per row? Keep it a bit more modular.\u003C/p>\u003Cp>Speaker 1: AKA, can we nest these forms?\u003C/p>\u003Cp>Speaker 0: Yeah. That that Let's\u003C/p>\u003Cp>Speaker 1: check as we check-in with our friend v form and see how he feels about it.\u003C/p>\u003Cp>Speaker 0: -Oh, boy. Can't wait. Guys, if you enjoy\u003C/p>\u003Cp>Speaker 1: messaging, please. Where you have the forms that or the view of the page or whatever you wanna call it is the same for everybody, but then you just have a section where it's like this section only shows up for x role. Right? Could be interesting. That is a conditional field in and of itself, of course, where it's like, the condition is show or hide this thing if current role is x y z.\u003C/p>\u003Cp>Right? Which now I'm thinking about it. I'm pretty sure that exists. Present time. I'm pretty sure you can this is something I'll have to test, actually, because I know we have those dynamic variables for current user and current role in those.\u003C/p>\u003Cp>I don't remember if we support those in conditional fields. Because if we do, you can step a group and have a conditional field on the group that says current role equals x y z and then hide the whole group. We do not,\u003C/p>\u003Cp>Speaker 0: Tim. Tim and a chat. Why not? Why not?\u003C/p>\u003Cp>Speaker 1: He calls me out he calls me out on my bluff. It's happens happens sometimes. Yeah. But that would theoretically be a a soul for the same thing, though. Right?\u003C/p>\u003Cp>Or you could just say the whole group is hidden for a role, and therefore, no problem. You make it so that you can have the same field in different presentation section configured per role? Right. Right. So the same field multiple times.\u003C/p>\u003Cp>Yeah. That is that is another thing when it comes to dynamic form building and, just full stop dynamic form building at that point. Right? Because right now, the form is data model first. It's like you have a title field, therefore, you can now have a title input because it's 1 to 1 to the data model.\u003C/p>\u003Cp>Right? With a form building thing, maybe you have 2 title fields, like, 2 fields that point to the same underlying data thing. Right? There's instinct. I don't know why the hell you would do that, but you could.\u003C/p>\u003Cp>For for some interface, it may set I mean, in this this example where it's like you have the same field in different sections and the section show and hide based on the role, it starts to make sense again. I for admin users, it'd be interesting, but it it yeah. For sure. Then for, I I think there's a a definite interesting use case for certain data types where it would help to have multiple fields, multiple visual fields for the same underlying column. Think about, like, an address interface face or something.\u003C/p>\u003Cp>Right? Where you wanna have address line 1, 2, and then, ZIP code and all that kind of stuff, but you wanna save it as one field in your data model. Not super uncommon, or as a let long sort of search thing, right, where you have a let and a long input and then an address field, and those are all connected. So you can type in an address and it'll geo look up the let long, but then the thing that's saved in the database is just the let long. So there's definitely, you know, some additional things that we unlock with that sort of modular form idea.\u003C/p>\u003Cp>Right?\u003C/p>\u003Cp>Speaker 0: Alright. So what I gathered from this, is that we're basically about to build our own page building framework where we can dynamically close plugs. So we're basically set, you know? Like, director's page building, that sounds like a great idea. Okay.\u003C/p>\u003Cp>On the\u003C/p>\u003Cp>Speaker 1: So just to solve condition fields. That's that's the beauty of it, isn't it? How did we how did we get here for just solving nested conditional fields?\u003C/p>\u003Cp>Speaker 0: Yeah. It all started so innocently. You know?\u003C/p>\u003Cp>Speaker 1: It's true.\u003C/p>\u003Cp>Speaker 0: I just want to hide a field, and now we're basically embarking on a mission to\u003C/p>\u003Cp>Speaker 1: Okay. This is this is actually this is a good thing because this is a perfect example of the sort of, you know, request review session. For those who've been here before, you've seen this happen before. It's like we go completely off the rails in all directions, and then now let's try to see how we can actually get this back on track for nested conditional fields. Right?\u003C/p>\u003Cp>So as a you know, in a potential future utopia where you can just magically conquer up any sort of form, any sort of view that you possibly want. Great. But as of right now, I'm kind of thinking, based on everything that we talked about so far, it, to me, makes the most sense to follow Tim's suggestion from earlier, which is basically you cannot put the field and conditional fields that the user does not have read access to. Right? I think that is that is a safe call.\u003C/p>\u003Cp>I think doing it on the API side, we're never gonna be able to get it just performant enough, and we don't really wanna make WebSockets a requirement for this to work. So I think as of today, you know, what can we actually achieve in the next month or 3? We would most likely keep the client side, keep it fast so we can do all the calculations on the client. It has to be from current fields that you have read access to. The main difference that we have to do is that we have to dynamically, when you open the page the first time, we have to load up what is the nested data structure of this item based on the rules used in conditional fields.\u003C/p>\u003Cp>And then have some sort of utility function that can cleverly combine the stage changes on top of that. Right? We have to account for the differences like many to one ID versus nested object. We have to account for things like the one to many update structure versus array. But that that way, we can merge that and we can do a client side.\u003C/p>\u003Cp>Right? I don't think we should do that per role. That just feels like a nightmare to configure, to be completely honest.\u003C/p>\u003Cp>Speaker 0: Yeah. And\u003C/p>\u003Cp>Speaker 1: a lot of a lot of duplication. Again, in a utopic utopic utopic? Utopia stick future. Utopia like future. Utopian?\u003C/p>\u003Cp>Utopian future, you know, where you have more of this flexible form idea. At that point, you know, you can say, okay, When someone I'm already boring Jonathan to death, I see. When when you open this this page for this particular role, we use form xyz instead but that is again a way way future discussion. But then I think, you know, we can support the core ask for this this feature request, which is if I say nested author dot name, I expect that the lookup, what is the name of the nested author no matter what. If I select an existing one, it needs to look at the name of the existing one.\u003C/p>\u003Cp>If I change somebody's name, it needs to look at the changed name. Right? That is something that we can I'm pretty hopeful we can turn that into some sort of usability function that we can run relatively quickly on the client side and make this happen. Right?\u003C/p>\u003Cp>Speaker 0: Yeah. That shouldn't be shouldn't be impossible. Yeah. Yeah. Look at the from Natron.\u003C/p>\u003Cp>Speaker 1: And 10 rabbits with 1 multiracial conditional stone. Yeah. Exactly. As an admin that's configuring these conditional fields to another person in the chat, it would be nice to see the whole form that a person with a given role would see. Maybe a view as role option somewhere.\u003C/p>\u003Cp>Fully a 100% agree. To Jonathan's point, there's another feature request about that user impersonation. Again, very high on my personal, wish list. Right? I would love it as an admin.\u003C/p>\u003Cp>And not so not just for the for the particular form and settings or something. I really want there to be a way for admins to just say, browse the whole app, impersonating a different role so that you can just click around and see exactly what that user can see and do. Right? From a visual perspective, we'll probably have to have some sort of banner, zoom out a little bit or whatever. We'll figure it out what that looks like.\u003C/p>\u003Cp>But that way, you can just configure it, see the whole thing as, you know, that particular user. Now especially dreaming wish list, it'd be great if you could just change the form while you're on the page looking at what the form looks like for that given your role. But let's I'll get ahead of ourselves.\u003C/p>\u003Cp>Speaker 0: We're going back. We're going back, guys. Back to the page.\u003C/p>\u003Cp>Speaker 1: We're spinning. We're spinning again. We're spinning again. Let's not spin too much. Yeah.\u003C/p>\u003Cp>But no. That's a it's it is a very good idea because also with the other feature request that we talked about. Was it last time or not too long ago where we're talking about the rules and permissions as a whole. Right? And these policy units and whatnot.\u003C/p>\u003Cp>Now that these policies become way more composable, buzzword shot, we can actually you you also have the problem that it becomes a little bit harder to figure out what is the actual permission for this one user now. Right? Because it could come from multiple different places and you can have on the user overrides and that kind of stuff. So I think user impersonation becomes way more important, with that in mind as well.\u003C/p>\u003Cp>Speaker 0: Great. Let's see. We caught up to the chat. If anyone has any last questions, please let us know. There's not much time left.\u003C/p>\u003Cp>I was running out. Just the the call to action, you know, just to get them going.\u003C/p>\u003Cp>Speaker 1: Yeah. Just a moment. Please like and subscribe.\u003C/p>\u003Cp>Speaker 0: Yeah. Yeah. Yeah. Yeah.\u003C/p>\u003Cp>Speaker 1: Hit that notification bell so you'll stay up to date.\u003C/p>\u003Cp>Speaker 0: But if you truly want to stay up to date, you should head to direct us dot io/tv. I I nearly said dot tv. Yeah. Alright. No.\u003C/p>\u003Cp>But seriously, on the directors dot iotv, there's lots of interesting series that you can check out, such as this one and also other ones. And enjoy. And\u003C/p>\u003Cp>Speaker 2: see how Directus TV was built on Directus. Very cool. It's exciting.\u003C/p>\u003Cp>Speaker 1: That is pretty cool.\u003C/p>\u003Cp>Speaker 0: We have Jeron to join literally in the last minute. Hey there.\u003C/p>\u003Cp>Speaker 1: Hey there. Thank you for joining. How you doing? We're about to call it. Goodbye.\u003C/p>\u003Cp>Speaker 2: Anyway. Very, very exciting.\u003C/p>\u003Cp>Speaker 1: As always, thank everybody so much for watching. This was yet another talk where I was, like, going into it, it's like, oh, this feels like a small little bug that we could just fix. Right? And then we talk about it now, and I'm like, oh, man. Okay.\u003C/p>\u003Cp>Speaker 0: It deep go. Building a form builder and page builder. Now now\u003C/p>\u003Cp>Speaker 1: we're getting snazzy with it. But that's that's the beauty of these sessions, and I love it every time. So those are joining. Thank you so much. See you guys in 2 weeks from now.\u003C/p>\u003Cp>Or oh, no. Wait. That's the one that we're skipping for the, you know, the special week week. Yep.\u003C/p>\u003Cp>Speaker 2: It'll be, 4 weeks before our next one, folks. Thanks so much. Appreciate your patience. There's some big announcements coming that that this next week's time or next 2 week time slot is gonna be consumed with other events, and keep an eye out for the live events and things going on that week. So very exciting announcements on the way.\u003C/p>\u003Cp>We're we're excited to have such an awesome community. Have a great day. Have a great week.\u003C/p>","Love it all. Yeah. Hello. Welcome everybody once again. Thank you for joining us again in our biweekly, bi monthly. I always forget the difference between the 2, but they're also interchangeable. Our bimonthly, twice a month, session where we go over, you know, feature requests and try to go in deep, find all of the edge cases, think about everything that we possibly wanna support ever of the universe, and then bring it back down to number 42. Today, we're talking about supported nested relational values in conditional fields, which feels like a, oh, just support nested relational values. Easy. Until you start thinking about it for real, which is what we're gonna do today, and realize that it's probably not as easy as it sounds because that seems to be far from the course for these sessions. As it always So before we dive in on the every single time, before we get in too deep on the technical problems, you wanna, outline what what this is all about, Daniel? Yes. So, just for anyone that has not used this feature before, it's pretty, I think it's pretty niche. I mean, I have not extensively used it in the past, but, a little bit here and there. And I think lots of people, share this experience. But, if if you use this feature, conditional fields, you will eventually run into this little problem. So it is about the ability to conditionally render, for example, or hide or show or change fields inside of your collection edit or your item edit page depending on other fields. So you open up an item and you have a couple of groups depending on how much information there is inside of your item. It might be useful for you as a user or for, you know, to make it easier for actual users of your directus instance to hide a couple of fields, for example, so lessen the, you know, initial information overload, for example. Or you could also make use of it to actually enhance the visual, the the user experience. There's lots of stuff that you can do. Also, you know, require different fields if a different field has a specific condition, if it meets a specific condition. So lots of interesting stuff that you can do and, like, really, really customize how your editing experience looks, how it feels, and improve it for your users. And, so this is just the overall, like, high level description of what this does. But this issue that has been opened for a little bit, a little tiny, tiny, tiny while. So, it is about this exact scenario. So where you want a field to have a new, let let's say you want to hide something depending on if this item has some type of property in in a relation. I don't think I, describe this very well. But, so you want the to apply these conditions depending on some nested property. And this currently is a little bit tricky, for us because this stems stems from an architecture standpoint, like, how our forms work as of right now. So this is not like, you know, we're just missing a little if statement maybe, and then we could enable this. It's a little bit more more involved, but we'll explore this a little bit. So, yeah, this is what this issue is about. You want to, you know, conditionally style or, you know, change your existing fields depending on the nested property. And it's currently a little problematic because if you open up a form or your item page, I mean, we currently do not load every single nested relation because, you know, that it could be bad. It could be good. It could be bad depending on how large your item is. So, technically, if you open up your item page, we do not have that type of information as of right now. So you can't actually apply conditions because we don't have that information inside of the form, which is the root of the problem. So how do we fix that? Good question. Problem number 2 is we might not even have access to the info that you're trying to use, which makes this a heck of a lot more tricky to think. Yeah. Tack tack on permissions, and suddenly this gets very, very complicate. I mean and how deep is this? Right? So in my case, right, where many to any, this can this, I've seen clients with anywhere from 5 to 18 levels deep in this relational model. How much data do you load up into the current view? Right? This can get very first, Gary, you know, this can get a little bit of hands in from the chat. You know? Let's involve the chat a little bit. So So just to just to summarize this to, those three main Please, let's problems at first. Right? So right now, those conditional fields are just using the information that is visible on the form, right, with the edits applied because it needs to be reactive to what the user does. Then once you go relationally deep, we have a bit a problem because that information just doesn't exist in the context of that page at present time. Right? So that in and of itself could be easy enough by saying, okay. Let's just fetch all of the paths that are used within the conditional fields, and then at least we have that data. But we fetch it separately from the actual form content just for conditional fields purposes. That would solve part of this. Right? But then the second problem that makes that part a little tricky is that we have to merge it with the edits made by the user in the form. Right? So now we're dealing with differences in data types and how you configure them, which is one of the the sort of bigger the the second issue. Because theoretically speaking, you know, conditional fields check against the staged value of the form. So therefore, if you select, you know, a many to one item, you could check against the ID that you have selected. If you make a nested update, you could theoretically, through the rules, check for the nested value and and change it. The difficulty is, like, if you select an existing item, now the data that is staged is just a UUID. Right? It's not a nested object of values. So if your conditional field says, author names or nested name and author has to be reg, then it becomes tricky if you select the existing author because now you're checking the rule is nested field name has to be reg, but you're checking it against the u a d string. Right? Because that's the actual data that you're about to save. So that's that's another big big mismatch there. And that problem compounds the further down you go, obviously. Right? So the other thing is when you update, a one to many, we have that difference in syntax where you can provide an array of all the items or you can provide, you know, the create update, delete statements individually, which is what the app uses because it's still easier to manage for larger datasets. But that again also means that you now have to check against 2 data types and it works a little bit unlike you would expect. Right? That's kind of the the the TLDR for this. The 3rd major issue is permissions. Right? So as an administrator, you could set hide, a certain set of fields if a hidden field for this user, like, that's something they can't see is enabled or disabled, which for the end user is invisible and therefore the app can't actually run the check against it because it doesn't even know that the field exists. Right? So that needs a totally different solution where the check doesn't even happen on the app client side. The check happens on the server side. So it can check against data that the client user might not even have access to in the first place. Right? So those are the 3 major sort of problem spaces that we have with this particular feature. All of which need some sort of specialized solution for conditional fields. And hopefully, we can find some sort of direction that is 1, you know, one endpoint that rule them all, so to speak. That's a top order. I guess. We we have some interactions. Yeah. Exactly. So we have a little bit of chat. How about having a field, that just show calculated data from other columns? So it's not a column in a database, a column just for showing some calculation. So if I'm understanding correctly, to summarize that, what we're saying is instead of trying to use the nested values like an actual nest of the tree, why not have one alias field that just pulls up the relevant bit of data? So it's always just the string name, for example, from an author, and then you can conditional fields against that. Right? So instead of trying to dynamically do it against the whole tree, you're just pulling out the data that's relevant, and then the conditional fields check only runs on the top level. Alright. But lots to think about. There we go. I've done it in. Fit this problem before, so what I do is to just create another extra foreign key. It can be used to filter the current items onto many drop down. Problem is that the user need to do another selection to enable this filtering. That's kind of a similar idea. Right? Yeah. Where it's like instead of trying to nest it deeply, you just pull the value back up in some sort of way, either automatically or by having the user chip choose it, and then you operate against the static value of that field. Now the the interesting thing here is that one of the problems that we're seeing is that the way it works technically makes sense. Right? You you validate the conditions against whatever the third stage value is with the user's changes applied. Where it falls on its face is that the expectation is that it will do nested relational lookups and then dynamically apply the changes in that tree and then check against that. Right? So that could potentially solve for the first two. Right? Where we're saying, okay. We can make some sort of utility function that says, what is the conditional field rule? What data do we need for that? Then apply the current edits on top of that in a way that fits the model, right, the model for the conditional fields. So, therefore, if you selected an an ID for many to 1, we have to go fetch the nested data for that so not the permission. I saw it on the screen. It's in a different order now. So it's for the the app data context and then the nested relationships. For the permissions piece, though, we have an issue. Right? Because at the, like, the end of the day, we cannot run that in the app. That's that's basically the long story short. So those for for those who have been eyeing the GitHub repo like a hawk, there was actually a PR not too long ago with an issue, in a in a similar vein, but about the permission checks. Right? So some users were running into some issues where the application would allow you to change fields that you didn't have update permission to, for that exact reason because the update permissions were using a field that the app cannot read because you didn't have read permissions to those fields. So, therefore, the app couldn't know if you had access or not. So it would just default to, like, okay. You can do it. And then once you hit save, the API would just throw an error and be like, no. You cannot do it actually. Right? The way we solved for that is with a new endpoint in the API that basically say, hey. For the current user, am I able to update this particular item in this particular collection? Right? And it will return, like, these are the fields that you can edit, as far as I understand. I I'm a little hazing the execs, you know, IO, but that is effectively the gist of it. Right? And it feels like It feels like this feature will probably go in a very similar direction, where we need to have some sort of API endpoint where the app can say, okay. Here's the current about to be safe changes. For the for the current user, what should the conditional state be, I guess? Right? Because that's the only way. If the the app cannot read fields that are used in the conditions, it's kinda game over. Right? However Interesting. How how would how would that endpoint look like? Like, what type of payload how would that translate all of the different requirements that we have? Interesting. So I'd imagine I I know the requirements generally are, a, we need to fetch all of the data that is used in the, conditional fields rules. Right? So we just have to look up what are all the fields and what is the whole tree that is used within the conditional fields and fetch just those in the exact same structure so so we can run the checks against it. Right? Then we need to dynamically apply all of the staged changes from the user because one very important use case for conditional fields is things like, you know, you click a toggle and you show and hide fields conditionally. Right? That's kind of one of the major use cases for this. So it needs to be real time. And then the last thing right now, I'm pretty sure that's, it just returns. I I think what we do right now is we effectively just loop over and and then merge the field's configuration for the current item with the conditional field result, sort of smash them together. Right? So if, like, the default field is hidden in your conditional fields, you have field that's visible, then that takes precedence, and we merge them together by by field key. Right? So we dynamically update the area of fields that exist within the form based on that logic. So to translate that into an endpoint, you would most likely have to have an endpoint that takes what collection are we in, what item are we in, because that might affect, you know, the the IDs and all that kind of stuff. And then what is the changes that you've currently made so we can dynamically merge those and then do all of that logic on the server side and effectively return a new list of fields that should be visible in the app. Right? That's theoretically possible. Tricky thing, performance. Right? It it is exactly. Like, I was already, like like, inhaling and just to, you know, finish your sentence so I can say that. Exactly. So, yeah, that that would probably then lead to, you know, some delay because, let's say, you type a name pretty quickly, you know, like, example, whatever. Now you made, like, I don't know, 6, 7, 8, whatever it is that you're typing. The key presses, alright, do we debounce those? Then, alright, we have another little delay. So we then have to contact the API, which gets the stuff back, and then we have another little delay. And then the whole experience might suffer depending on how exactly we do it. Because, like, even if we now if we now, start, like, debouncing, that could lead to other problems. You know? Like, if if we want something to change, if the the the the text field contains a specific substring or something. Yeah. Then then that won't trigger fast enough, basically, which, you know, is kinda not the point. That is that's really hitting it on the head because this has to be you click a toggle, stuff shows up. That's that's the goal. Right? So it needs to be immediate and interactive. So if you debounce it for a second or something, to your point, the experience is gonna suck because you click a button and then Yeah. You're already looking somewhere else and then magically stuff shows up. Right? This, it's instant. Right? Because the app has all the context and data and permissions and things that it needs, so this is instantaneous for this to show or hide. Mhmm. You know, make required, do whatever. The the toggle here, the app side is doing all that, and it's almost instantaneous where you go server side now if you're having to send back to server. I'm wondering, does WebSockets' real time kinds of capabilities help at all in this space if we work towards I mean, again, we've always wanted to make the app real time so that we can do, you know, multi multi user editing of records and things. Yeah. I think, realistically, the main it it would reduce the network latency a little bit, but I think the main time spent on this is re fetching the existing item data and then merging on the changes. Right? Now this is a nice segue because I just read it in the chat. Does it have to be solved dynamically on the fly? Question mark. I think the answer is yes, unfortunately, because it's based on the current user changes, so it's always have to be dynamic. Is it possible to require users to save the query somewhere, save like a SQL stored procedure kind of thing? If so, would that make it easier to resolve? Yes and no. I mean, it's again, because it's based on the current sexual users changes, we can't really have that prepared because you don't know what those changes will be. That being said, you know, if the item that you've just read, we could cache that for a little while. Right? The tricky bit is just when do you invalidate that cache? That's been a bit of an issue before, right, where right now we have to sort of auto purge the whole thing and it's kind of inefficient, which is a very high on my personal wish list item, but let's not psych sidetrack too much on that in this one. So so the the problem is we can cache that particular call to the database and just be like, oh, in the last, you know, 10 minutes, we already fetched this. It's probably the same. But if some other user changed it in between, you know, it gets a little bit tricky. But we could cache the database call for sure for sure. If so, would that make it easier to resolve? Yeah. It would make it a little bit faster. We still have the network latency though. Right? Even if the API would just respond immediately from all the caches and skips all the execution, just by the nature of it having to go over the Internet, you know, you might have your the the API that you're talking to might be in a different region or something that might be, you know, a 100 200 milliseconds latency just from that. And then it's just the experience is gonna suffer a lot. Like, a lot. Right? Yeah. To a point where, oh, I see our own team here in the chat mentioning a similar thing where it's like, maybe conditions should just not support fields you don't have the permissions to. Because that way, you know, all the commissions, because then then you have this issue where it has to be on the API side. Right? So maybe one of the requirements that we're learning here now is that it kinda has to be on the app just to be able to keep that instant, feedback loop going. And then to mention for conditions not to support fields you don't have permissions to though, you have to configure it on a sort of per role basis what those conditions are because only on the role do you know what fields are available in the condition, Which is true, although that makes configuration hack a lot more annoying. Because if you just have you know, I wanna show an email field when you click, subscribe to newsletter or something. Then now you have to reconfigure that for every single role. Right? Yeah. Chicken. There's always plan c, which is just aggressively saying no relational fields and conditions. That's kind of what we've been doing so far. You know? It it sucks. Does Paul is does the new policy system maybe allow us some better flexibility so that it's not on a per role? It's configured, but Oh, don't get me started. But, again, it's a lot of and no. It does require, I think I think this I I think the the idea is this really has to be either real time in some way, you know, WebSockets implementation, the app itself. Goal longer term is to have that kind of capability anyway. But with a policy based, you know, if we are able to, you know, walk the conditional tree and we can we can see that and pull the data necessary. Now it might be that we wanna limit, you know, number of conditions that you can apply or number of levels deep you can go with a conditional. Right? Because I don't know that we can have an you know, the infinite depth capabilities. You know, I can go 18 levels deep in a condition that seems insane to kinda try and cash all that, or even manage all that in front end. But is it you know, maybe it's a 1 or a 2 level deep is what is allowed, from a conditional rules perspective kind of thing where it's manageable, controllable, and sustainable. The the thing to me though when it comes to conditional fields, to me, that is more a form builder type of thing than an access control type of thing. So having to configure how the form behaves on a policy to policy basis feels hard to manage, if that makes sense. Because now you're the output form is just it's hard to expect what it's hard to know what to expect once you have, you know, multiple different policies doing multiple different things when it comes to form building. Now this is a complete sidebar. That's also the beauty of these sessions. Right? Divergent thinking. Love it. Here we go. Strap in, folks. It's there's there's another singer, Annette. See I see you nodding over there. But one thing that we have been sort of, you know, floating the idea of is this idea of, like, what if we decouple the data model from the form. Right? So it's decouple the actual actual how you interact with the data from the data model itself. So therefore, you could have multiple forms for the same database table. Right? And then in a policy or in a role or whatever, you would choose what is the form that we wanna use for this particular table, for this particular set of users. Because the one of the other known I mean, issues might be a bit of a big word, but one of the other downsides that I've on my personal wish list, it's kinda like if you have read access, we we show and hide fields that you'd expect. Right? You don't know that a field exists. It doesn't show up in the form. It also means that if you're doing a form building exercise where you have, like, multiple columns, like, 2 things side by side, and all of a sudden one disappears, you know, the form kind of reflows, but it it results in a bit of an unexpected state. Right? Mhmm. So by having, you know, that form, having that form decoupled from the data model, now you could just say, okay. We're gonna make a form that we know will look exactly like this. Like, what you see is what you get for the form or the role that we attach it to. This is, again, a way bigger discussion than just a little brain fart dumping out into the world here. But that is that is, you know, one of the ways around this because then you do have conditional fields per role or per policy group or whatever you wanna call it. Alright. Many, many different things. I'm trying to I'm trying to find a way where we can, you know, like like, define a little pathway for us right now, but it's it's very hard because there's so much so many different things that we could do, technically. So yeah. Yeah. My initial feeling, like, when I read about this was, yeah, it sounds very reasonable, like, in the naive way, you know, the very naive, first understanding of the of the problem. Very similar or basically what you said in the beginning. Alright. So we do know when we open the form, what people used inside of the conditions. Alright. How about we then fetch those things, all of the related stuff to separately from the table? Alright. So far so good. Then the permission issue comes in. Alright. Are they allowed to read this? Yes. No. Alright. What do we do if they and, and then it gets tricky, and then it starts to spiral. Alright. Goddamn. Okay. We got we got a couple. Yeah. We we got a couple of steps that sound like alright. Alright. Maybe maybe yes. Yeah. And okay, permissions. There's there's always the point where we could put limitations in place. Right? It's like, we like to think with the least amount of limitations as we can while keeping it fast. But to Tim's point earlier, we could make a line in the sand and say, okay. You know what? Nested relational data is only allowed if you have read access to those those data points. Otherwise, it's just not intended to work. Because that way, we can remove the server component, keep it on the app site, and make it work the way you'd expect to make it work fast. But we put a ceiling in place to make that happen. Right? That is a very real, a very real in between. I'm I'm still been noodling on that that idea that you had, Jonathan, to, like, could WebSockets potentially help with this? And the more I think about it, the more I'm like, maybe, just maybe. Because if that database call is heavily cached and we send, you know, a message of, like, here's the stage change ID such and such, and then the API will just respond as fast as it can with, like, the the combined change and the new form that comes out of that. If we can heavily cache it enough, we can make that work. Now I see Tim typing in the chat. I'm curious if he's gonna say the same thing. I knew it. That was exactly what I was gonna say. He put in the chat, WebSockets are great, but we cannot rely on them for stuff like this as they're not a hard requirement to run direct this. Not yet. And this is this is a different question, of course. Like, should it be a hard requirement or not? Right? Because and this is again a a bit of a sidecar sidebar from from this, this particular discussion. Because the way we implement the WebSockets right now I mean, first and foremost, we haven't really used them in the app yet, for very similar reasons to this actually, which is, like, we have to be careful with relying on stuff, maybe, yes, no, and then tricky tricky. The the the real question is, you know, WebSockets are not supported everywhere like regular HTTP requests are. Right? So for example, there's there's a couple of platform as a service providers that just will not work with WebSockets in your container or something. Right? Because there's so many hoops you could jump through. You gotta go from, like, you know, the CDN to, like, some sort of load balancer to some sort of proxy container to some sort of, you know, container that has the actual connection. Yeah. And to to Tim's point in the chat now too, if you wanna do snazzy things on the edge, like scaling back to 0 containers or something, you cannot have a persistent connection at all. Right? Which is another very good point. I know there was another this another discussion thread that has seen some activity recently around, being able to run directives in a serverless environment, which, oh, boy, is a whole different session of one of these. I'm sure. But if that were ever, you know, a deployment target that we wanna officially support, then WebSockets are just out. They're just unavailable to rely on, right? And then the question really becomes like, okay, what what is more important to us supporting serverless environment scaling down to 0? Or are we gonna say, well, Directus is just a a a tool that is intended to be a long running server because with cron jobs and hooks and all that kind of stuff. And therefore, WebSockets are just enabled just like the API and you can use them and we can heavily rely on it in the app to make it faster and a better experience. Right? That is gonna be a difficult call to make, because it's it's it's, at the end of the day, a little bit of a subjective one. I know it's it's, we haven't really done all the pros and cons of research and all that kind of stuff. But it's like, you know, people have very strong opinions on this kind of stuff. Very strong opinions. We have to be careful, with Tim. He probably has one of those. Like, one of those nasty opinions. One of these nasty, nasty opinions. Oh, no. No. No. No. Alright. Yeah. Yeah. With the angel emoji. Alright. So far so good. Then let's maybe, you know, do the little, exercise. Alright. Let's say we go down that route that we mentioned with alright. You can't put conditions on stuff that you can't read or that this specific user can't read. Alright. This would have a couple of repercussions. Right? Like, then alright. You have multiple different different user roles. Do you then, as an admin that is configuring this collection, do you want to? Probably not. But do you want to actually configure then these things between different roles all the time. That sounds like a big pain, to be honest. Like, very annoying. Would we? Yeah. I mean, we do have to attach it to some kind of role. Right? Because, as of right now, you know, there can be, like, unlimited different types of user roles. Yeah. And some of them can read those fields. Some of them don't. We don't know that. Would we like to share this then with some type of diffing between those? But oh, man. This this just sounds like spaghetti, like, the largest bowl of spaghetti that you can think of. Weird. It doesn't sound enticing to go down. Yeah. I think the the the conflict that we're finding ourselves in is that we know you can configure conditions for fields that you might not have access to and then it doesn't work. Right? So what are we gonna do to help the admin user in that situation? Like, we need to educate them on this. We need to educate them on the, on the on the limitation there or show it somehow or prevent them from making that mistake in the first place by connecting it tightly to a role somehow. Because once you connect it tightly to a role, we know what fields are available, and we can only service those in the conditions. Right? Mhmm. I agree with your earlier sentiment when you were, like, configuring that on the role and having to reconfigure it for every single role that might access this thing feels like a nightmare. That feels like so much extra work. Mostly because and and I briefly touched on this before, but mostly because I really see this as a form building tool, not so much an access control thing. Right? Yeah. It's to me, it's similar that you wanna have 2 fields side by side. I wanna have one show up and hide based on the value of the other. That's that's all sort of form building magic, not so much access control magic. So I I kinda strongly feel like we don't wanna conflate those 2 and and put, like, too much form building stuff in access control. Because it Right. It just makes me context. Yeah. Thanks. So, similarly alright. How about then we reverse this a little bit? So, let's say, as of right now, you know, the admin goes into the collection thingy into the conditions and configures, you know, how it's supposed to look like, all of the different conditions, you know, height depending on this checkbox, make the title red. And then we attach a roll to that filter and we can now check, you know, is this role can this role even apply this filter? And we can immediately just say, oh, no. This role is not compatible with this filter because it can't read x and y and z. And this would also solve, like, solve let's let's in big big big quotation marks, solve that problem of, you know, like, having multiple user problems having multiple user roles that you could, you know, just say, alright. But this filter is, yeah. I I'm already, like, thinking while I'm talking. So then you come into this whole thing. Alright. Maybe you want to have different conditions for different user roles. Maybe. Here we are again. Here we go. Here we go. Love it. That's the moment where it starts spinning again. Tim, just in the chat, does not make sense to build your forms based on what fields you have access to? Which, yes, I think that is kinda closing closing in on the the sort of wild wicked idea of saying, what if you can just configure multiple different forms and you can just make a form that is dedicated to, you know, one one role? So that way you can you know for a fact that all the conditions exist and all the fields exist, and the way you configure the form and the layout is tailor made for that role because the only fields that exist are the ones that exist for the, for the item. Yeah. I can I can feel I can already, like, feel the pain through just thinking about this of, you know, the then, like, synchronizing between different types of forms between different types of user roles and oh, man? It's getting it's getting a little bit of rough. Let's say let's say rough. Alright. Tim has another thing. You effectively already do that using access control as the form will not render fields you don't have access to. Yeah. Which I think might become an issue at some point in the not too distant future. Because one other thing that we've sort of been been noodling about, Jetta the Jetta, is the idea of a little bit more flexible grit for forms. So right now, it's it's a 2. Right? You can either make a full width or you have 2 side by side. That's it. We also just been thinking about, like, what if we make that just a configurable number with some with some responsive breakpoints potentially. You could make it a 12 grid. You could make it in the 8 grid. Whatever. Right? At that point, if the field in in column number 6 disappears because of redexes, we cannot we can no longer sort of cleverly reflow it, to make sense. Right? Because now we legitimately just don't know where things are supposed to go anymore on the page because it just it it just has to be become a a gap, basically. At that point, we might end up having to just show, like, there used to be a field here, but you don't know about it. Right? Because otherwise, the whole form layout is tell anyone. Because otherwise, the form layout is just gonna look either broken because you're gonna end up with blank spots all over the place, or, you know, if if we're trying to I I think it's safe to say that we're trying to sort of reorganize it on the fly. It will break, because we just don't know what needs to go where at that point. Because it would be a multidimensional grid. Right? That will be 2 dimensional because you can have things go 2 rows or 2 columns, etcetera, and then you have a problem. Right? Kinda like, I think of dashboards basically in terms of just positioning stuff all over the place. But if we go that route, if if that ever comes to fruition, right, again, it's just a random thought. It's not actively being worked on or anything. But, if we're going in that direction, I think we need to have some sort of way to have a form per role anyways. Because otherwise, you know, you're gonna either have a form with a bunch of holes in it or with place holders that you're like, hee hee. You can't actually see this. Or, you know, or it just needs to be per role because that way you can just make one that is, you know, tailor made for for that particular role. Well, whether or not, we're actually, you know, looking into this, we already have our first customer. Then he said, I'm sold on the option to build a form per roll. So good. Sold it already. It was fast. I like it. So if we can inherit, like, a global so it inherits the the default kinda data model form that you configure, and then allow you to adjust that on the specific role, I think that's actually pretty freaking cool because we do have those kinds of use cases where, you know, this particular business and especially if we could apply specific conditionals on that form, it means that, you know, my business user versus my consumer user could have a very different form experience intentionally and different conditionals. Right? The the default conditional for the business user presets those conditions and organization. I I kinda love the idea. Whether or not again, this this comes back to whether or not this actually we we decide to allow additional depth, you know, conditionals. Just having that particular feature seems kind of amazing. As long as we can inherit the default, then if I don't need that kind of capability, I can just use the default and manage the default that we'll get. If I've got a custom reason for adjusting the form. Pretty brilliant. I like it. So there's a question by Benny Wade. Could we make groups configurable per row rather than making a whole form per row? Keep it a bit more modular. AKA, can we nest these forms? Yeah. That that Let's check as we check-in with our friend v form and see how he feels about it. -Oh, boy. Can't wait. Guys, if you enjoy messaging, please. Where you have the forms that or the view of the page or whatever you wanna call it is the same for everybody, but then you just have a section where it's like this section only shows up for x role. Right? Could be interesting. That is a conditional field in and of itself, of course, where it's like, the condition is show or hide this thing if current role is x y z. Right? Which now I'm thinking about it. I'm pretty sure that exists. Present time. I'm pretty sure you can this is something I'll have to test, actually, because I know we have those dynamic variables for current user and current role in those. I don't remember if we support those in conditional fields. Because if we do, you can step a group and have a conditional field on the group that says current role equals x y z and then hide the whole group. We do not, Tim. Tim and a chat. Why not? Why not? He calls me out he calls me out on my bluff. It's happens happens sometimes. Yeah. But that would theoretically be a a soul for the same thing, though. Right? Or you could just say the whole group is hidden for a role, and therefore, no problem. You make it so that you can have the same field in different presentation section configured per role? Right. Right. So the same field multiple times. Yeah. That is that is another thing when it comes to dynamic form building and, just full stop dynamic form building at that point. Right? Because right now, the form is data model first. It's like you have a title field, therefore, you can now have a title input because it's 1 to 1 to the data model. Right? With a form building thing, maybe you have 2 title fields, like, 2 fields that point to the same underlying data thing. Right? There's instinct. I don't know why the hell you would do that, but you could. For for some interface, it may set I mean, in this this example where it's like you have the same field in different sections and the section show and hide based on the role, it starts to make sense again. I for admin users, it'd be interesting, but it it yeah. For sure. Then for, I I think there's a a definite interesting use case for certain data types where it would help to have multiple fields, multiple visual fields for the same underlying column. Think about, like, an address interface face or something. Right? Where you wanna have address line 1, 2, and then, ZIP code and all that kind of stuff, but you wanna save it as one field in your data model. Not super uncommon, or as a let long sort of search thing, right, where you have a let and a long input and then an address field, and those are all connected. So you can type in an address and it'll geo look up the let long, but then the thing that's saved in the database is just the let long. So there's definitely, you know, some additional things that we unlock with that sort of modular form idea. Right? Alright. So what I gathered from this, is that we're basically about to build our own page building framework where we can dynamically close plugs. So we're basically set, you know? Like, director's page building, that sounds like a great idea. Okay. On the So just to solve condition fields. That's that's the beauty of it, isn't it? How did we how did we get here for just solving nested conditional fields? Yeah. It all started so innocently. You know? It's true. I just want to hide a field, and now we're basically embarking on a mission to Okay. This is this is actually this is a good thing because this is a perfect example of the sort of, you know, request review session. For those who've been here before, you've seen this happen before. It's like we go completely off the rails in all directions, and then now let's try to see how we can actually get this back on track for nested conditional fields. Right? So as a you know, in a potential future utopia where you can just magically conquer up any sort of form, any sort of view that you possibly want. Great. But as of right now, I'm kind of thinking, based on everything that we talked about so far, it, to me, makes the most sense to follow Tim's suggestion from earlier, which is basically you cannot put the field and conditional fields that the user does not have read access to. Right? I think that is that is a safe call. I think doing it on the API side, we're never gonna be able to get it just performant enough, and we don't really wanna make WebSockets a requirement for this to work. So I think as of today, you know, what can we actually achieve in the next month or 3? We would most likely keep the client side, keep it fast so we can do all the calculations on the client. It has to be from current fields that you have read access to. The main difference that we have to do is that we have to dynamically, when you open the page the first time, we have to load up what is the nested data structure of this item based on the rules used in conditional fields. And then have some sort of utility function that can cleverly combine the stage changes on top of that. Right? We have to account for the differences like many to one ID versus nested object. We have to account for things like the one to many update structure versus array. But that that way, we can merge that and we can do a client side. Right? I don't think we should do that per role. That just feels like a nightmare to configure, to be completely honest. Yeah. And a lot of a lot of duplication. Again, in a utopic utopic utopic? Utopia stick future. Utopia like future. Utopian? Utopian future, you know, where you have more of this flexible form idea. At that point, you know, you can say, okay, When someone I'm already boring Jonathan to death, I see. When when you open this this page for this particular role, we use form xyz instead but that is again a way way future discussion. But then I think, you know, we can support the core ask for this this feature request, which is if I say nested author dot name, I expect that the lookup, what is the name of the nested author no matter what. If I select an existing one, it needs to look at the name of the existing one. If I change somebody's name, it needs to look at the changed name. Right? That is something that we can I'm pretty hopeful we can turn that into some sort of usability function that we can run relatively quickly on the client side and make this happen. Right? Yeah. That shouldn't be shouldn't be impossible. Yeah. Yeah. Look at the from Natron. And 10 rabbits with 1 multiracial conditional stone. Yeah. Exactly. As an admin that's configuring these conditional fields to another person in the chat, it would be nice to see the whole form that a person with a given role would see. Maybe a view as role option somewhere. Fully a 100% agree. To Jonathan's point, there's another feature request about that user impersonation. Again, very high on my personal, wish list. Right? I would love it as an admin. And not so not just for the for the particular form and settings or something. I really want there to be a way for admins to just say, browse the whole app, impersonating a different role so that you can just click around and see exactly what that user can see and do. Right? From a visual perspective, we'll probably have to have some sort of banner, zoom out a little bit or whatever. We'll figure it out what that looks like. But that way, you can just configure it, see the whole thing as, you know, that particular user. Now especially dreaming wish list, it'd be great if you could just change the form while you're on the page looking at what the form looks like for that given your role. But let's I'll get ahead of ourselves. We're going back. We're going back, guys. Back to the page. We're spinning. We're spinning again. We're spinning again. Let's not spin too much. Yeah. But no. That's a it's it is a very good idea because also with the other feature request that we talked about. Was it last time or not too long ago where we're talking about the rules and permissions as a whole. Right? And these policy units and whatnot. Now that these policies become way more composable, buzzword shot, we can actually you you also have the problem that it becomes a little bit harder to figure out what is the actual permission for this one user now. Right? Because it could come from multiple different places and you can have on the user overrides and that kind of stuff. So I think user impersonation becomes way more important, with that in mind as well. Great. Let's see. We caught up to the chat. If anyone has any last questions, please let us know. There's not much time left. I was running out. Just the the call to action, you know, just to get them going. Yeah. Just a moment. Please like and subscribe. Yeah. Yeah. Yeah. Yeah. Hit that notification bell so you'll stay up to date. But if you truly want to stay up to date, you should head to direct us dot io/tv. I I nearly said dot tv. Yeah. Alright. No. But seriously, on the directors dot iotv, there's lots of interesting series that you can check out, such as this one and also other ones. And enjoy. And see how Directus TV was built on Directus. Very cool. It's exciting. That is pretty cool. We have Jeron to join literally in the last minute. Hey there. Hey there. Thank you for joining. How you doing? We're about to call it. Goodbye. Anyway. Very, very exciting. As always, thank everybody so much for watching. This was yet another talk where I was, like, going into it, it's like, oh, this feels like a small little bug that we could just fix. Right? And then we talk about it now, and I'm like, oh, man. Okay. It deep go. Building a form builder and page builder. Now now we're getting snazzy with it. But that's that's the beauty of these sessions, and I love it every time. So those are joining. Thank you so much. See you guys in 2 weeks from now. Or oh, no. Wait. That's the one that we're skipping for the, you know, the special week week. Yep. It'll be, 4 weeks before our next one, folks. Thanks so much. Appreciate your patience. There's some big announcements coming that that this next week's time or next 2 week time slot is gonna be consumed with other events, and keep an eye out for the live events and things going on that week. So very exciting announcements on the way. We're we're excited to have such an awesome community. Have a great day. Have a great week.","published",[149,159,168],{"people_id":150},{"id":151,"first_name":152,"last_name":153,"avatar":154,"bio":155,"links":156},"23ebcf2c-4374-4f5c-8198-f8ad497fd856","Rijk","van Zanten","7ef9652f-3835-432c-a43a-c5fe13001f31","CTO of Directus",[157],{"url":135,"service":158},"website",{"people_id":160},{"id":161,"first_name":162,"last_name":163,"avatar":164,"bio":165,"links":166},"0d906492-75f0-45d9-abf7-ab779bf1ed08","Jonathan","Wagner","5062e4df-a198-4b40-af47-42362d3c0551","Sales Engineering Manager at Directus",[167],{"url":138,"service":158},{"people_id":169},{"id":170,"first_name":171,"last_name":172,"avatar":173,"bio":174,"links":175},"07ec688d-251d-4efe-bc17-73848402d43b","Daniel","Biegler","8897b70f-c524-460a-8990-58cc5c3be886","Engineer at Directus",[176],{"url":141,"service":158},[],{"id":179,"number":180,"year":181,"episodes":182,"show":195},"6aa046f1-bd53-4510-9af0-c0f3daaf4415",1,"2024",[183,184,185,122,186,187,188,189,190,191,192,193,194],"daed2c08-703a-43d6-ac97-aacac61be4c0","86fa152b-6a8b-477e-94b5-bd91e1202d21","0b5f4343-1494-455b-b41a-25811c151242","b63afbe1-6418-4e9e-b1da-4890979789f0","69ad81e8-5e1d-4b85-9fa9-3b767a3a3478","5c9c888c-f527-4608-a2f7-56f156d00980","243daa59-3772-4ebe-b212-c2a09a4a0b71","d66c1e46-cc57-49fe-a914-2e440bbc1576","12c8f72d-22fa-4ffa-a9d1-57047216fd1a","8896c934-aa2c-43b6-9342-8275682ab8b2","84c7b3ac-fd85-4539-8f39-3247118bcbf2","044b7c89-aaec-43b2-9d6d-6743a0fb5afd",{"title":196,"tile":197},"Request Review","73687d01-3734-4c28-aef7-e6fa8db4cf1e",{"id":186,"slug":199,"season":179,"vimeo_id":200,"description":201,"tile":202,"length":203,"resources":8,"people":204,"episode_number":208,"published":209,"title":210,"video_transcript_html":211,"video_transcript_text":212,"content":8,"seo":8,"status":147,"episode_people":213,"recommendations":214},"inline-data-editor","926603960","In this recording of our live event on March 21 2024, Rijk, Jonathan, and Daniel discuss inline editing.","db868174-6a9e-4823-9962-382f5bd55cb1",52,[205,206,207],{"name":134,"url":135},{"name":137,"url":138},{"name":140,"url":141},5,"2024-03-28","Inline Data Editor","\u003Cp>Speaker 0: Hello, everybody. Welcome to feature request review with me as a host today, joined by the good old Reich, Van Zanten himself and Jonathan Wagner. Hello. Hello, everybody. Thank you for coming.\u003C/p>\u003Cp>Very exciting to see you all. Quite quite the quite the collection of people we have here from Algeria, Japan, everywhere. Germany, Austria. No. No.\u003C/p>\u003Cp>No. I nearly said it. But, yeah, today today, everybody's, apparently favorite topic because there's so much demand here in the channel right now. Inline editing, which can mean a lot of things. So let's just take a look at what a small example could look like.\u003C/p>\u003Cp>If you take a look at the screen shared footage of Jonathan, you'll see this is our feature request that got in, which you can vote on, by the way, in case, some people are not aware of this feature in our discussions in the director's repository. You may vote on stuff that gets implemented into the software, which is pretty cool. And, today's topic is about inline editing. If we scroll up a little bit to the top to the screenshot, you might have seen this in other interfaces online, you know, when you use Notion or whatever, like, many many sites implement this a little bit differently. You know, on Trello boards, you can click into the title, then you can change the title right then and there without a pop up or something.\u003C/p>\u003Cp>And, yeah, why why doesn't have direct as this yet? It's a good question. I mean, there are many, many different things that we could talk about. And, in case you have any questions or stuff that you want to share, please feel free to use the chat. We're excited to engage with you guys.\u003C/p>\u003Cp>It would be fun, a sign of life like previously. That would be nice. And how about how about we jump in right into a couple of questions? Let me quickly, give one second. Alright.\u003C/p>\u003Cp>So by looking at this, you know, basic example with the with the input field, I mean, the the first question to me is, alright. Like, how how much can we blow this up to, because Directus is very, very versatile, and, people build the craziest displays and interfaces and very, very customizable different pieces. How do they fit into this, and if we just target, like, simple inputs, for example, like in these simple example with, like toggles or text inputs. What about relations? Because those tend to be very nice to deal with.\u003C/p>\u003Cp>And, how about we go over to give over to Rijk for this one? How do you feel about different types of inputs for inline editing? Do you think we should, like, aim to be able to do everything in in in line editing? Should we reduce it down? Should we only support a sub set?\u003C/p>\u003Cp>How do you feel about inline editing in itself?\u003C/p>\u003Cp>Speaker 1: I mean, when it comes to inline editing, I think the first question that we gotta ask ourselves and everybody watching is like, what does that even mean in the first place? Is it kinda like a spreadsheet where everything is just a cell where you can change whatever you see? Is it more like, a table view by default where everything looks pretty through those displays, And then you have some sort of edit state. Is it like, an edit state where we render a whole interface in line? Or is there some sort of dialogue overlay that we're seeing when you click on one of the cells, so to speak, to to stay in spreadsheet terms.\u003C/p>\u003Cp>So I think the first question really is what is what is inline editing? What does it even mean? Right? Because we do have a different feature request for a spreadsheet view, which I think very closely overlaps, but there's definitely differences. And then I think the other question, of course, I mean, relationships, we'll dive into that in 5 minutes.\u003C/p>\u003Cp>But, if you think about the basics, I think one of the thing that we're doing with direct is with all the interfaces is to make sure that you can edit the data in a way that makes sense for what the data is. Right? So, a very basic example, you know, a slider could be a better representation for a numeric value that you're using for whatever it is that you're building. Right? But You wanna use a slider to control the value.\u003C/p>\u003Cp>When it comes to inline editing, you know, if we're looking at this screenshot where the reserve column right now presumably is in this edit state, you know, if we're dealing with inline editing in its sort of truest form, does that mean that it just turns into a sort of raw value input? Or do we include interfaces kinda like we are with a regular form? Right. So when it comes to a date value to name something, the technical value is always gonna be that that what's the exact spec, the, ISO 8601. Is that the thing that you wanna be editing?\u003C/p>\u003Cp>I would argue, probably not. You probably wanna have, you know, the data interface that you have configured for that field, which then leads to the question, does that even fit wherever we're doing this inline editing presumably in this table layout. Right? And I think we're we're quickly reaching the question then is like, okay, do interfaces even fit? And if they don't, how do we present it otherwise?\u003C/p>\u003Cp>Speaker 0: Right? Yeah. To your example, like, even even a simple slider, which is a nice way to input, like, a specific value inside of a range, which could be, you know, like, relevant to the use case, you know, where you want to restrict. You maybe you don't allow, like, negative numbers or something. But if if we allow, like, editing via raw values, then somebody might put in, you know, minus 1 or something, and then you very quickly run into the issue that you mentioned.\u003C/p>\u003Cp>We want to give people the tools to, like, input stuff as as as comfortably as possible with using, like, nice interfaces and displaying like, even displaying, you know, with with the value that you see inside of the table might, like, might not actually be the wrong value just like you described with the, like, date time, for example. So there's a disconnect there and, like, for, like, nontechnical users, for example. No. It could be it could feel bad, you know, from a user experience standpoint where they like if if marketing salespeople, what what was the thing that's, somebody said I won't name any names, but somebody said, like, the scariest thing that marketing people see is, like, a UUID somewhere. So we're dealing with UUIDs.\u003C/p>\u003Cp>Yeah. It is, is a scary endeavor, so you have to be quite careful with the display. So yeah. Yeah. Speaking to that, we have why don't we explain a little bit about the difference between our interfaces and displays?\u003C/p>\u003Cp>Because, you know, indirect is also 2 different things. What are those? How do I use those? What can they do?\u003C/p>\u003Cp>Speaker 1: Good question. So so from I'll I'll prefixes was sort of the theoretical idea behind it while Jonathan here pulls up the actual difference and how you configure them. So the basic idea is that a display, controls how a raw value is displayed in line, importantly. So it's really meant to be part of a sentence or one of the cells in a table or, you know, part of a description or something. So if you think about a, labels display, it can be configured to render it as a small color dot with a tooltip, with the idea being you can then render that in the title of a page, or in the description of a card or inside of a table.\u003C/p>\u003Cp>Right? The interface is really the the way you edit the value. So if you go and you open an item, it's basically the form field, section of of how you interact with that data. So it's really the difference between sort of block level, in CSS terms, editing of the data versus inline displaying of that same data. Importantly, those 2 can be very different representations of the same data.\u003C/p>\u003Cp>Right? So the image display will just be a tiny thumbnail where an image interface is like a bigger box where you can drag and drop stuff in and you have, like, preview and some more metadata available. They are at present a different thing. And the display is then Yeah. So so Jonathan right now is, you know, adding, a related values you know, those displays, and compose them all together to really control how an individual item is presented.\u003C/p>\u003Cp>Right? So on the collection detail page 2, there is a display template setting where, again, you can render individual fields as part of one title string. And then that's how it displays the individual pieces of data. So when it comes to editing them in line, one of the interesting, challenges that we're gonna be facing when it comes to the table layout specifically is that the value that you're seeing in here, it's very likely that that's not the value that you're gonna be editing. Right?\u003C/p>\u003Cp>Speaker 2: And is it a toggle? Is it something that you enable or disable? If you haven't enabled, what happens? If you don't have an enabled or how do I access the record? Because currently, you know, I just know that I can just click anywhere on the row, and it will open the item for me, and I can edit the item.\u003C/p>\u003Cp>How do we trigger, you know, you start to get into that. So we've got the whole interfacing aspect, relational content, allowed or not allowed. It feels like at least maybe you could almost do it in, like, an iterative. So start with the normal input fields, date fields, the the simpler interfaces and things to deal with versus relational. Relational gets complicated, right, depending on how deep or how complex that relational is.\u003C/p>\u003Cp>Now in order to edit this translation, well, that requires now that I get the full translational split toggle side by side translations kinds of things, and is that beneficial in this kind of a in this kind of utility? Yeah. Toggles, drop downs, you know, some of this, some of the more string text slash\u003C/p>\u003Cp>Speaker 1: Is this is there there is a a another additional question when it comes to how do we then render an interface to change the data, which is that there's gonna be a couple of them where the interaction would be way nicer if it's, like, truly in line. Like, so if we, if you think about a toggle, like a checkbox. Right? Kinda like the default checkboxes for selecting items. But let's say you have, you know, an on or off state on your own custom item.\u003C/p>\u003Cp>In your display, ideally, I just wanna click it and it flips. I I don't wanna click it then open a dialogue that shows me just one toggle anyways, and then close it, and then change it that way. You know what I mean? And I think the same goes for basic text values or basic numbers where I just wanna be able to click the text, edit it, and then that's it. Right?\u003C/p>\u003Cp>I don't wanna have to deal with clicking it, seeing a popover, drop down dialog, whatever it may be, then change it there because it's just another step away for something that feels like it could have been a spreadsheet, basically.\u003C/p>\u003Cp>Speaker 2: Yep.\u003C/p>\u003Cp>Speaker 0: With that example, you know, with just clicking in and changing something, Tim also brought up a nice point because, with nullable values, like, even such a simple thing as a, like, togglable checkbox, if that is even a word, you know, we already run into, like, a small little, thing, like, okay, what if you want to set it to null? You know? Like, if you uncheck the thing, it's false, but you want it to be null. Do we do we, you know, do we, like, enable triple, like, stateful checkboxes that support 3 values? Do we want to have, like, a ellipse that gives you, like, a setting for that?\u003C/p>\u003Cp>Like, similar to our v form where, you know, you're allowed to enter a raw value, but that's another piece of UI that would have to be somewhere some at some point. Yeah. Exactly. For strings, similar in that vein, you know, for strings, do you want a, empty string, or do you want a null value? Alright?\u003C/p>\u003Cp>How do you differentiate between those?\u003C/p>\u003Cp>Speaker 1: And it can even differ,\u003C/p>\u003Cp>Speaker 0: you know, from from to\u003C/p>\u003Cp>Speaker 1: Yeah. All of those are problems that we have solved in the form context. Right? Because even in the form, there's just the field label drop down that says empty this value, which is effectively nullifying it. So the question is also how much of that do we wanna pull a level up in here versus how much of that do we just say oh well if you explicitly wanna change a boolean back to a null, you can always go to the page detail thing and then do it there.\u003C/p>\u003Cp>Right? There is an escape hatch, and we could make the call to say, well, you know, the toggle display goes between true and false. And if you need to reset it back to that null state for whatever specific reason, you can always go to the detail page, and do it there. Right? And I think similarly for the string empty update, empty string, null, that that question is a question that we've currently solved on the interface settings, I believe.\u003C/p>\u003Cp>Therefore, an input interface, you can say empty string becomes null, and then that's just the value it, you know, stages, it emits. So if we go the route where we use the exact same interface you have already configured as the way to edit it in line, that problem should sort of automatically be solved. Right? Because we're using the same interface with the same settings, and then that should be fine as is. Where that part gets super interesting though, is how do we deal with conditional fields within the context of that row?\u003C/p>\u003Cp>So the way conditional fields currently work is, you know, you have the whole form of on the field, you have the whole form on the page, and then we can use the values of the form and sort of connect the dots. Right? And use it that way. On a row in a table though, the fields that are displayed might be completely different. The second piece to that is gonna be for conditional fields.\u003C/p>\u003Cp>They're now react reactive in real time where if you make a change to one field, sort of real life like, real time updates it elsewhere. When you're in the context of an individual row, and I think this is just a bigger question overall, is, like, does it auto save every time you sort of blur the input that you change something in? Or is there gonna be a save button that is like, okay. Now you've made all the changes and you hit save once.\u003C/p>\u003Cp>Speaker 0: That's a very good question. Like, especially for, like, the togglable checkboxes or whatever because, like, if you just miss click somewhere and all of a sudden, that could be a big change, you know, like with flows and automations and other stuff that runs or update events, fire something. If you hit publish on something, that should be, there should be a mechanism, you know, to stop making mistakes, you know, like, accidentally, if you have, like, you know, is active or is published field on some type of blog post or whatever, and you don't want to accidentally just oops. Oops. It's live now.\u003C/p>\u003Cp>Oopsie. Would would be nice if we could avoid that, but, yeah, that opens up another can of worms. You know? Like, how do we do you configure this on a field level? Do you configure this on a column level, on a, preset level?\u003C/p>\u003Cp>Like, where where do you where would you like to do that? That's also the thing. Because very good point from the chat also from the, is currently, for example, the displays do not know, like, which item they belong to. They are very stupid in that way with quotation marks where they just Yeah. Display a value.\u003C/p>\u003Cp>This is why they're called displays.\u003C/p>\u003Cp>Speaker 1: It's it's a presentation, presentation layer. Yeah. Yeah. Yeah.\u003C/p>\u003Cp>Speaker 0: So if if we would like to have the, you know, like, mutable, displays or whatever, you know, if we decide to go that down that road. So, we would have to provide the displays with the item ID in the collection, like, in every place because there's not not only displays only in the table view, in the tabular layout, but also in, like, titles and drop downs or whatever. Like, any and they could be at any place at any time, which makes this a little bit, dangerously spaghettty like, which\u003C/p>\u003Cp>Speaker 1: which which also, kind of bleeds into a similar yet different question, which is where do we allow inline editing in the first place? Because we're assuming we're sort of assuming the table layout right now because that's the most commonly seen elsewhere. I mean, I'm I'm sure that people that have ever seen Airtable are like, that's that's the way. But at the same time, the the question is, do we inline edit elsewhere? Like, if you have a status icon in your page title, does that become an inline editable thing?\u003C/p>\u003Cp>Right? In the chat somebody says we'd appreciate it for the card layout, maybe even the calendar. I would agree. So on the card layout, if you have in your description of an individual card, you have a a text display. If you click the description, can you now edit the description of a card in line, which opens up a big can of worms, especially from a UX design perspective.\u003C/p>\u003Cp>Speaker 2: I I guess because because we're we're concatenating that into a string in the display right now for a card. Right?\u003C/p>\u003Cp>Speaker 0: Mhmm. Mhmm.\u003C/p>\u003Cp>Speaker 1: So if we're just The same for page titles for the for for that matter or the calendar layout. Yeah. Yeah.\u003C/p>\u003Cp>Speaker 0: And Tim, Tim, another fun, fun little thing that could happen if you're already editing something and you have auto refresh enabled. Somebody updated your stuff in between the edits, and now you have another edge case. Love it. Love it. Love it.\u003C/p>\u003Cp>Love it.\u003C/p>\u003Cp>Speaker 1: Which is gonna be the same issue that you have with, you know, the regular form. So I'm hopeful that whatever solution we come\u003C/p>\u003Cp>Speaker 2: up with that right now.\u003C/p>\u003Cp>Speaker 1: Yeah. Exactly. Whatever solution we come up with for that, I'm sure the same solution should also then work here. But Yeah. For this So this is a good example in the cars layout.\u003C/p>\u003Cp>Right? So in that right side bar, you see title, subtitle, and you can configure any combination of the different fields with any sort of additional strings in between, for like adding a dollar sign in front of price. That kind of stuff. Right? So in this particular case, it becomes extra interesting.\u003C/p>\u003Cp>Because if you now were to click on the number of the price in that description line, do you expect it to be editable? Right? And how do you determine that? Yes or no? Because making every editable globally at all times feels like a UX nightmare waiting to happen, but it also unlocks a lot of flexibility.\u003C/p>\u003Cp>Right? So it's a tricky one as many things are.\u003C/p>\u003Cp>Speaker 0: Of course. So how about how about then we take a different look? So now we thought about tables and the current layout and whatever. Technically, there's also another option of adding a new layout, like you mentioned earlier, with the spreadsheet layout, which could be the point where you do that type of stuff. I don't know.\u003C/p>\u003Cp>Maybe, you know, I'm just, you know, throwing stuff in the room right now just to discuss a little bit. But Yeah.\u003C/p>\u003Cp>Speaker 1: Because it does have the mute display thing. Yeah.\u003C/p>\u003Cp>Speaker 0: Yeah. Yeah. So maybe if it turns out to be better or easier or whatever, the spreadsheet layout could be an interesting point where we could tackle this, but, then we have new, cans of worms and cans and of worms stacked upon each other, you know, till this evening.\u003C/p>\u003Cp>Speaker 1: Stack a can.\u003C/p>\u003Cp>Speaker 0: Which which is fun. Yeah. Because, you know, a spreadsheet layout people come into a spreadsheet layout with lots of preconceived notions. Is that the is that the word? And\u003C/p>\u003Cp>Speaker 1: Like, I think expectations is the word I would say. Yeah.\u003C/p>\u003Cp>Speaker 0: Expectations. Yeah. Yeah. Yeah. Yeah.\u003C/p>\u003Cp>Expectations and and stuff that they would like to have or that they expect to be there because it's, you know, spreadsheets are, daily used by billions of people. So they do want to have, like, conventions and keyboard navigation and different stuff that they already, you know, introduced to the day to day life with bulk renaming, whatever formulas. Maybe they think that this is then an actual spreadsheet that they can do calculations in, which is another cool feature that we would like to have probably from\u003C/p>\u003Cp>Speaker 1: different feature requests for a different day. Yeah.\u003C/p>\u003Cp>Speaker 0: Exactly. Exactly. Exactly. So spreadsheet seems to be a very big thing, for me personally. Yeah.\u003C/p>\u003Cp>Speaker 1: I think to me it's just a very different thing, isn't it, than than this inline editing approach that we're talking about? Because I fully agree with what you're saying. If you close your eyes and you think spreadsheet, there's a whole set of rules that come with that. That if you miss one of them, you have a bad spreadsheet. Right?\u003C/p>\u003Cp>Because if you look at Excel versus Google Sheets versus Excel on the web or even Apple's, what they call it, numbers, they are all effectively identical in the exact same settings, exact same thing you can do. It's a right or wrong approach. So, funnily enough, for a session like this, it would be a very short call because it's like spreadsheet. It's basically a known entity at that point. Right?\u003C/p>\u003Cp>I think where it gets interesting to me, and this is sort of the the the Airtable spreadsheet equivalent. It's like, you're not dealing with the spreadsheets. You're dealing with a table that you can edit in line. But it's not a pure spreadsheet in the technical term, right, where you're dealing with cells with raw values, so to speak, rather than UI elements where you edit the values. Yeah.\u003C/p>\u003Cp>Same thing in the chat was was coined there. The reason why I immediately started thinking about okay. So our display is now editable as a concept is basically from that modular fashion. Right? Because making one new layout that does inline editing sure.\u003C/p>\u003Cp>We could totally make that happen. We could also make it an option of the regular table layout and then that's it. Right? To me the interesting question for this is really like, is there a way to make it work for any display anywhere? And is that something that we wanna do or not?\u003C/p>\u003Cp>Because by doing so, you get the tabular layout feature out of the box but you also unlock it elsewhere. Like, if you have, a list of one to many items on, a record, each of those one to many items now also has inline editing because they are using displays to render those values. Right? So it it just, like, it transforms this discussion from an inline table editor to a bigger sort of, like, what does that editing in situ look like across the board?\u003C/p>\u003Cp>Speaker 0: Very, very good question. I wish I would have the answer to it, but, yeah, like you said, I mean, for for for example, for the, like, relational stuff, I could see, you know, reusing the existing drawer that pops up in different places, which could be a nice experience. You know, if you let's say you have a, a website collection with blog posts or something, articles, whatever. And as the drawer opens and you can use the currently already existing, like, relations go through the list, it it's it's with pagination and stuff. That could be nice.\u003C/p>\u003Cp>But like you said earlier, if for smaller fields, it feels like add UX if you, you know, just want to change one text and then the drawer opens or, like, a pop up opens with just one input. That's, like, at that point, it just feels very not thought through, which I would like to avoid. Yeah. We got correlate with this PR. Yeah.\u003C/p>\u003Cp>Yeah. Yeah. The the batch editing is also a nice thing. So slightly different.\u003C/p>\u003Cp>Speaker 1: There's also the the, the bigger question here, Which is\u003C/p>\u003Cp>Speaker 0: As it always is?\u003C/p>\u003Cp>Speaker 1: As it always is. But it's that's that's what these sessions are. For those who are new, in these sessions, we always go find all of the edges and then take it back into what is actually realistic in the next step. But so think about it. If if we're now dealing so so you we explained it before that the displays were meant as a presentational only unit and interfaces are meant as an editable unit of the same value.\u003C/p>\u003Cp>Right? But now we're saying: What if displays are editable, but only at sometimes? So some displays like a string we wanna make inline editable, Some displays like a checkbox inline editable. And some like a relational related values or something we wanna have a click with some sort of dialogue to to have the space to make it a proper editing experience. Right?\u003C/p>\u003Cp>The question could also be, should those still be 2 separate entities or should they all be interfaces? And based on how we where we're rendering an interface, it can display in different ways. Right? So if you have an interface on a form where it has enough space to grow, it can show as a proper big input. But if you try to squash it into a cell of a table, it just drops the visual representation of an input and becomes one of those underline only in inputs for example.\u003C/p>\u003Cp>Right? Because then with a read only prop, yes or no, you can toggle between a string that's just rendered as a string. Or when you click it, it switches into this inline interface version, basically. Know what I mean? Because then for a display one, it can always just be interactive for an input, you can just click to start typing for, a related values one or a relation when you can click it and it would just do it in a pop over or dialogue or something along those lines.\u003C/p>\u003Cp>Speaker 2: So depending on the interface type or the interface implementation, you could allow or disallow inline editing ongoing. Right? Right.\u003C/p>\u003Cp>Speaker 1: It it would basically mean that the interface is always the thing that controls how it's displayed, because therefore you can have the interface control how that interactivity works in that display context. Now, that does, of course, come with the the side effect that you can no longer have a different display per interface like we currently allow. So theoretically, you could use, you know, a text input interface, and then an icon display if you wanted to. Or, you know, you can have a rating input that is a slider and then a display that's that's rendered as stars. I don't have the stats on how popular that is.\u003C/p>\u003Cp>Like, that would be a breaking change where we remove that. At the same time it also makes it easier to configure. Right? Because you can have, okay, I'm using the icon this, icon interface, and at smaller scales, it turns into an icon display. Right?\u003C/p>\u003Cp>Speaker 2: So I guess another option could be that if you toggle the, you know, inline capability here, then the display gets turned off. Right? You don't have display capability. So you don't have a breaking change, you have the ability to come in and edit an existing interface, keep the existing display capabilities where I don't know what the overhead looks like for that, but something that we could think about instead of just outright ripping this out because I I still think, again, this is gonna be, I think, the most common case where I would want the ability to do, like, inline editing is on strings and numbers and dates. Right?\u003C/p>\u003Cp>Those are the, you know,\u003C/p>\u003Cp>Speaker 1: the The the simple somebody in the the chat called it the simple\u003C/p>\u003Cp>Speaker 2: stuff. Yeah. If I'm dealing with relational, you know, now you're dealing with complex, you know, you're you're just as easily popping into the item at that point to edit a relational setup potentially. Now down the line, that could change, but I think the most common things, you know, based on the ticket that we got inbound was around I just wanna be able to update some numbers, and I'll be able to quickly go through and adjust some numbers. I wanna adjust some text, and it's not a bulk edit because I'm not making them all the same, but I wanna be able to quickly edit things in line.\u003C/p>\u003Cp>Relational's I don't know. My brain my brain, I can see the nicety of it to be able to quickly just pop an interface and make a change without having to open the entire work, you know, in and out of a record to do that, but I think short term initial implementation. But if we added a toggle here or a function that says, you know, disable the display, if you go to inline, then you get the interface, and that is the display.\u003C/p>\u003Cp>Speaker 1: Woah. Say say that again. So That last part,\u003C/p>\u003Cp>Speaker 2: if you\u003C/p>\u003Cp>Speaker 1: have a display but you use an interface and you toggle it, you now have a display. You lost me in that last part.\u003C/p>\u003Cp>Speaker 2: No. No. So I'm saying that if we add a new if we add the feature for inline on the interface so if specific interface designed to support inline, and you just say, I wanna use the inline or I don't know where we would set that.\u003C/p>\u003Cp>Speaker 1: I think it's set up based on the type. Yeah. Yeah. Yeah. Yeah.\u003C/p>\u003Cp>Yeah. I think somebody in the chat mentioned that it's too. It might have been the derp. Yeah.\u003C/p>\u003Cp>Speaker 2: It gives you the, you know, if I make c one in here, it overrides display. Right? Display is essentially either disabled, right, becomes grayed out here, or it's just ignored, and with a note here that says if I check-in line, then boom display is no longer utilized. We're gonna utilize the interface spec for that.\u003C/p>\u003Cp>Speaker 1: So so, you know, in the chat, mentioned a similar idea in that we could also have and this is a direct quote. We could also have multiple optional components for a single interface, like an inline version and a block version of the same interface. And then when the inline interface version exists, that can be used instead of the display, and then gray out the display to you your point.\u003C/p>\u003Cp>Speaker 0: Yeah.\u003C/p>\u003Cp>Speaker 1: Because the,\u003C/p>\u003Cp>Speaker 2: this gets ignored. As long as there's a note or a warning, you know, even if someone does set it here, it's just ignored. If in line is enabled here, then it just gets ignored.\u003C/p>\u003Cp>Speaker 1: Because the reason to then ignore the displays is because you kinda want the display itself to be editable at all times at that point. Like a checkbox, interface in the an inline checkbox interface would just be a toggle that's always active for you to click on. Because the comment that was just made in the chat too is like, you say you're loading a nested relational simple column in a table. You need simple editing. But in terms of toggling, you know, you can use the display by default.\u003C/p>\u003Cp>And then when you turn on an edit mode, maybe all of those in line ones are displayed so you still have displays. It gets tricky. So so the reason I'm saying that is we have things like the, formatted value display which is basically, a very configurable string. Right? You can make it bold, italic.\u003C/p>\u003Cp>You can make it, a different font if you wanted to. If you wanna go crazy with themes, you can make it Comic Sans. Would would highly recommend doing that. Ben's gonna kill me. Then, so those displays are and and you can have a text prefix.\u003C/p>\u003Cp>Right? That's where it gets a little tricky. So the display can show additional data that's not the, like, present in the value. So if we wanted to keep that level of flexibility, like, a rating display being stars. If you have an inline number input, now you kinda kill the usefulness of this rating display.\u003C/p>\u003Cp>Speaker 0: Yeah. The the drawing drawing the line, what is considered simple, is also very hard. Like, for me, for example, like, a many to one relation, for example, I mean, that's basically a drop down. No. A drop down doesn't seem to me to be, like, a complicated change, so to speak, like, a complex update.\u003C/p>\u003Cp>Yeah. But from a user standpoint, not from the implementation detail standpoint, but from a, like, oh, I just want to change the user. That's like one, you know, one click, select the user, select another user, be done. That seems like a simple thing, technically, you know, but it's still a relational change.\u003C/p>\u003Cp>Speaker 1: Yeah.\u003C/p>\u003Cp>Speaker 0: Wait. What did the doer say?\u003C/p>\u003Cp>Speaker 1: I mean, it's you kinda wanna what they're saying is you want the way that you're editing the value to to look the same after you're done editing it. So if you're looking at I think the obvious ones are, the toggle again. You wanna click it and you just edit it in the way it's presented. If you have a rating display, you wanna just click on the number of stars and that's the way you edit the value that you're seeing. When it comes to, like, a related values thing where it shows x number of items, it gets a little finicky.\u003C/p>\u003Cp>Right? If you're talking about the formatted value display where you might have, you know, a dollar sign prefix or something, Now it also gets tricky because now the moment you edit the value, it shows something completely different than you have displayed. Right? I think with dates, there's a different expectation, but if you think about the raw value underneath, it's just a string. It's an ISO 8601 string.\u003C/p>\u003Cp>So if you were to click a nicely formatted in your local language date, and you click it, and now all of a sudden it turns into a technical string, that'd be a bad experience. Right? Even though you could inline edit it as a string, which is not probably not what you want.\u003C/p>\u003Cp>Speaker 0: But what's also funny about like the ISO strings is that, you know, often are like, usually they're stored in like UTC universal time. So, like, people Right.\u003C/p>\u003Cp>Speaker 2: Yeah.\u003C/p>\u003Cp>Speaker 0: In other time zones, might not even know what to actually put in there because, you know, they want to select, alright. This should happen every day at, you know, 8 in the morning or something like some some whatever date. And, then all all of a sudden, the UTC time is completely different. And then you're like, oh, no. This this field's not good.\u003C/p>\u003Cp>What is it? I don't know. And again, yeah, it it really depends on the time zone of the server itself of your database or whatever. And then\u003C/p>\u003Cp>Speaker 1: I mean, at that point, it's it's game over. You really need to have some sort of proper data interface that handles that under the hood and then those presentational side of it. There is this is this is where the discussion is is interesting to me though, because it's like we're basically saying, do we have a small interface or do we have an editable display? And what's the difference? Right?\u003C/p>\u003Cp>Because when it comes to the date the date time specifically, the the basic of the date display is that it basically just takes the raw value and then shows it in whatever is appropriate for your locale. Right? So in the USA, it does the, objectively ridiculous thing. And I moved here by choice, mind you, of month slash day slash year. Right?\u003C/p>\u003Cp>And then elsewhere, it'll just do the proper thing of day, month, year.\u003C/p>\u003Cp>Speaker 0: Right? Shot's fired.\u003C/p>\u003Cp>Speaker 1: But I can imagine that if you have an inline editable date interface, you can just, you know, just like the system native one, basically, you can click on any of those parts and just type in what you want. Right? It doesn't have to be a whole selection, UI, and all that kind of stuff. So sorry for air format.\u003C/p>\u003Cp>Speaker 0: Yeah. The the American people go to great, great, great lengths to not actually use some type of normal measurement. Like, how long is something? Yeah. I don't know.\u003C/p>\u003Cp>2 2 and a half elbows or something. That's something how high how high is this building? I don't know. It's at 20 1,000 feet. I don't know how big is a feet.\u003C/p>\u003Cp>Speaker 1: What? Oh, man. This derails very quickly though. Next session, we'll spend, it's a full hour on the Imperial system.\u003C/p>\u003Cp>Speaker 0: Oh, no. Somebody's actually this relates to the discussion. Yeah. Great. Okay.\u003C/p>\u003Cp>Sure. Sure.\u003C/p>\u003Cp>Speaker 1: Okay. Yeah. Yeah. Yeah. Yeah.\u003C/p>\u003Cp>This yeah. At least take a bit of context.\u003C/p>\u003Cp>Speaker 2: Everything should be millimeters. He's Google. The Australians got it right there.\u003C/p>\u003Cp>Speaker 1: There there's a good point in the chat though. Let's say you're storing a height value in millimeters or centimeters or meters or something, but then you wanna display it with a display, you know, in feet or inches or that kind of stuff. If you then inline edit it, what are you now inline editing? Because if it would be an interface where you're doing the value, you're now editing, I suppose, the millimeters, but you're showing it as foot. You know what I mean?\u003C/p>\u003Cp>Or as as inches.\u003C/p>\u003Cp>Speaker 2: Oh, don't do it. Don't do it. Just do millimeters.\u003C/p>\u003Cp>Speaker 1: Well, yeah, that's not always appropriate.\u003C/p>\u003Cp>Speaker 2: We're we're not that dumb. We we figure it out. Mhmm. We're we're slowly being converted to metric by the by the global corporate infrastructure. We're getting there.\u003C/p>\u003Cp>I actually flip all my stuff. I use Metrc on everything now.\u003C/p>\u003Cp>Speaker 0: Good boy. Good boy.\u003C/p>\u003Cp>Speaker 1: From FCW comes in with the question, you know, what if we click on a cell, which is one of the displays, and then the field whatever that field's interface appears, just like it does in the form, and I could pop over and it will be prefocused or something. That is very close to basically where we started the discussion. So I'm glad that we're coming full circle, in in converging it back down. Because that would be, in terms of implementation, by far the simplest way for us to build this. Right?\u003C/p>\u003Cp>It's like, don't care about any of this stuff. You click it, you open a little pop over and then you change it and it's done. I also like simple things.\u003C/p>\u003Cp>Speaker 2: Drop down, you get your whatever.\u003C/p>\u003Cp>Speaker 1: You get effectively everything. Now there is. One major downside with that, that we've sort of hinted at, but not explicitly called out like this, Which is I believe that there's a lot of data types where you wanna edit it truly inline and not in a popover. So you have a checkbox, if you click it, you wanna have it change. You don't wanna have it open a popover with an inline toggle that you then click to change the other thing.\u003C/p>\u003Cp>I think when you have a small, text input Drop downs.\u003C/p>\u003Cp>Speaker 2: Drop downs, same thing.\u003C/p>\u003Cp>Speaker 1: Change the change the drop downs, same thing. Right? Both data entry gets frustrating in that model and I would agree. Like, I think for a drop down, you just wanna click it. It needs to show the drop down section.\u003C/p>\u003Cp>It'd be a bit of an annoying UX if it then opens a pop over with the same dropdown again that you then click to to have a nested popover down, I guess, which would also be a bit annoying.\u003C/p>\u003Cp>Speaker 2: Very much agreed.\u003C/p>\u003Cp>Speaker 1: I do think that for me, one of the requirements from a UX design perspective is that we have some sort of truly in line flavor for some of those, and then use the pop over for the interfaces where it doesn't make sense. Right?\u003C/p>\u003Cp>Speaker 2: I like it.\u003C/p>\u003Cp>Speaker 1: Picky stuff. But it's it's also hard to it's also difficult to decide which ones make sense and which ones don't. Because I'm thinking about our color display, which is just a tiny dot in its smallest form. If you click that, do we really have to show the full color interface? Because again, it's more like a a select.\u003C/p>\u003Cp>Right? It's more like a drop down. You could just click the tiny preview and then edit the drop down items directly. But how do we how do you control that, right? Which is, I think, what we're getting at is sort of the suggestion from the DIRF earlier, which kinda says, it's up to the interface to communicate somehow whether or not it is, inline editable.\u003C/p>\u003Cp>Yeah. So I think this is a good example, John. Jonathan. Exactly. It's like this whole drop down, we could just render that the moment you click on the little preview in line, right?\u003C/p>\u003Cp>It doesn't have to have this whole interface again because the only real thing that you care about for the interface is the part in the drop down, right? So from the chat, if interfaces have an inline variant those could be used inline and then fall back to popover if the interface doesn't have an inline variant. I think that is basically what I'm suggesting then. Yeah. Because then for the color in line variant, it can just render it, you know, nice and in line.\u003C/p>\u003Cp>For, a one to many interface where we know it's like there's there's no way to do the whole UI in a table row, it would use a pop over and just render whatever needs in there. I don't know though if interfaces should always have an inline variant, and it is then in charge of what goes in the popover because I can also imagine that the UX of how you wanna deal with an interface itself within the constraints of a pop over smaller window can be different. So if you think about the pagination for a one to many, for example, if you have that configured to, paginate at 50 and the individual rows of a once many are pretty big. You know, they're the regular size of an interface or, input height is what we call it. For a consistent view on the form, it looks nice.\u003C/p>\u003Cp>But if you cram that into a small popover, there's gonna be a lot of overflow scrolling now in that tiny little, in that tiny little pop over. We could go full modal. This is from the chat. Let me mind you. We could go full modal and make people suffer, which we could, but I I kinda to me, it's no longer in line editing then.\u003C/p>\u003Cp>Right? You just have a short cord to open a single field. But I could imagine that yeah. John, thanks for pulling this up. Like that left column section you're seeing there.\u003C/p>\u003Cp>I could imagine that the interface itself has an alternative rendering mode where it can just compress it down a hell of a lot more to be a better experience in a sort of pop over context. Popovers on mobile would be particularly a pain in the neck. Another one from the chat. Yeah. Yeah.\u003C/p>\u003Cp>Absolutely true. Which, in that case, you know, there is the opportunity to say for mobile, if we're rendering a popover, we're just rendering it as a dialogue or it might take over the full screen. There there's ways to responsibly handle that responsibly, responsibly.\u003C/p>\u003Cp>Speaker 0: Okay. So just looking at the time, real quick since we are approaching the hour mark. I think yeah. But I I think we landed on a quite the nice, let's say, idea on how to tackle this because, you know, nothing is, you know, struck in stone, but I I do think I do think I like the approach of, you know, you can have interfaces, you can have displays, and you can have inline interfaces, which sounds very reasonable to me. But then, like you said, alright.\u003C/p>\u003Cp>Where do we control what pops in, what doesn't pop in?\u003C/p>\u003Cp>Speaker 1: And I think it will have to be the interface, honestly. Because I could, an input interface, it knows that it could be handled in line. There's no way real way for us to to see that from the outside in. Right? I mean, we could always have, like, a lookup table somewhere, but it would only work for the stuff we the stuff we ship in core, not for extensions, which is a big part of this, of course.\u003C/p>\u003Cp>I I I think that the the question that I'm struggling with now is really what is the difference displays and interfaces in this paradigm. Right? Because now we're rendering interfaces in the place of a display, sometimes. And I'm I'm now just starting to think with this whole in line editing idea, maybe a display is just a read only inline version of the interface. It it does remove that flexibility that we talked about earlier where you could have a different display value for a input value.\u003C/p>\u003Cp>But to me, it would sort of solve for some of the complexity in configuration and some of these questions that when is it when is it a display? When is it an inline interface? How do you control between the 2? How do you toggle? Etcetera etcetera.\u003C/p>\u003Cp>Because that way we could say, well, in every interface needs an inline and a block version. The block version is what we use on forms and bigger pages. The inline version is what we use in title cards and table rows and that kinda stuff. And then it is read only or it's not. Like we currently already have.\u003C/p>\u003Cp>You know, we have read only forms, for permissions and all that kind of stuff. And a display is effectively just a read only inline version of the interface. And then if you have the editable table layout which is just a toggle. Maybe it's always on tbd. The inline version of the interface now controls if it's a pop over or not.\u003C/p>\u003Cp>So the inline version of a die, of a checkbox. Just click it. It immediately interactive. In line version of a text input. Click it.\u003C/p>\u003Cp>You can type in line version of a relational, one to many or something. By default, it'll just show 6 items. But then when you click it, the popover has the actual editable part. Right? But I think it could be the same the same interface.\u003C/p>\u003Cp>It's all interfaces at that point.\u003C/p>\u003Cp>Speaker 0: Interface is all the way down.\u003C/p>\u003Cp>Speaker 1: I mean, it would reduce it. So so one of the other parts is, like, there is a bit of confusion around the difference between interface and display. And I feel like a lot of people configure an interface by setting up a new field and then don't know that displays even exist. Cause if you configure a new field, it's very easy to skip over it and never know it's there. Right?\u003C/p>\u003Cp>So I also think there is a case to be made that it would improve the experience for a lot of the people that normally don't, really take the time to go over every single option that exists because it can be a bit overwhelming, you know, arguably. There's a lot of stuff you can configure.\u003C/p>\u003Cp>Speaker 0: That sounds good to me.\u003C/p>\u003Cp>Speaker 1: It'd be a gigantic rate and change, so don't worry about that.\u003C/p>\u003Cp>Speaker 0: This is not something we can just\u003C/p>\u003Cp>Speaker 1: in a little 10.1. Here you go. Bang.\u003C/p>\u003Cp>Speaker 0: Looks good to me. Ship it.\u003C/p>\u003Cp>Speaker 1: But I I think to me, that would sort of solve it because then for the table layout, you can have a toggle somewhere that says make it editable. Yes or no. For and for any of the layouts, really. For the tabular layout, we can make it editable by default. For the cards layout, we could say it's probably not a good idea to do it for some but for others because now the layout's in control.\u003C/p>\u003Cp>I think there's there's something to it.\u003C/p>\u003Cp>Speaker 2: Very cool stuff.\u003C/p>\u003Cp>Speaker 0: Good stuff, guys. Any last questions from the, audience? Your chance is now.\u003C/p>\u003Cp>Speaker 1: Forever hold your peace. Winston.\u003C/p>\u003Cp>Speaker 2: Final cue.\u003C/p>\u003Cp>Speaker 0: Forever hold your peace.\u003C/p>\u003Cp>Speaker 2: If you're if you're still awake.\u003C/p>\u003Cp>Speaker 1: Yeah.\u003C/p>\u003Cp>Speaker 2: Oh, let's see. Vincent.\u003C/p>\u003Cp>Speaker 0: Someone type it. Well, then, thank you everybody.\u003C/p>\u003Cp>Speaker 1: Thank you. Bored everybody to death.\u003C/p>\u003Cp>Speaker 2: We've hard hard boiled a few eggs.\u003C/p>\u003Cp>Speaker 0: Lovely. Thanks for tuning in. In case you enjoyed this, there's much more of this on directors.io/tv. If you want to go there, there's lots and lots of interesting shows for you. Lots of good, great entertainment.\u003C/p>\u003Cp>And, feel free to join us next time for another very interesting topic. Thank you for linking the show, Kevin. Oh, yeah. Fire emojis. Yes.\u003C/p>\u003Cp>Very good. Thank you everyone for tuning in. We hope you have a\u003C/p>\u003Cp>Speaker 2: great day. Enjoy your week, folks. Have a good night. Good\u003C/p>\u003Cp>Speaker 0: night. Strong feelings, please let us know. The discussion is open. The issues are open.\u003C/p>\u003Cp>Speaker 1: That way.\u003C/p>","Hello, everybody. Welcome to feature request review with me as a host today, joined by the good old Reich, Van Zanten himself and Jonathan Wagner. Hello. Hello, everybody. Thank you for coming. Very exciting to see you all. Quite quite the quite the collection of people we have here from Algeria, Japan, everywhere. Germany, Austria. No. No. No. I nearly said it. But, yeah, today today, everybody's, apparently favorite topic because there's so much demand here in the channel right now. Inline editing, which can mean a lot of things. So let's just take a look at what a small example could look like. If you take a look at the screen shared footage of Jonathan, you'll see this is our feature request that got in, which you can vote on, by the way, in case, some people are not aware of this feature in our discussions in the director's repository. You may vote on stuff that gets implemented into the software, which is pretty cool. And, today's topic is about inline editing. If we scroll up a little bit to the top to the screenshot, you might have seen this in other interfaces online, you know, when you use Notion or whatever, like, many many sites implement this a little bit differently. You know, on Trello boards, you can click into the title, then you can change the title right then and there without a pop up or something. And, yeah, why why doesn't have direct as this yet? It's a good question. I mean, there are many, many different things that we could talk about. And, in case you have any questions or stuff that you want to share, please feel free to use the chat. We're excited to engage with you guys. It would be fun, a sign of life like previously. That would be nice. And how about how about we jump in right into a couple of questions? Let me quickly, give one second. Alright. So by looking at this, you know, basic example with the with the input field, I mean, the the first question to me is, alright. Like, how how much can we blow this up to, because Directus is very, very versatile, and, people build the craziest displays and interfaces and very, very customizable different pieces. How do they fit into this, and if we just target, like, simple inputs, for example, like in these simple example with, like toggles or text inputs. What about relations? Because those tend to be very nice to deal with. And, how about we go over to give over to Rijk for this one? How do you feel about different types of inputs for inline editing? Do you think we should, like, aim to be able to do everything in in in line editing? Should we reduce it down? Should we only support a sub set? How do you feel about inline editing in itself? I mean, when it comes to inline editing, I think the first question that we gotta ask ourselves and everybody watching is like, what does that even mean in the first place? Is it kinda like a spreadsheet where everything is just a cell where you can change whatever you see? Is it more like, a table view by default where everything looks pretty through those displays, And then you have some sort of edit state. Is it like, an edit state where we render a whole interface in line? Or is there some sort of dialogue overlay that we're seeing when you click on one of the cells, so to speak, to to stay in spreadsheet terms. So I think the first question really is what is what is inline editing? What does it even mean? Right? Because we do have a different feature request for a spreadsheet view, which I think very closely overlaps, but there's definitely differences. And then I think the other question, of course, I mean, relationships, we'll dive into that in 5 minutes. But, if you think about the basics, I think one of the thing that we're doing with direct is with all the interfaces is to make sure that you can edit the data in a way that makes sense for what the data is. Right? So, a very basic example, you know, a slider could be a better representation for a numeric value that you're using for whatever it is that you're building. Right? But You wanna use a slider to control the value. When it comes to inline editing, you know, if we're looking at this screenshot where the reserve column right now presumably is in this edit state, you know, if we're dealing with inline editing in its sort of truest form, does that mean that it just turns into a sort of raw value input? Or do we include interfaces kinda like we are with a regular form? Right. So when it comes to a date value to name something, the technical value is always gonna be that that what's the exact spec, the, ISO 8601. Is that the thing that you wanna be editing? I would argue, probably not. You probably wanna have, you know, the data interface that you have configured for that field, which then leads to the question, does that even fit wherever we're doing this inline editing presumably in this table layout. Right? And I think we're we're quickly reaching the question then is like, okay, do interfaces even fit? And if they don't, how do we present it otherwise? Right? Yeah. To your example, like, even even a simple slider, which is a nice way to input, like, a specific value inside of a range, which could be, you know, like, relevant to the use case, you know, where you want to restrict. You maybe you don't allow, like, negative numbers or something. But if if we allow, like, editing via raw values, then somebody might put in, you know, minus 1 or something, and then you very quickly run into the issue that you mentioned. We want to give people the tools to, like, input stuff as as as comfortably as possible with using, like, nice interfaces and displaying like, even displaying, you know, with with the value that you see inside of the table might, like, might not actually be the wrong value just like you described with the, like, date time, for example. So there's a disconnect there and, like, for, like, nontechnical users, for example. No. It could be it could feel bad, you know, from a user experience standpoint where they like if if marketing salespeople, what what was the thing that's, somebody said I won't name any names, but somebody said, like, the scariest thing that marketing people see is, like, a UUID somewhere. So we're dealing with UUIDs. Yeah. It is, is a scary endeavor, so you have to be quite careful with the display. So yeah. Yeah. Speaking to that, we have why don't we explain a little bit about the difference between our interfaces and displays? Because, you know, indirect is also 2 different things. What are those? How do I use those? What can they do? Good question. So so from I'll I'll prefixes was sort of the theoretical idea behind it while Jonathan here pulls up the actual difference and how you configure them. So the basic idea is that a display, controls how a raw value is displayed in line, importantly. So it's really meant to be part of a sentence or one of the cells in a table or, you know, part of a description or something. So if you think about a, labels display, it can be configured to render it as a small color dot with a tooltip, with the idea being you can then render that in the title of a page, or in the description of a card or inside of a table. Right? The interface is really the the way you edit the value. So if you go and you open an item, it's basically the form field, section of of how you interact with that data. So it's really the difference between sort of block level, in CSS terms, editing of the data versus inline displaying of that same data. Importantly, those 2 can be very different representations of the same data. Right? So the image display will just be a tiny thumbnail where an image interface is like a bigger box where you can drag and drop stuff in and you have, like, preview and some more metadata available. They are at present a different thing. And the display is then Yeah. So so Jonathan right now is, you know, adding, a related values you know, those displays, and compose them all together to really control how an individual item is presented. Right? So on the collection detail page 2, there is a display template setting where, again, you can render individual fields as part of one title string. And then that's how it displays the individual pieces of data. So when it comes to editing them in line, one of the interesting, challenges that we're gonna be facing when it comes to the table layout specifically is that the value that you're seeing in here, it's very likely that that's not the value that you're gonna be editing. Right? And is it a toggle? Is it something that you enable or disable? If you haven't enabled, what happens? If you don't have an enabled or how do I access the record? Because currently, you know, I just know that I can just click anywhere on the row, and it will open the item for me, and I can edit the item. How do we trigger, you know, you start to get into that. So we've got the whole interfacing aspect, relational content, allowed or not allowed. It feels like at least maybe you could almost do it in, like, an iterative. So start with the normal input fields, date fields, the the simpler interfaces and things to deal with versus relational. Relational gets complicated, right, depending on how deep or how complex that relational is. Now in order to edit this translation, well, that requires now that I get the full translational split toggle side by side translations kinds of things, and is that beneficial in this kind of a in this kind of utility? Yeah. Toggles, drop downs, you know, some of this, some of the more string text slash Is this is there there is a a another additional question when it comes to how do we then render an interface to change the data, which is that there's gonna be a couple of them where the interaction would be way nicer if it's, like, truly in line. Like, so if we, if you think about a toggle, like a checkbox. Right? Kinda like the default checkboxes for selecting items. But let's say you have, you know, an on or off state on your own custom item. In your display, ideally, I just wanna click it and it flips. I I don't wanna click it then open a dialogue that shows me just one toggle anyways, and then close it, and then change it that way. You know what I mean? And I think the same goes for basic text values or basic numbers where I just wanna be able to click the text, edit it, and then that's it. Right? I don't wanna have to deal with clicking it, seeing a popover, drop down dialog, whatever it may be, then change it there because it's just another step away for something that feels like it could have been a spreadsheet, basically. Yep. With that example, you know, with just clicking in and changing something, Tim also brought up a nice point because, with nullable values, like, even such a simple thing as a, like, togglable checkbox, if that is even a word, you know, we already run into, like, a small little, thing, like, okay, what if you want to set it to null? You know? Like, if you uncheck the thing, it's false, but you want it to be null. Do we do we, you know, do we, like, enable triple, like, stateful checkboxes that support 3 values? Do we want to have, like, a ellipse that gives you, like, a setting for that? Like, similar to our v form where, you know, you're allowed to enter a raw value, but that's another piece of UI that would have to be somewhere some at some point. Yeah. Exactly. For strings, similar in that vein, you know, for strings, do you want a, empty string, or do you want a null value? Alright? How do you differentiate between those? And it can even differ, you know, from from to Yeah. All of those are problems that we have solved in the form context. Right? Because even in the form, there's just the field label drop down that says empty this value, which is effectively nullifying it. So the question is also how much of that do we wanna pull a level up in here versus how much of that do we just say oh well if you explicitly wanna change a boolean back to a null, you can always go to the page detail thing and then do it there. Right? There is an escape hatch, and we could make the call to say, well, you know, the toggle display goes between true and false. And if you need to reset it back to that null state for whatever specific reason, you can always go to the detail page, and do it there. Right? And I think similarly for the string empty update, empty string, null, that that question is a question that we've currently solved on the interface settings, I believe. Therefore, an input interface, you can say empty string becomes null, and then that's just the value it, you know, stages, it emits. So if we go the route where we use the exact same interface you have already configured as the way to edit it in line, that problem should sort of automatically be solved. Right? Because we're using the same interface with the same settings, and then that should be fine as is. Where that part gets super interesting though, is how do we deal with conditional fields within the context of that row? So the way conditional fields currently work is, you know, you have the whole form of on the field, you have the whole form on the page, and then we can use the values of the form and sort of connect the dots. Right? And use it that way. On a row in a table though, the fields that are displayed might be completely different. The second piece to that is gonna be for conditional fields. They're now react reactive in real time where if you make a change to one field, sort of real life like, real time updates it elsewhere. When you're in the context of an individual row, and I think this is just a bigger question overall, is, like, does it auto save every time you sort of blur the input that you change something in? Or is there gonna be a save button that is like, okay. Now you've made all the changes and you hit save once. That's a very good question. Like, especially for, like, the togglable checkboxes or whatever because, like, if you just miss click somewhere and all of a sudden, that could be a big change, you know, like with flows and automations and other stuff that runs or update events, fire something. If you hit publish on something, that should be, there should be a mechanism, you know, to stop making mistakes, you know, like, accidentally, if you have, like, you know, is active or is published field on some type of blog post or whatever, and you don't want to accidentally just oops. Oops. It's live now. Oopsie. Would would be nice if we could avoid that, but, yeah, that opens up another can of worms. You know? Like, how do we do you configure this on a field level? Do you configure this on a column level, on a, preset level? Like, where where do you where would you like to do that? That's also the thing. Because very good point from the chat also from the, is currently, for example, the displays do not know, like, which item they belong to. They are very stupid in that way with quotation marks where they just Yeah. Display a value. This is why they're called displays. It's it's a presentation, presentation layer. Yeah. Yeah. Yeah. So if if we would like to have the, you know, like, mutable, displays or whatever, you know, if we decide to go that down that road. So, we would have to provide the displays with the item ID in the collection, like, in every place because there's not not only displays only in the table view, in the tabular layout, but also in, like, titles and drop downs or whatever. Like, any and they could be at any place at any time, which makes this a little bit, dangerously spaghettty like, which which which also, kind of bleeds into a similar yet different question, which is where do we allow inline editing in the first place? Because we're assuming we're sort of assuming the table layout right now because that's the most commonly seen elsewhere. I mean, I'm I'm sure that people that have ever seen Airtable are like, that's that's the way. But at the same time, the the question is, do we inline edit elsewhere? Like, if you have a status icon in your page title, does that become an inline editable thing? Right? In the chat somebody says we'd appreciate it for the card layout, maybe even the calendar. I would agree. So on the card layout, if you have in your description of an individual card, you have a a text display. If you click the description, can you now edit the description of a card in line, which opens up a big can of worms, especially from a UX design perspective. I I guess because because we're we're concatenating that into a string in the display right now for a card. Right? Mhmm. Mhmm. So if we're just The same for page titles for the for for that matter or the calendar layout. Yeah. Yeah. And Tim, Tim, another fun, fun little thing that could happen if you're already editing something and you have auto refresh enabled. Somebody updated your stuff in between the edits, and now you have another edge case. Love it. Love it. Love it. Love it. Which is gonna be the same issue that you have with, you know, the regular form. So I'm hopeful that whatever solution we come up with that right now. Yeah. Exactly. Whatever solution we come up with for that, I'm sure the same solution should also then work here. But Yeah. For this So this is a good example in the cars layout. Right? So in that right side bar, you see title, subtitle, and you can configure any combination of the different fields with any sort of additional strings in between, for like adding a dollar sign in front of price. That kind of stuff. Right? So in this particular case, it becomes extra interesting. Because if you now were to click on the number of the price in that description line, do you expect it to be editable? Right? And how do you determine that? Yes or no? Because making every editable globally at all times feels like a UX nightmare waiting to happen, but it also unlocks a lot of flexibility. Right? So it's a tricky one as many things are. Of course. So how about how about then we take a different look? So now we thought about tables and the current layout and whatever. Technically, there's also another option of adding a new layout, like you mentioned earlier, with the spreadsheet layout, which could be the point where you do that type of stuff. I don't know. Maybe, you know, I'm just, you know, throwing stuff in the room right now just to discuss a little bit. But Yeah. Because it does have the mute display thing. Yeah. Yeah. Yeah. So maybe if it turns out to be better or easier or whatever, the spreadsheet layout could be an interesting point where we could tackle this, but, then we have new, cans of worms and cans and of worms stacked upon each other, you know, till this evening. Stack a can. Which which is fun. Yeah. Because, you know, a spreadsheet layout people come into a spreadsheet layout with lots of preconceived notions. Is that the is that the word? And Like, I think expectations is the word I would say. Yeah. Expectations. Yeah. Yeah. Yeah. Yeah. Expectations and and stuff that they would like to have or that they expect to be there because it's, you know, spreadsheets are, daily used by billions of people. So they do want to have, like, conventions and keyboard navigation and different stuff that they already, you know, introduced to the day to day life with bulk renaming, whatever formulas. Maybe they think that this is then an actual spreadsheet that they can do calculations in, which is another cool feature that we would like to have probably from different feature requests for a different day. Yeah. Exactly. Exactly. Exactly. So spreadsheet seems to be a very big thing, for me personally. Yeah. I think to me it's just a very different thing, isn't it, than than this inline editing approach that we're talking about? Because I fully agree with what you're saying. If you close your eyes and you think spreadsheet, there's a whole set of rules that come with that. That if you miss one of them, you have a bad spreadsheet. Right? Because if you look at Excel versus Google Sheets versus Excel on the web or even Apple's, what they call it, numbers, they are all effectively identical in the exact same settings, exact same thing you can do. It's a right or wrong approach. So, funnily enough, for a session like this, it would be a very short call because it's like spreadsheet. It's basically a known entity at that point. Right? I think where it gets interesting to me, and this is sort of the the the Airtable spreadsheet equivalent. It's like, you're not dealing with the spreadsheets. You're dealing with a table that you can edit in line. But it's not a pure spreadsheet in the technical term, right, where you're dealing with cells with raw values, so to speak, rather than UI elements where you edit the values. Yeah. Same thing in the chat was was coined there. The reason why I immediately started thinking about okay. So our display is now editable as a concept is basically from that modular fashion. Right? Because making one new layout that does inline editing sure. We could totally make that happen. We could also make it an option of the regular table layout and then that's it. Right? To me the interesting question for this is really like, is there a way to make it work for any display anywhere? And is that something that we wanna do or not? Because by doing so, you get the tabular layout feature out of the box but you also unlock it elsewhere. Like, if you have, a list of one to many items on, a record, each of those one to many items now also has inline editing because they are using displays to render those values. Right? So it it just, like, it transforms this discussion from an inline table editor to a bigger sort of, like, what does that editing in situ look like across the board? Very, very good question. I wish I would have the answer to it, but, yeah, like you said, I mean, for for for example, for the, like, relational stuff, I could see, you know, reusing the existing drawer that pops up in different places, which could be a nice experience. You know, if you let's say you have a, a website collection with blog posts or something, articles, whatever. And as the drawer opens and you can use the currently already existing, like, relations go through the list, it it's it's with pagination and stuff. That could be nice. But like you said earlier, if for smaller fields, it feels like add UX if you, you know, just want to change one text and then the drawer opens or, like, a pop up opens with just one input. That's, like, at that point, it just feels very not thought through, which I would like to avoid. Yeah. We got correlate with this PR. Yeah. Yeah. Yeah. The the batch editing is also a nice thing. So slightly different. There's also the the, the bigger question here, Which is As it always is? As it always is. But it's that's that's what these sessions are. For those who are new, in these sessions, we always go find all of the edges and then take it back into what is actually realistic in the next step. But so think about it. If if we're now dealing so so you we explained it before that the displays were meant as a presentational only unit and interfaces are meant as an editable unit of the same value. Right? But now we're saying: What if displays are editable, but only at sometimes? So some displays like a string we wanna make inline editable, Some displays like a checkbox inline editable. And some like a relational related values or something we wanna have a click with some sort of dialogue to to have the space to make it a proper editing experience. Right? The question could also be, should those still be 2 separate entities or should they all be interfaces? And based on how we where we're rendering an interface, it can display in different ways. Right? So if you have an interface on a form where it has enough space to grow, it can show as a proper big input. But if you try to squash it into a cell of a table, it just drops the visual representation of an input and becomes one of those underline only in inputs for example. Right? Because then with a read only prop, yes or no, you can toggle between a string that's just rendered as a string. Or when you click it, it switches into this inline interface version, basically. Know what I mean? Because then for a display one, it can always just be interactive for an input, you can just click to start typing for, a related values one or a relation when you can click it and it would just do it in a pop over or dialogue or something along those lines. So depending on the interface type or the interface implementation, you could allow or disallow inline editing ongoing. Right? Right. It it would basically mean that the interface is always the thing that controls how it's displayed, because therefore you can have the interface control how that interactivity works in that display context. Now, that does, of course, come with the the side effect that you can no longer have a different display per interface like we currently allow. So theoretically, you could use, you know, a text input interface, and then an icon display if you wanted to. Or, you know, you can have a rating input that is a slider and then a display that's that's rendered as stars. I don't have the stats on how popular that is. Like, that would be a breaking change where we remove that. At the same time it also makes it easier to configure. Right? Because you can have, okay, I'm using the icon this, icon interface, and at smaller scales, it turns into an icon display. Right? So I guess another option could be that if you toggle the, you know, inline capability here, then the display gets turned off. Right? You don't have display capability. So you don't have a breaking change, you have the ability to come in and edit an existing interface, keep the existing display capabilities where I don't know what the overhead looks like for that, but something that we could think about instead of just outright ripping this out because I I still think, again, this is gonna be, I think, the most common case where I would want the ability to do, like, inline editing is on strings and numbers and dates. Right? Those are the, you know, the The the simple somebody in the the chat called it the simple stuff. Yeah. If I'm dealing with relational, you know, now you're dealing with complex, you know, you're you're just as easily popping into the item at that point to edit a relational setup potentially. Now down the line, that could change, but I think the most common things, you know, based on the ticket that we got inbound was around I just wanna be able to update some numbers, and I'll be able to quickly go through and adjust some numbers. I wanna adjust some text, and it's not a bulk edit because I'm not making them all the same, but I wanna be able to quickly edit things in line. Relational's I don't know. My brain my brain, I can see the nicety of it to be able to quickly just pop an interface and make a change without having to open the entire work, you know, in and out of a record to do that, but I think short term initial implementation. But if we added a toggle here or a function that says, you know, disable the display, if you go to inline, then you get the interface, and that is the display. Woah. Say say that again. So That last part, if you have a display but you use an interface and you toggle it, you now have a display. You lost me in that last part. No. No. So I'm saying that if we add a new if we add the feature for inline on the interface so if specific interface designed to support inline, and you just say, I wanna use the inline or I don't know where we would set that. I think it's set up based on the type. Yeah. Yeah. Yeah. Yeah. Yeah. I think somebody in the chat mentioned that it's too. It might have been the derp. Yeah. It gives you the, you know, if I make c one in here, it overrides display. Right? Display is essentially either disabled, right, becomes grayed out here, or it's just ignored, and with a note here that says if I check-in line, then boom display is no longer utilized. We're gonna utilize the interface spec for that. So so, you know, in the chat, mentioned a similar idea in that we could also have and this is a direct quote. We could also have multiple optional components for a single interface, like an inline version and a block version of the same interface. And then when the inline interface version exists, that can be used instead of the display, and then gray out the display to you your point. Yeah. Because the, this gets ignored. As long as there's a note or a warning, you know, even if someone does set it here, it's just ignored. If in line is enabled here, then it just gets ignored. Because the reason to then ignore the displays is because you kinda want the display itself to be editable at all times at that point. Like a checkbox, interface in the an inline checkbox interface would just be a toggle that's always active for you to click on. Because the comment that was just made in the chat too is like, you say you're loading a nested relational simple column in a table. You need simple editing. But in terms of toggling, you know, you can use the display by default. And then when you turn on an edit mode, maybe all of those in line ones are displayed so you still have displays. It gets tricky. So so the reason I'm saying that is we have things like the, formatted value display which is basically, a very configurable string. Right? You can make it bold, italic. You can make it, a different font if you wanted to. If you wanna go crazy with themes, you can make it Comic Sans. Would would highly recommend doing that. Ben's gonna kill me. Then, so those displays are and and you can have a text prefix. Right? That's where it gets a little tricky. So the display can show additional data that's not the, like, present in the value. So if we wanted to keep that level of flexibility, like, a rating display being stars. If you have an inline number input, now you kinda kill the usefulness of this rating display. Yeah. The the drawing drawing the line, what is considered simple, is also very hard. Like, for me, for example, like, a many to one relation, for example, I mean, that's basically a drop down. No. A drop down doesn't seem to me to be, like, a complicated change, so to speak, like, a complex update. Yeah. But from a user standpoint, not from the implementation detail standpoint, but from a, like, oh, I just want to change the user. That's like one, you know, one click, select the user, select another user, be done. That seems like a simple thing, technically, you know, but it's still a relational change. Yeah. Wait. What did the doer say? I mean, it's you kinda wanna what they're saying is you want the way that you're editing the value to to look the same after you're done editing it. So if you're looking at I think the obvious ones are, the toggle again. You wanna click it and you just edit it in the way it's presented. If you have a rating display, you wanna just click on the number of stars and that's the way you edit the value that you're seeing. When it comes to, like, a related values thing where it shows x number of items, it gets a little finicky. Right? If you're talking about the formatted value display where you might have, you know, a dollar sign prefix or something, Now it also gets tricky because now the moment you edit the value, it shows something completely different than you have displayed. Right? I think with dates, there's a different expectation, but if you think about the raw value underneath, it's just a string. It's an ISO 8601 string. So if you were to click a nicely formatted in your local language date, and you click it, and now all of a sudden it turns into a technical string, that'd be a bad experience. Right? Even though you could inline edit it as a string, which is not probably not what you want. But what's also funny about like the ISO strings is that, you know, often are like, usually they're stored in like UTC universal time. So, like, people Right. Yeah. In other time zones, might not even know what to actually put in there because, you know, they want to select, alright. This should happen every day at, you know, 8 in the morning or something like some some whatever date. And, then all all of a sudden, the UTC time is completely different. And then you're like, oh, no. This this field's not good. What is it? I don't know. And again, yeah, it it really depends on the time zone of the server itself of your database or whatever. And then I mean, at that point, it's it's game over. You really need to have some sort of proper data interface that handles that under the hood and then those presentational side of it. There is this is this is where the discussion is is interesting to me though, because it's like we're basically saying, do we have a small interface or do we have an editable display? And what's the difference? Right? Because when it comes to the date the date time specifically, the the basic of the date display is that it basically just takes the raw value and then shows it in whatever is appropriate for your locale. Right? So in the USA, it does the, objectively ridiculous thing. And I moved here by choice, mind you, of month slash day slash year. Right? And then elsewhere, it'll just do the proper thing of day, month, year. Right? Shot's fired. But I can imagine that if you have an inline editable date interface, you can just, you know, just like the system native one, basically, you can click on any of those parts and just type in what you want. Right? It doesn't have to be a whole selection, UI, and all that kind of stuff. So sorry for air format. Yeah. The the American people go to great, great, great lengths to not actually use some type of normal measurement. Like, how long is something? Yeah. I don't know. 2 2 and a half elbows or something. That's something how high how high is this building? I don't know. It's at 20 1,000 feet. I don't know how big is a feet. What? Oh, man. This derails very quickly though. Next session, we'll spend, it's a full hour on the Imperial system. Oh, no. Somebody's actually this relates to the discussion. Yeah. Great. Okay. Sure. Sure. Okay. Yeah. Yeah. Yeah. Yeah. This yeah. At least take a bit of context. Everything should be millimeters. He's Google. The Australians got it right there. There there's a good point in the chat though. Let's say you're storing a height value in millimeters or centimeters or meters or something, but then you wanna display it with a display, you know, in feet or inches or that kind of stuff. If you then inline edit it, what are you now inline editing? Because if it would be an interface where you're doing the value, you're now editing, I suppose, the millimeters, but you're showing it as foot. You know what I mean? Or as as inches. Oh, don't do it. Don't do it. Just do millimeters. Well, yeah, that's not always appropriate. We're we're not that dumb. We we figure it out. Mhmm. We're we're slowly being converted to metric by the by the global corporate infrastructure. We're getting there. I actually flip all my stuff. I use Metrc on everything now. Good boy. Good boy. From FCW comes in with the question, you know, what if we click on a cell, which is one of the displays, and then the field whatever that field's interface appears, just like it does in the form, and I could pop over and it will be prefocused or something. That is very close to basically where we started the discussion. So I'm glad that we're coming full circle, in in converging it back down. Because that would be, in terms of implementation, by far the simplest way for us to build this. Right? It's like, don't care about any of this stuff. You click it, you open a little pop over and then you change it and it's done. I also like simple things. Drop down, you get your whatever. You get effectively everything. Now there is. One major downside with that, that we've sort of hinted at, but not explicitly called out like this, Which is I believe that there's a lot of data types where you wanna edit it truly inline and not in a popover. So you have a checkbox, if you click it, you wanna have it change. You don't wanna have it open a popover with an inline toggle that you then click to change the other thing. I think when you have a small, text input Drop downs. Drop downs, same thing. Change the change the drop downs, same thing. Right? Both data entry gets frustrating in that model and I would agree. Like, I think for a drop down, you just wanna click it. It needs to show the drop down section. It'd be a bit of an annoying UX if it then opens a pop over with the same dropdown again that you then click to to have a nested popover down, I guess, which would also be a bit annoying. Very much agreed. I do think that for me, one of the requirements from a UX design perspective is that we have some sort of truly in line flavor for some of those, and then use the pop over for the interfaces where it doesn't make sense. Right? I like it. Picky stuff. But it's it's also hard to it's also difficult to decide which ones make sense and which ones don't. Because I'm thinking about our color display, which is just a tiny dot in its smallest form. If you click that, do we really have to show the full color interface? Because again, it's more like a a select. Right? It's more like a drop down. You could just click the tiny preview and then edit the drop down items directly. But how do we how do you control that, right? Which is, I think, what we're getting at is sort of the suggestion from the DIRF earlier, which kinda says, it's up to the interface to communicate somehow whether or not it is, inline editable. Yeah. So I think this is a good example, John. Jonathan. Exactly. It's like this whole drop down, we could just render that the moment you click on the little preview in line, right? It doesn't have to have this whole interface again because the only real thing that you care about for the interface is the part in the drop down, right? So from the chat, if interfaces have an inline variant those could be used inline and then fall back to popover if the interface doesn't have an inline variant. I think that is basically what I'm suggesting then. Yeah. Because then for the color in line variant, it can just render it, you know, nice and in line. For, a one to many interface where we know it's like there's there's no way to do the whole UI in a table row, it would use a pop over and just render whatever needs in there. I don't know though if interfaces should always have an inline variant, and it is then in charge of what goes in the popover because I can also imagine that the UX of how you wanna deal with an interface itself within the constraints of a pop over smaller window can be different. So if you think about the pagination for a one to many, for example, if you have that configured to, paginate at 50 and the individual rows of a once many are pretty big. You know, they're the regular size of an interface or, input height is what we call it. For a consistent view on the form, it looks nice. But if you cram that into a small popover, there's gonna be a lot of overflow scrolling now in that tiny little, in that tiny little pop over. We could go full modal. This is from the chat. Let me mind you. We could go full modal and make people suffer, which we could, but I I kinda to me, it's no longer in line editing then. Right? You just have a short cord to open a single field. But I could imagine that yeah. John, thanks for pulling this up. Like that left column section you're seeing there. I could imagine that the interface itself has an alternative rendering mode where it can just compress it down a hell of a lot more to be a better experience in a sort of pop over context. Popovers on mobile would be particularly a pain in the neck. Another one from the chat. Yeah. Yeah. Absolutely true. Which, in that case, you know, there is the opportunity to say for mobile, if we're rendering a popover, we're just rendering it as a dialogue or it might take over the full screen. There there's ways to responsibly handle that responsibly, responsibly. Okay. So just looking at the time, real quick since we are approaching the hour mark. I think yeah. But I I think we landed on a quite the nice, let's say, idea on how to tackle this because, you know, nothing is, you know, struck in stone, but I I do think I do think I like the approach of, you know, you can have interfaces, you can have displays, and you can have inline interfaces, which sounds very reasonable to me. But then, like you said, alright. Where do we control what pops in, what doesn't pop in? And I think it will have to be the interface, honestly. Because I could, an input interface, it knows that it could be handled in line. There's no way real way for us to to see that from the outside in. Right? I mean, we could always have, like, a lookup table somewhere, but it would only work for the stuff we the stuff we ship in core, not for extensions, which is a big part of this, of course. I I I think that the the question that I'm struggling with now is really what is the difference displays and interfaces in this paradigm. Right? Because now we're rendering interfaces in the place of a display, sometimes. And I'm I'm now just starting to think with this whole in line editing idea, maybe a display is just a read only inline version of the interface. It it does remove that flexibility that we talked about earlier where you could have a different display value for a input value. But to me, it would sort of solve for some of the complexity in configuration and some of these questions that when is it when is it a display? When is it an inline interface? How do you control between the 2? How do you toggle? Etcetera etcetera. Because that way we could say, well, in every interface needs an inline and a block version. The block version is what we use on forms and bigger pages. The inline version is what we use in title cards and table rows and that kinda stuff. And then it is read only or it's not. Like we currently already have. You know, we have read only forms, for permissions and all that kind of stuff. And a display is effectively just a read only inline version of the interface. And then if you have the editable table layout which is just a toggle. Maybe it's always on tbd. The inline version of the interface now controls if it's a pop over or not. So the inline version of a die, of a checkbox. Just click it. It immediately interactive. In line version of a text input. Click it. You can type in line version of a relational, one to many or something. By default, it'll just show 6 items. But then when you click it, the popover has the actual editable part. Right? But I think it could be the same the same interface. It's all interfaces at that point. Interface is all the way down. I mean, it would reduce it. So so one of the other parts is, like, there is a bit of confusion around the difference between interface and display. And I feel like a lot of people configure an interface by setting up a new field and then don't know that displays even exist. Cause if you configure a new field, it's very easy to skip over it and never know it's there. Right? So I also think there is a case to be made that it would improve the experience for a lot of the people that normally don't, really take the time to go over every single option that exists because it can be a bit overwhelming, you know, arguably. There's a lot of stuff you can configure. That sounds good to me. It'd be a gigantic rate and change, so don't worry about that. This is not something we can just in a little 10.1. Here you go. Bang. Looks good to me. Ship it. But I I think to me, that would sort of solve it because then for the table layout, you can have a toggle somewhere that says make it editable. Yes or no. For and for any of the layouts, really. For the tabular layout, we can make it editable by default. For the cards layout, we could say it's probably not a good idea to do it for some but for others because now the layout's in control. I think there's there's something to it. Very cool stuff. Good stuff, guys. Any last questions from the, audience? Your chance is now. Forever hold your peace. Winston. Final cue. Forever hold your peace. If you're if you're still awake. Yeah. Oh, let's see. Vincent. Someone type it. Well, then, thank you everybody. Thank you. Bored everybody to death. We've hard hard boiled a few eggs. Lovely. Thanks for tuning in. In case you enjoyed this, there's much more of this on directors.io/tv. If you want to go there, there's lots and lots of interesting shows for you. Lots of good, great entertainment. And, feel free to join us next time for another very interesting topic. Thank you for linking the show, Kevin. Oh, yeah. Fire emojis. Yes. Very good. Thank you everyone for tuning in. We hope you have a great day. Enjoy your week, folks. Have a good night. Good night. Strong feelings, please let us know. The discussion is open. The issues are open. That way.",[],[],{"reps":216},[217,273],{"name":218,"sdr":8,"link":219,"countries":220,"states":222},"John Daniels","https://meet.directus.io/meetings/john2144/john-contact-form-meeting",[221],"United States",[223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241,242,243,244,245,246,247,248,249,250,251,252,253,254,255,256,257,258,259,260,261,262,263,264,265,266,267,268,269,270,271,272],"Michigan","Indiana","Ohio","West Virginia","Kentucky","Virginia","Tennessee","North Carolina","South Carolina","Georgia","Florida","Alabama","Mississippi","New York","MI","IN","OH","WV","KY","VA","TN","NC","SC","GA","FL","AL","MS","NY","Connecticut","CT","Delaware","DE","Maine","ME","Maryland","MD","Massachusetts","MA","New Hampshire","NH","New Jersey","NJ","Pennsylvania","PA","Rhode Island","RI","Vermont","VT","Washington DC","DC",{"name":274,"link":275,"countries":276},"Michelle Riber","https://meetings.hubspot.com/mriber",[277,278,279,280,281,282,283,284,285,286,287,288,289,290,291,292,293,294,295,296,297,298,299,300,301,302,303,304,305,306,307,308,309,310,311,312,313,314,315,316,317,318,319,320,321,322,323,324,325,326,327,328,329,330,331,332,333,334,335,336,337,338,339,340,341,342,343,344,345,346,347,348,349,350,351,352,353,354,355,356,357,358,359,360,361,362,363,364,365,366,367,368,369,370,371,372,373,374,375,376,377,378,379,380,381,382,383,384,385,386,387,388,389,390,391,392,393,394,395,396,397,398,399,400,401,402,403,404,405,406,407,408,409,410,411,412,413,414,415,416,417,418,419,420,421,422,423,424,425,426,427,428,429,430,431,432,433,434,435,436,437,438,439,440,441,442,443,444,445,446,447,448,449,450,451,452,453,454,455,456,457,458,459,460,461,462,463,464,254,465,466],"Albania","ALB","Algeria","DZA","Andorra","AND","Angola","AGO","Austria","AUT","Belgium","BEL","Benin","BEN","Bosnia and Herzegovina","BIH","Botswana","BWA","Bulgaria","BGR","Burkina Faso","BFA","Burundi","BDI","Cameroon","CMR","Cape Verde","CPV","Central African Republic","CAF","Chad","TCD","Comoros","COM","Côte d'Ivoire","CIV","Croatia","HRV","Czech Republic","CZE","Democratic Republic of Congo","COD","Denmark","DNK","Djibouti","DJI","Egypt","EGY","Equatorial Guinea","GNQ","Eritrea","ERI","Estonia","EST","Eswatini","SWZ","Ethiopia","ETH","Finland","FIN","France","FRA","Gabon","GAB","Gambia","GMB","Ghana","GHA","Greece","GRC","Guinea","GIN","Guinea-Bissau","GNB","Hungary","HUN","Iceland","ISL","Ireland","IRL","Italy","ITA","Kenya","KEN","Latvia","LVA","Lesotho","LSO","Liberia","LBR","Libya","LBY","Liechtenstein","LIE","Lithuania","LTU","Luxembourg","LUX","Madagascar","MDG","Malawi","MWI","Mali","MLI","Malta","MLT","Mauritania","MRT","Mauritius","MUS","Moldova","MDA","Monaco","MCO","Montenegro","MNE","Morocco","MAR","Mozambique","MOZ","Namibia","NAM","Niger","NER","Nigeria","NGA","North Macedonia","MKD","Norway","NOR","Poland","POL","Portugal","PRT","Republic of Congo","COG","Romania","ROU","Rwanda","RWA","San Marino","SMR","São Tomé and Príncipe","STP","Senegal","SEN","Serbia","SRB","Seychelles","SYC","Sierra Leone","SLE","Slovakia","SVK","Slovenia","SVN","Somalia","SOM","South Africa","ZAF","South Sudan","SSD","Spain","ESP","Sudan","SDN","Sweden","SWE","Tanzania","TZA","Togo","TGO","Tunisia","TUN","Uganda","UGA","United Kingdom","GBR","Vatican City","VAT","Zambia","ZMB","Zimbabwe","ZWE","UK","Germany","Netherlands","Switzerland","CH","NL",1773850437382]