 So today I'm going to be talking about decoupling weather storms in Drupal, partially decoupling them. So as Mike said, this is a preview of my submission for Drupal South Wellington. I guess this is not what happened in a lot of talks, but I'll be asking for feedback. Please note that it is not complete because I don't have that much time to do things. And any feedback is useful, whether I did touch on something you'd like to know or I did touch on something you'd like to know and didn't talk about it enough or there was something that I thought about linking with anything about it. That would be helpful. Hi, I'm Bryn. I am a CSS wizard, but I need a day job, so I do Drupal sites. I do Drupal sites really, but mostly with Drupal. I work for iPhone Agency. I previously worked with Modern AX, but didn't do anything. I think that's about a month now. You know, putting out buyers there and there, that's very common. We have a few of these partially decoupled web forms down in the wild, and it's very cool. I will show you one today if I remember correctly, but it's, yeah, interesting. I have a few running locally on another machine in my bag. I am interested in more complex forms, and ones that don't require submissions because they can't run on a CSS. Anyway, so I guess what is user experience? It's basically when a user lands on your site, isn't it good? Are the, in this case, user-friendly, or do we just give them 1,000 builds to fill out, and we don't put any aspects on it? Things require it, and we've all been on that site. We've already get to the end, and you can fill out 1,000 right at the top, and that just is a disaster. So I guess user experience is how the user experiences you, so I'm going to skip over this, because I think it's pretty good. So why do we need to decouple web forms? Kind of bad. So in my opinion, the web form module is a very good administrative tool, and it allows a user to build web forms very easily and quickly with conditions, pages, and all sorts of wild things that I've seen in my time. But I guess the front-end is kind of cringey, as someone that enjoys looking at pretty things. Web form is not one of them. Specifically with multi-page forms. It kind of looks like it was made in 2001. I never progressed past that. It's got issues, but nonetheless, they do work. And we kind of like the back-end, but we kind of don't like the front-end. So in my opinion, that kind of gives us a good candidate for something that we should probably decouple and make nice. So these are a few screenshots of some sites that I've worked on with very cool, boring PHP-based forms. As you can see, they're pretty fun. I actually couldn't find many page forms. And any that were paginated were kind of fine, so I didn't want to show them to you. But they kind of... I'll get into the technicalities later about why there's some things, but as you can see, basic forms... I don't think you really need to do a couple basic forms if you've just got a standing contact form or something. This is pretty fine. There's a lot of work for not much reward if you're doing something like this. Yeah, so those are... When you're using paginated or like page-based forms, you access the headache. The UI is kind of bad. You've got to send an Ajax request all the time. Go to the server, don't make sure everything's fine. Use the experience. So I guess why is progressively de-coupling this a good option? Like I said before, the webform module handles webforms really well and building them. It's very easy for administrators to build a form out. They just select the builds they want, the types of builds they want. It's very easy. But I guess there's a few... There's five things that are sort of lacking in a way. Once you start to have one, you kind of don't want to change it because it can make things go a bit varied. But there's some things that we can do to make it a bit better. So then we need to think, okay, if this is a candidate for de-coupling, should I fully de-couple this form or should we progressively or partially de-couple this form? I guess fully de-coupled for anyone that doesn't. How many people don't know what de-coupled forms or de-coupled things are? One, two, three. Okay, you. So when we're talking about de-coupling, we're talking about using... So if we talk about de-coupled, here's your... So this is traditionally a traditional sort of renderer or a couple. And then a fully de-coupled, in this case I'm just going to keep saying form, but this could be any kind of component on the page. We would have the CMS just acting on its own and then maybe like an API endpoint or something passing the data to that component and then it would be rendered in the page without Drupal rendering the page at all. So things like Facebook and stuff, they're using technology that allows them to, you know, build out their pages without having to have like a PHP render the page in that instance. And then we have this progressively de-coupled on the bar side, which takes advantage of Drupal doing its thing so Drupal still renders the page, but then we use, you know, a framework, ReactU to render a page component. And in this case that's a word form. So we would still render the page with Drupal, you would still get all the nice things, big pipe, et cetera, making sure that like your page is still performant and you're getting all the other nice things from Drupal, you're getting some context from users or any of that other stuff. Or like I guess we might want to use this in a page where we have page content and then we're just attaching a word form to the bottom of the instance. We don't really want to decouple the whole site, we just want this form to be nice. In this case partially or progressively decoupled components are a really good way of sort of like rolling forward. I mean at some point you could have decoupled every component on the page and then you're basically here and you don't really need to worry about Drupal rendering anything anymore, but progressively we're talking about let's just do one thing at a time, ship a feature, make it good. Eventually you could get to this point, this is another bag of cats. This one will just work as long as you can run the JavaScript on the page. So I guess that's basically fully and progressively decoupled out of the brief overview. I don't want to do too much detail about that. So how do we implement those things? We build our form like normal. So if anyone that's never seen a web form that we built, this is what it looks like in Drupal. Very cool, very snazzy, pretty easy for a person to understand. You can add elements, pages and all sorts of things. That's all well and good, but I don't have a picture of it. It's going to be a bit really cringy, but I'll show it later. So we build our form like normal, which is exactly what we want. We don't want to change that because this bit's good. We have to decide how we're going to get our information to our components because it doesn't just appear in places. So we have three choices. Drupal has a JSON API module. It uses REST API by default. And then there's this little bundle of fun in every Drupal cycle of Drupal settings, which is my weapon of choice in this case, only because I don't need asterisks, I don't need another module to do the REST API. So I could use that by default, but webforms aren't enabled because it's a third party module. So that requires the webform REST module. And if I want to make submit, I'll asterisk this now. If you want to make submissions with that, you will need to use the webform REST module, but I will talk about other cases where we don't really need to make the submission. We just want to use the form builder for making nice things. And the JSON API module, it's all well and good, but you need a module. It's going things like, I guess the thing I like about this is that we can use it on Gulfseam Earth because we don't need to install anything unless you're on the submission. Don't ask me about that. But basically, we choose Drupal settings because it's a native thing inside of Drupal and every page gets rendered with the Drupal settings. So we use this very basic snippet of code that attaches to the Drupal settings, a new webform object. So Drupal settings just outputs a JSON blob in your page and that's how your page gets rendered essentially. But this trimmed down version basically says, like, I want an object, I want a webform object and the form ID and then just, like, all the data and that's where I'm storing all the field data and stuff. I'll show you the version a little later. And then we want to add some sparkles. Anyone that likes the Simpsons? This is Thomas and this is Sparkles. Very cool. So you pick your framework of choice, never pick Angular for anyone in the crowd. This is a really bad choice. Never do it. I prefer Vue.js just because it's better. Bring it to your question. Yes? What was the logo on the bottom right-hand corner? Stanley. Thank you. I have heard that word. It's a very cool new Earth framework. I've used it one time for a side project and it's pretty nice. But I like Vue.js. I don't know why. Like, bring. So in Vue.js, I just have a form function that just grabs the window object and then looks for the variable settings webform and data and that's going to return all that information into the form object and that is how we get our information into Vue.js. Let's have a little bit of fun. I will just quickly show that this does work. So we have like a basic webform here. I can still choose these things. I'll choose Sunday. Next. January. Next. You can see I'm rendering out different parts of webform. This is just plain text. I can go backwards. You can see my progress by a little while dating because I'm in a framework now. I don't need to make a request. Like Ajax doesn't need to send a request back to Drupal. We'll get more information. In this example, I don't have any conditions but we basically read great conditions in JavaScript. So we were able to use logic in forms. I had to do some funky stuff on the PHP side as well but that all gets in there. I'm just going to press next and then submit. I'm not going to do anything because I haven't put in the redirect yet but nothing has changed too much and I can check my results. Yay! That's why I said it's cool. So we can see my information got into Drupal. I'm going to show that that was a form. I'm seeing that I have UVS running on the page. Yay! Very cool. I guess some advantages for using this. I'll show you one in a while. This is where we first started using this technique. I guess when we first started using it it was mostly because our designers wanted animations to start in forms and that's really not what PHP is called. Or Drupal in general. But you know, I guess JavaScript is really good at that kind of stuff. So let's try it. This is kind of an unsolicited plug for the energy innovation tool kit. But pretty much from this moment on everything from here down is all JavaScripts. Well, all UJS rendering it. All of this content. So this isn't built-in GovCMOS but so we can make custom models. So we've got a custom model that adds party settings into Drupal for everyone to know what that is. We basically have some nice things that allow us for the user to be able to just add more content into the form without having to create content somewhere else and then do some complicated stuff in Webform to grab the identity references and then grab that later if it's complicated. But all of these models can start all rendered from Webform. We're going to make a real submission here because it's fun and cool and I want to do that on my size. But this site uses conditions. I have a local version running on my computer and they will go back if anyone wants to look at it after. We're happy to spin up the local environment and actually get into the weeds a little bit. But so I'm just going to quick through this thing. You'll see that the progress bar is responsive to our answers. Actually, one... I think they are important there. So this form is like 57 different... Oh man, there's so many outputs. So this particular form here has about a total of 47 questions and then at the end when you submit those results you get central result page and that gives you a very specific set of content. Based on how you answered everything. I mean so there's a plan in the ass to sort of make sure that there's no regressions but we wrote Cyprus tests to make sure that this continues to operate as per we thought it would. If you can imagine, I've got this very cool form extra thing that I built. If I turn this off and we go back and look at that whole form. As you can see, this is the grossest that exists. You can imagine having those questions in this giant long cool bar at the top telling you how many questions you've got to do and how much you're going to hate your life by the time you get to the end of it. It's kind of frustrating and users don't want to see this gross. Like yeah, we could use CSS to tidy all this stuff up and that would be fine. That wouldn't really matter. This progress bar at the top, you don't get any nice animations. I should probably share this first, hey. I better like reload my page. I may have to turn on AJAX but I better wait for the request. It's kind of annoying. With a form like this, I can just press next and I get some nice animations on my progress bar. I don't want to sell gas or electricity. I get contextual updates to where I'm at in my form. If I say yes to this, it doesn't move this bar because I've got more questions to fill out. It's going to be too much None of them require that simple same job. But we have built forms that do they're very fun. Yeah, I think you can tell this is very normal but if I press the menu, I get sent to this very cool page. And this is already a bit triple. We wouldn't even know. So this page in particular is already a bit triple. There's a big component here. No worries. It's like your results and stuff is all just content sorted and triple. We want to know. These are all nodes. You've got to pass them on to do the conditions for this page. But you wouldn't even know the difference if you have a few JSs or if you're running on the page. It's very performant and wild. But yeah, I guess I haven't really thought about how to conclude this at all. Another gift. Another gift? No, not one. I can just look at this while I go. Nah, you're so smart. I guess the reason why we do this in this case was there was a bit of a unique reason for having animations and stuff. We were trying to just deliver that single question at a time. We wanted someone to be able to step through the form in a smooth way without having to wait for a response from Drupal. If you have a slow connection once the form's loaded, that's it. You don't really need to worry about load times or anything like that. The server's choked up for some reason. You've got to share those in computer for a while now. Or something like that is it's not an issue. We do a couple of few other components like the back of top button and stuff but we already have VJS running on the site. I don't think there's any reason not to. We've used it in a few other cases where users had quizzes and stuff because of the way for someone to be able to build out a little questionnaire. So we used the form because it already has that sort of building capability. You can already make pages. Really, I don't need a way to handle text and results. And then we're building GovCM. So there were some crazy ways that if you were building your own site and it wasn't mostly GovCM you could just write custom builds and build types that went form and it would be really easy. Like once you had the button down it's easy. But yeah, I guess in short, it makes a better user experience. Mostly because it's smooth and not janky. It's pretty lightweight as well. Not too bad. You're not really imposing any models on Drupal because Drupal settings is kind of it's already there in the head. Now in Drupal 10 I should put a new one. Yeah, so he used to be at the bottom but basically I know it's going on and on now. I might just stop talking for a minute about Drupal settings. Very cool. So if anyone has any questions you can ask the phone or ask what it is you want. So obviously and I agree with a lot of perspectives building with forms behind the scenes front end. I like it's obviously helped some of that stuff the progress part of the classic one where it just jumps around and obviously from a maintenance and up-to-date perspective that's a good one because you get this super technical like you get them in constant tweaks for one thing. Is there any sort of overhead challenges on the other side if people start I don't know, adjusting a bit a bit deeper adjusting those sort of things is there a flaw on that? I guess if you write a PhD properly now Essentially this is what form includes one you can easily switch back and forth by turning off that toggle in Gov Seam as you could and do that so we add any category to the form and we just check to see if someone was using the modern form category there's a toggle in some cases. But basically it just loops over all the fields and just provides a type if UJS doesn't find a type it just doesn't render it. So like if you're putting in a weird or a complainant that hasn't been configured yet in view then you're not really running into any issues unless someone's made a required thing on the form and someone tries to submit it So if you're writing pages and you've got pages you've found but if someone's trying to put in a capture can they configure them? Yeah probably but you just need another dev again to probably just come in and fix that problem or just turn off your modern form and there's four back options. Yeah I think like it's reasonably robust of course with any of these sort of like running any magic things that exist there's a lot of each statement because you're kind of just a bit worried that someone's going to do something wrong or there's something that you're expecting to be there and then someone thinks that I've forwarded this as you can tell I never delete this but I've forwarded this to maybe five different instances of Drupal and it worked pretty straight I spun this up last night and I played third as well so I didn't really I guess need to do that much you kind of just plug and play a little bit there's like some you have to do a template so it's this basic thing using that modern form just render the app around it and if not then just render the form but like there's not many pieces to puzzle that's kind of the surprising part and the best is like once you get sort of I've found that as you start to develop more you get kids coming in with their JavaScript skills their backwards caps um not really wanting to touch Drupal or when they do they kind of make it cringe like Drupal is a very good content management system you kind of do it right and you can get you can go wrong real quick and sort of end up in a snowball of terror because your content model is bad at least with this you can just have your Drupal person come in and build out the things and then you can get your kids with their backwards hats making their JavaScript things if you want but in an ideal world maybe the time is I guess probably with my good case most likely we built that way I reckon but now I think like this partially decoupled components are a really solid get the best of both worlds Drupal is quite good at rendering but we can all agree that this thing in Drupal never really did there's also things that aren't great so we should just fix them sometimes we can't fix all of this because we can't fix all the maintainers abandoned or whatever I guess I would rather be fired right um and I think that this is like robots and I use it in a few sites now in production and it hasn't formed over yet so I'm feeling that's pretty good so if I understand this properly so it's data driven the form still gets constructed what sort of coverage do you have in terms of webform components that will actually render in the front end like what kind of surprises are there there are some there's a few so I don't know if anyone's really ever dug in for webform birds I might have just held together a big paper string and that's put in the pilot webform is a module is kind of just like this kit of everything there's a lot of modules like submodels inside of it with addresses and all sorts of crazy stuff like building bad SVG and making maps and stuff that's crazy why does that exist because like some government agency in America was like oh hey it was like okay any good open source there um but I guess some of the gotchas really came in when we were looking at not the standard type of form because they had a different like the built object that came from Drupal was different than everything else which is kind of frustrating and so that this webform php file just ended up being a longer thing of just like if it's this part please just like re-render these things to be these things um but in general it was pretty good like if it was like text fields HTML radio checkbox like the standard suite of things that you needed in in a form then I can almost guarantee that you could just go and play this thing and like if someone just had amazing bite in this in this project but whatever compiler of choice or tool of choices all set up probably pretty much works pretty good must say that you know it will probably help me a lot but in business just free but yeah once we got this sort of this php side working getting it in once it's in a framework it's just like lots of dots basically access your objects yeah I think once it was in there there's some weird things like we could have gone down we looked down the rest api pathway first let me tell you I'll put it back take me on that one you can take that to the bank there's lots of stuff in there that's just like not required submissions are like deep bubbled out from the initial rest call you've got to go back and like reference oh I've got this idea from my field okay cool let me make another request to go and get the field now pay me off this way easier people say maybe never put ideas in my life never ever and now I'll put this on every side of that yeah yeah Kyle have you noticed any difference in table size to what you're turning it all back on any competition no I haven't particularly checked too much I mean that slide that I was showing before runs in platform usage barely see any any issues on the creation side or anything like that it's not really a problem I think it's just compiled JavaScript at that point barely have any issues at all basically objective what you're exploring and can I give this all an example of what you're talking about I do talk now but yeah that's probably a presentation yeah cool yep I will do that Kyle I can there's probably some like Facebook and all those Twitter people Twitter kids out there if you use that up you use that decoupled up fully because JavaScript doesn't need any there's no render up like it's just a HTML file with an app in it I don't know how else to explain it really progressively decoupled things I think the people in previous notes do some cool work in that area so I'm sure I could probably track down some slides that use it I don't know too many but I guess it's good because you can just sprinkle it in if that's necessary but yeah I think it would be a good idea to sort of add that in some good solid examples with those that would be good yeah? how do you handle I'm not even doing some hindsight validation but what if you need to do something like that in the PHP you can so we pass across conditions and like one of the conditions is that this build is required if you can do it in my form we can do it in the form obviously that's what you're saying still three different settings like we just basically process the form and just pull out all the stuff and reorganize the order so it's not gross but like you can see there's there is conditions on this page of like one of these must be selected so I can't go next but maybe if my dribble source gets accepted I'll have a better explanation around conditions and stuff that might be helpful but yeah I think conditions do work I'll boot up a site and I'm having to show you we've got those quizzes and stuff that I was talking about earlier they use conditions that sort of render out the right page in certain circumstances like there's a bit of a if you select yes on this you get this score and you get that score and then you should be sharing this if you're going to get a binary score so webform handles all those like those conditions are from the webform itself we're going to have a silly question so the normal form that you like can be used in the webform and then pass all the validations to the front end for the coincident kind of design with the with the decoupled form so you could use something like vvalidate in view I'm sure that's React libraries that do it for you or you can just write custom validators so like we've basically a rewrite of our group of this sort figuring out those things and then the conditions are just passed in by an object from somewhere in here where check to see if the pages are valid process conditions which basically is what's running here but basically you pass the field and the values that it should be expecting and then you each field has an object on it for each condition and then it just moves over every field, like every condition and in Drupal you just say like this field needs this condition to render and that would work normally but in this case we just take that condition and then just do a jump script check in some of the PHP one and then we just render that field if it can be or not so which means you only need to set the validation once and then if it took all it can render the validation so when the page initially loads it goes and grabs all of the fields and all of the pages and all of the conditions it just bombs it all up in that setting it bombs it on the page and then when we get to you can see here in this form we have form pages and then but just like for every page just make a page view form page and then that has fields attached to it and each page has each field attached to it and then the conditions are also faster with those fields if I have a running example that I can show you in the web form it's clear but web form facilitates you being able to do those like that validation and so that's another question let's say that you have a website and you're going to make like 10 forms and you're going to use a whole range which means you're going to use a huge add to build those 10 forms and how many real apps you want to create with your format? Is it like one where I have not all of those things online you want to create a 10-year app so in this example we create just one and you'll see that I just declare the app here and then I just declare the components in that complex form so we could just declare all different types of components here so I could have form 1, form 2 50 if you want and because I'm only creating the app one time here I'm not like creating it like on per page we would be creating a new app but like in the AER one we just wrap the whole site in the app view because it's back to top but in theory you only need to create one so one app with 10 form component yeah you just have to make each form if it needs to be there's no real reason why it needs to be 10 different components you could just make one form component and then like if you make your component correctly you should just be able to create a new web form and use it talk with me after but I will just create a web form and I'll show you that it works yeah, like there's no real reason to unless these unless form 1 and form 2 are distinctly different then there's no real reason to really create components like that and even if they were I would suggest there's a better way within web form to define like you could render a different component if it had these categories like if this form was in category A and this form was in category B category B renders components X, Y and Z and then component A does A, B and C like there's not really any real reason why you need to create different components essentially they're all the same form right? we don't really care for me the JSON API is what I'm used to working with so it's good but I need a model technically I need a model with triple settings as well so it's not really a valid argument if I want to make a submission because the web form endpoints unexposed with the REST API out of the box um the REST API I don't know I just don't like the REST API they're alright but triple settings seems like it gets rendered on the page anyway so if I'm doing partially big couples there's not really a reason to have another endpoint that I'm hitting every time like I'm already learning the page and triple settings are already there so may as well use it I guess if it's a herring so when I say endpoint like if I was to use the JSON API for instance and not triple settings when I load the form I would have to get another URL to get that data sent back to it so the web form would have to request information from caller slash API slash dot form slash ID or whatever the thing is and then I would have to yeah I would have to get the data from there and then it would have to be sent to the component and then my component would then have to handle that information might be already but with triple settings like when I render the page and it's a web form like the web form is on the page it's already automatically being put into the triple settings as a JSON object already so I don't need to do another request like it could be slow it could be some weird validator somewhere that broke down but I know that with triple settings it's 100% it's that making requests kind of stuff but it's not too bad I mean it's not a valid option to go like if I was to choose between JSON or REST API I think I'd go JSON API just because it's sort of what I'm used to looking at I don't like JSON rules but yeah with the triple settings I have a bit more of a droopy way of doing it yeah, now see you