 Felly roi, roi sicr yn fydd. Mae hynny'n gweud credu y bwysig i'r bobl fyddwyr ar gyfer drwpol. Rydyn ni wedi gan diolch wedi dipyn o gael gwlad. Cyngorol yn synodol yn y bwysig ac mae'r cyngor ond yn ymwysigol, felly rydyn ni'n rhoi ymblch yn siarad iddo ymwysig i'r gweith save. Yn gyngor y ffordd drwy Walson Hym, oedd chi'n gweithio, oedd ymgromog, ac rydyn ni'n rai'n ei gweithio o èch, ac ymdweithio i'r cyndaill yn rhimol. So, my name is Phil Walsonholm, I'm a front-end developer at CTI Digital in Manchester in the United Kingdom. You can find me on Drupal.org as Phil-Walsonholm and on Twitter as PhilW underscore. We've got quite a lot to talk about, I was quite ambitious in what I put in my talk abstract, possibly overly ambitious, so if we run out of time then come find me at lunch and talk to me on Twitter, happy to answer questions then. So, we're going to be running through what progressive decoupling is compared to regular coupling or decoupling rather. We're going to be talking about what view is in the context of front-end UI frameworks and libraries, talking about why I feel view and Drupal are really good partners, then getting into a little bit of a case study and then finally some tips if you want to take this back home and start playing around with view of Drupal. So, we'll start with what progressive decoupling is. So, decoupling in general is when we break the bond between Drupal as a back-end CMS system that provides data and Drupal as a sort of system that renders your front-end. We can think about coupling and decoupling on a sort of scale or continuum and this is what we have up here. So, on the left-hand side we have our traditional coupled Drupal site where Drupal gets the data, Drupal renders it, it knows exactly what's going to be on the page and because it knows exactly what's going to be on the page it can do nice things like in-place editing, contextual links, layout builder, live previews or that kind of Drupal-y stuff that we know and love. A fully decoupled site is on the opposite side of the spectrum, so on the right-hand side and that's where Drupal is purely sort of an API, a data repository, a content hub and use a framework or library, live view or Angular React to handle the front-end routing, content changes, UI stuff all through client-side JavaScript code. Progressive decoupling exists in the middle in a sort of a happy place where we use Drupal to do all the bits that it's really good at and then we add a layer of JavaScript on top to do sort of more dynamic application-like stuff that Drupal's not necessarily so good at. We'll come back to more benefits of that in a later slide. So, with progressive decoupling, Drupal handles the routing, collecting data from the database or other sources, transforming it through things like text filters, making a render tree, allowing other modules, Contrib, Custom Ones themes to transform that render tree and then finally dumping it all on the page as HTML. So up to that point it's a traditional Drupal site. The difference with progressive decoupling is that we then layer on top of that a bit of extra JavaScript and this could target just a small part of the page. It could be like a block with a live weather widget in it or it could be a larger part of the page, for example, like a real-time block for a sport event or a political event. So we can imagine that most of the page would be Drupal. The header and footer could be normal Drupal blocks. There could be a sidebar of normal Drupal blocks. The only thing that would be handled by the JavaScript would be the section in the middle where we need the dynamic content. Everything else is standard. This is a pretty crazy diagram from a Dries blog post in 2019. We don't need to look at it too closely but I'll talk through what it describes because it's a good way of covering the benefits. In this top red box we've got two columns. On the left we have editorial interests, so I want to be able to have a live preview. I want to be able to control page layout. I want to use in-place Edison and I want my HTML to be accessible. This is a big thing for me with decoupling. A lot of effort in Drupal goes into accessibility. We have an accessibility gate, so we know for sure that things like our form API is always going to produce accessible markup. When we give control of things like forms to a decoupled site, there isn't that guarantee, so you have to make sure that your developers are sufficiently aware and skilled up and able to match Drupal's level of accessibility. If you have a coupled site or progressively decoupled where Drupal is handling the forms, you don't need to worry about that as much. On the right hand side we have more developer needs. These are things like I need to be able to control the markup exactly. I want to use JavaScript because I'm going to be pulling in lots of APIs. I want to do real-time stuff. It's going to be hard to do that in PHP. There's also agency needs. We find it hard to find good Drupal developers, but everyone wants to do React, so maybe we should just build more React sites because it might be easier. Progressive decoupling is when you have both of those problems. You have editorial needs, you have developer needs, and you need to find a compromise. That's what the second box says. It says requirements reflect both editorial and developer needs. The decision tree there leads down to a progressively decoupled website. It's a quick introduction to progressively decoupling. Now let's talk about view. This isn't going to be a super technical talk. It's not going to introduce anything crazy, not too much detail. I really just want to raise awareness of using view because it's probably in the last five years been the thing that's made me most excited about my job. It's changed how I feel about front-end development, especially with Drupal. I absolutely love it. It's really amazing. I don't want this to get into a view versus angular view versus React talk because it's not that kind of talk. If you want that, there's millions of medium articles about that, but I am going to talk about what I think view strengths are, especially in a Drupal context. View, ViewJS, pronounced view, it's an open source UI framework. It's from the second generation of these things, so it's not like Ember or Knockout. It's more similar to React. It's maintained by a core team, similar to Drupal in a way. The lead developer Evan Yu used to work at Google. He used Angular day in, day out, and he thought there's good bits about this, there's bad bits. What if I made my own version? He doesn't actually work at Google anymore. He works full-time on view funded by a Patreon campaign. I checked this last night and he receives $20,500 a month from commercial and individual sponsorship. I think that shows how strongly the view community feels about the product. As a result of that, View is independent from any big tech company. It brands itself as a progressive framework. What that means is it's incrementally adoptable. You can start off using it really easily to control just one thing on your page, and then as your skills develop, as your appetite for using View develops, as your requirements get more complex, it scales with you. It's really powerful, but it's not overwhelming. Finally, the last thing is really important. It's template-based, so rather than writing sort of a JavaScript-defined version of HTML like JSX, you write valid HTML and View will parse that and it will turn it into a virtual DOM at runtime. Got another one of these scale slides, and here we're going to be talking about the sort of footprint of the size and the ambition of these frameworks or libraries. On the left-hand side, we've got React. It's a library rather than a framework. It does one thing and it does it really, really well. It helps you build your eyes that react to use it input. For other features, there's a massive ecosystem. There's so many additional things that you can extend your view app with. That ecosystem is healthy, it's big, and that's really great. There's kind of a cost to that size. There's so many options. People have very strong opinions. You need to spend time finding what works for you, and there's sort of a cost to that decision-making. Angular, on the other side of the spectrum, is a framework, so it tries to do everything. It will handle your routing for you, your form validation, or your UI stuff. It's quite heavyweight. You need to buy into using it. You need to commit to using it, but it saves you from having to make design decisions which can take time and be difficult if it's not your specialist area. View, similar to Progressively Coupling, occupies this nice middle spot. The view core is quite small. It's about the same size as jQuery. It does everything React does with a few extra syntactical sugar type stuff. It's got tools for managing animations, tools for managing transitions, but it's not too heavyweight. It kind of stops there. If you want to extend it, there's core plug-ins, so they're separate from the core code base, but they're maintained by the core team. There's an ecosystem which is much smaller than React, but it also has less duplication, so if you need to extend it, there's generally one thing that most people use, or one or two things. So it's got a small footprint. You can extend it, and when you need to extend it, it's not overwhelming with choice. You can talk about why I think it's really, really cool. The fundamental thing is that it gives you a shift in the way you think about your front-end development. So rather than the DOM being a single source of truth as it was in the jQuery days, everything's now databaseed. So if you have an element and you want to add a class to it, you have a JavaScript object that represents that element's classes. You bind that object to the element for a view directive, which we'll talk about in a minute, and then whenever anything adds to that object, whether it's a method in your own code, whether it's someone using the view developer tools, whether it's anything else, the DOM will automatically be updated in real time. So you tell view what data you want to track, and that could be strings, it could be objects of classes, it could be arrays. Whenever those things are modified in any way, it picks up on it and it updates the DOM. So there's no need to create events to watch for changes. We don't have to bind our code to sort of long query string selectors or anything like that, and it just works really, really nicely. As a bonus, a lot of people are using View as a replacement for jQuery. So there's two articles here, Smasher Magazine and CSS Tricks. I'll tweet the link to my slides afterwards if you want to check them out. And View works similar to jQuery in that you can attach it to anything on the page. It can use existing markup, which is really, really great for working with Quick Templates. And we've actually got an example here. So I won't spend too long on this because it's something that many of us will be familiar with, but in the jQuery way, we write a selector, we attach a click event, we do some class toggle in, we do some attribute toggle in. If I was to change that button to a different element, or if I was to change that toggle class, the whole thing would stop working. With View, we've got some new things to introduce. So we have View Directives, which are kind of extensions to HTML that you put in your twig, and which tell you what to do, basically. So that click, that means attach a click event. The colon before area pressed means bind value of area pressed to active, or evaluate this JavaScript. These things would normally be in your JavaScript, you wouldn't have the actual click event function in the code, but it's just an example. Later on, I'll show you a bigger example. And then on our JavaScript, it's just four lines of code. We tell View that we're dealing with this element, and we tell it to track a piece of data called active, which is a boolean, and it starts off false. When the click event happens, active will be set to the opposite of its current value, and as a result, this will update, so area pressed will be toggled to. We've also got a class example here, where we've got a object, which is bound to class attribute, and the class red will be shown if the value of active is true or false. So we're not using a toggle class function, we're just dealing with standard JavaScript objects, standard boolean stuff, which really helps you not get too confused. Another massive thing for me is it's easy going learning curve, so it feels like an extension of HTML rather than a replacement. The documentation is really solid, the community is nice, the dev tools are great, it's quite an easy thing to get yourself into. As an example of the developer experience, I wanted to show how to do something in React, and then how to do something with View. This is how to do a two-way data binding, so what that means is when I type in this input, the value up here is updated. So our HTML is just an empty div called app, and then in here we've got a React component, we set up some state to track value, we've got a function that handles changes, and then we've got our sort of template in the JavaScript file which gets rendered onto the page. So it's quite a lot, I think, of code. I'm sure someone who's better than me at React will be able to write that in a nicer way, but this is an example I adapted from a Flafio Copes tutorial, so hopefully it's okay. To do the same thing in View is that. So this is an example of View knowing that there's going to be a lot of people doing this, a lot of the time, and it provides a little shortcut, which is vModel. So vModel means basically bind this value and then on change, also update that value. So rather than having to specify those two things separately, we're doing it just with the vModel directive. So this would be our twig file. We can see that the markup is in twig, so we don't have to reconfigure our IDE to do syntax highlighting differently. If we've got things processing those twig files, we can still process them. The markup stays where it belongs really, which is in a Drupal templator language. On the JavaScript side of things, we attach View to the element, which is the ID in the HTML, and again we tell it to track a piece of data called name. So that's all it takes. This is a slightly more complex example. It's like a name badge generator. I'm typing in here the name badges updating. We're going to show you some more View directives here. So up here we've got something called vCloak, and what that does is that is removed once View has initiated itself. So in your CSS, if you put vCloak displaying none, that means this whole thing will be hidden until the JavaScript's run, and that stops the user from seeing the placeholders. We've got vIF here, which we use to toggle. So if the name's empty, we get the shug emoji, which comes from here, because we've got an exclamation mark in front of name. If name has a true value, then we show the capitalized name. What capitalized name is, is an example of a computed property in View. So computed properties are really, really cool. They're basically taking an existing piece of data, which is name, and they transform it. And View is clever enough to work out what the dependencies of the computed property are. So it knows that if name changes, then the capitalized name needs to change. And it's clever enough to only update the bits of the DOM that need it. So it's not going to render the whole page again. This is an example of the View DevTools, which I love. They make debugging so much easier. I've extended the example a little bit. There's now a range slider. You can say how excited you are, and then this gets bolder in exclamation marks. You can see the excitement values increasing up here. You can also see when someone clicks Submit, this array, which is currently empty, is going to get a value pushed into it. So I'm doing this, I think with the keyboard or the mouse, but we can see that the DevTools is updating in real time, which is really useful for when something's not working and you want to try and figure it out. Important thing to note is that in both those examples, there was no build process. We weren't having to run MPM Watch or anything. You can use View just by including it as a script tag. If you've got a massive application, you're probably not going to want to do that. You'll want to use Webpack or whatever, but you can start off just doing it like that. That's what I meant earlier about it being really easy to dip your toes into it. For me, View feels really complementary with Drupal. They both have a focus on doing things in markup. With Drupal 8, we started doing a lot more of twig. With View, we keep our directives alongside our markup, so there's less context shift in between files. There's an argument there about separation of concerns, but for me, I'd rather spend less time switching between files and trying to remember what I'm doing. Perhaps that's a personal opinion. They both have a small core functionality, but lots of plugins. They're both independent, open source projects. With the case of View, it's easy to add to existing sites. The project I'm going to be talking about in a moment, we built it as a standard Drupal site until we realised the Drupal Ajax stuff wasn't going to cut it and we had to use View. So, let's talk about that now. The site we were working on was a university website, so obviously one of its core functions was to promote the programmes, the courses, the degrees that the university offers. Especially the undergraduate degrees, they had a lot of what they called variants. So, if I wanted to do a course in my airline management, I could do it full time. I could do it part time. I could do it with a foundation year. I could do it with an industrial placement year. I could start in September. I could start maybe in the calendar year in January. All these variants have different content because one of a placement year will take longer to complete. It might cost a bit more. Until the redevelopment of their website, each of these course variants was its own node. So, there was a lot of shared content between the nodes, but also a few differences. The university was hit with duplicate content penalties from an SEO point of view, and they also had a maintenance overhead. Their CMS users were having to spend a lot of time updating the same things in different places. There was even a bit of a concern about regulations, so the courses have content which has to be there by law and it has to be updated, rather, and they were concerned that having the different nodes would mean that they might not always have the right content in the right place. So, we wanted to get all of this stuff on one single page. We wanted to have a single canonical URL. We wanted to have all the Google juice on focus on that one page rather than distributed. We also wanted a much better user experience. The prospective students were frustrated about switching between all these different pages, trying to work out what was different, which one they should be looking at. So, we wanted a more app-like user experience. We wanted content to update automatically on the page for changes to be highlighted and for all of that to happen sort of instantaneously. So, this is the Drupal side of the solution. Nothing we did here was particularly complex, but we had a really good end result and I think that is one of the things that encouraged me to do this talk. We built something that feels advanced, but when you look at the code isn't actually that complex and as a result we've had very, very few like big issues with it, very few big bugs. On the Drupal side of things, we have a content type for courses with all the usual fields. Anything that's static that stays the same between variants is just a regular field on the content type, and then we have a paragraph field which contains all our variants. So, each variant would be like starting at this time, doing it full time, starting this time, doing it part time, and so on. We exposed the variant data to our viewer application for Drupal settings, which I'll talk about in a moment, and then we have a custom twig macro which prints these variant fields, but if a sort of wrapping element which View uses to control their visibility. So, all the data is actually on the page, Drupal prints it there. All we're using View for, well, primarily what we're using View for is to control its visibility. We also use it to like update the URL so people can share a query string parameter of the variants in. We use it to allow the user to copy the application code to their clipboard for when they apply on external site, a few more things. But the main thing is showing and hiding these variants and presenting a user interface to toggle between them. So, this is kind of a zoomed out view of what it looks like. On the left-hand side, we've got a larger view of the page, and I've highlighted in pink some of the things that change. So, this shows what modules are available, like what units are study. It's also got some introductory text that can change, so that will all be updated. Lower down, there's lots more of those examples, and up here, and on the right-hand side, we've got an example of the user interface. So, this is a sticky bar. We have a study option here, which is the sort of full-time, part-time thing. We also have a start date. Both of those are select elements. If you update one, the list in the other will change, depending on what's available. But we did some user testing, and it turns out not everyone sort of thought to interact with those. So, lower down, we've got these things which look like sort of links or buttons, and these do exactly the same. So, if the user misses the options here in the select element, they can use these instead. And of course, if they change them down here, it also changes it up there. It keeps it all in sync, and that would have been really hard to do, I think, with a sort of DOM in control approach, but with the data in control approach, that's fine, because we just write to the data object and then view updates everything for us. So, this is what it looks like in Drupal. You can see we've got a bunch of course variant paragraphs, and inside then, there's quite a lot of things. Start dates, sort of codes for the application systems, how long it takes, some more internal stuff. There's some entity references there to shared content, like information about the funding options available, or application requirements. So, let's talk about how we get that data out of our paragraphs and interview. So, this is a sort of simplified example. We're going to build a little view app which toggles between two logos. This wasn't taken from the university project. It was a project I was working on recently, which had like sub-brands, and we wanted to sort of be able to change the logo through view based on the Drupal setting. So, on the PHP side, we've got a HTML preprocess function, and we're setting our logo variant value to be B. There's A, there's B, here we're setting it to B. We tell Drupal, we're going to be using some Drupal settings on this page, so we attach that library, and then we create a Drupal setting with our module name and our logo variant key, and we set it to the value of logo variant, so it's going to be B. Then, in our view, we create the component or app, tie it to the ID of app, it could be anything. In our data object, we have got current source, and we're reading this from Drupal settings, which will already be on the page because we attached the library. So, current source is going to be Drupal settings, module name, logo variant, which we'll evaluate to B. Then, we've got an object of our two different logos, so two images hosted on Cloudinary, A and B. Down here, we've got another computed value called logo source, and what logo source is going to do is it's going to return from the array the key which matches this current source. So, this current source, Drupal setting, will be B, it will pick this out of the object. And then, in our markup, we've put a colon in front of the source attribute, which means we want to bind this to a view piece of data, and we're binding it to logo source, which we had on the previous slide. So, let's talk about how we used this. We had some things which are like simple strings, so those we just output a view placeholder with the double curly brackets, which we'll talk about in a minute. And then, when that changes in the view data, it gets updated automatically. We had some more complex stuff. We had things which weren't just the simple string, but were like whole collections of markup. Those things like the entity references, I spoke about earlier, which put in almost a mini page. For those, we made a custom twig function and a twig macro. And what that does is it outputs the field as per normal in Drupal, but it wraps a div around it, which has some of these view directives. And we'll look at that in a second. So, if you hide, shows and hides those elements, if you've got two ways of doing that, you can use vif, which will actually add and remove things from the DOM, and it has vshow, which will display none or display what it was initially. We used vshow mainly for performance reasons. If you've got a lot of things changed on the page, vif will be updating and removing the DOM in quite a lot of places, whereas if you've used vshow, it's just toggling visibility, which is a much cheaper way of doing it from performance point of view. What's interesting is we didn't actually use any APIs for this. When the work first came in, we were like, oh, cool, we can use JSON API. That would be great. But in reality, we kind of didn't really need to because we're just toggling the visibility. An advantage of that is there's no network request being made. So if I'm using this on my phone and I go for a tunnel, like saying on a train or something, it's still going to work because we're not querying an API. For more complex examples or things of external data, we'd probably have to use an API, but in this case, we didn't need to, which was nice. So let's get into the twig side of it. What we've got here is two divs. We've got a data attribute here, which we just use to flash with CSS if it's updated. And then we've got a condition for this one. We're going to be showing this if the user said they want to override this bit of content at a variant level. The more interesting bit is what we've got here. So Rutherford is our theme. It's like an atomic design theme with pattern wrap. So we named it after Rutherford, who was an atomic scientist in Manchester. So we're loading our theme. We get in its twig macros and we've got a twig macro called print variant. We give it the field name. We give it a list of variants, which we want to print. So this is going to print one, two, three, four, as many of these variants as there are for that field. And we give it a field type, which in this case is a long text one. This is our twig macro. So the main thing for us to focus on is the middle. What this does is we render our Drupal field here. So we've got a set block. We put the field markup in it. We end the set block and that's going to get printed out here. To wrap it, we've got a div. We've got a VCloc attribute so the user won't see like five different variants and then suddenly one as the JavaScript runs. We've got some data attributes which we use for the styling, as I mentioned earlier. And then down here, we have got a VShow directive and what this is saying to view is only show this div and its content if the current variant, which comes from the view data object, matches the variant ID, which twig is going to print a integer to. We also have a check to see what the current funding nationality is. So some things like the cost fees are going to vary if you're applying from within the EU or domestically compared to if you're applying from overseas. So that added a little extra layer of complexity but in most cases it was just updating our statements. So twig will run through this. It will print on our different variants. View will control what's shown and what's not. The next thing to do was to build the UI for the variant selector. So this is the thing we saw earlier where you can use the selector element, you can use the links or buttons. And I've pulled up DevTools here. So it's really small but in this highlighted area as the user interacts with these things, we can see that these integers are being updated in real time. So whenever one of these is selected, we know the user is going to need to see some new content. So we run through all of the possible variants. We look at all the start dates, all the study options so they're the full-time part-time stuff. We reduce those two arrays to their unique values and then we find start dates that match that study option and we update the list. So we used quite a lot of low-dash here. We used the low-dash filter function quite a lot. The one that extracts unique values, we could probably have done that with ES6 stuff but in my opinion it would have made it harder for other people to work on, harder for the product to be supported and it would have increased the barrier to entry to work on it. Something that's cool to note is that these are not actually buttons, they're not anchors, they're styled radio buttons. The reason we did that is because these things can only ever have one value. They can only ever be this one toggled or this one toggled for the dates and that's something that radio elements or rather inputs or a radio type give you out-of-the-box with native HTML. So we didn't need to write any JavaScript functionality to make that work, it just worked. That's a trend I see a lot in looking at other people's view code. The way it feels like an extension of HTML means that you're more likely to use built-in HTML things. So there are some caveats with progressive decoupling just like any other type of decoupling. Let's run through those, we've got about eight minutes plus we need to do some questions as well. So accessibility is a big thing. Browsers have been around for a long time, they're really good at letting the user know when there's been a page change. JavaScript and updating the DOM dynamically is less good at doing those things but we've got a few ways around that. First thing is to do you can consider using area live regions. So Drupal has a helper function for this if you search for Drupal.announce. It basically just reads out a string so you can announce that something's changed. For people that might have trouble observing which bits are different you might consider using an animation or like a focus ring type thing to highlight what's being changed. If you're concerned about making the page too flashy for people that might prefer less motion there's the prefers reduced motion media query so you could turn that off. And you should also consider setting focus to things that have changed if there is one part of the page which is changing. It's more difficult when there's multiple things changing. If you want to read more about this it's like a massive subject. It's quite easy to get wrong but there's also a lot of basics which cover most people's mistakes. And the accessibility project A11Y it's a numer in them. Accessibility project A11Y project.com has a checklist and a resources page and I'll tweet those links later on. The other thing to watch out for is SEO. So search engines particularly Google have got a lot better over the years with indexing dynamic content. The way Google does it at the moment to the best of my knowledge is with two waves. So it will initially index your site without JavaScript enabled. It will look at your plain HTML content and then later on it will do a second wave and that's when it will run JavaScript. So it's best to serve your sort of default state as HTML. So in our case the paragraph which is at the top of that multi-value field paragraph field that's always shown. So when Google runs through the page the first time that's what will get indexed. When it runs through the second time it will realise there's a bit more interactivity going on and it will handle that. If you want to see how your site looks from Google's point of view use their fetch as Google tool. Finally we've got some tips and tricks for using Drupal and Vue so these are things that I learnt in the hard way. The key thing with Twig is that they have the same delimiters. So if you print a Vue variable and if you print a Twig variable they're both wrapped in those double curly brackets. So we need to get around that otherwise you spend ages refreshing your page wondering why there's nothing on it. One way to do that is with Twig's verbatum filter. So what verbatum in a single curly bracket and a percentage sign means is ignore everything until I end this verbatum tag. Yeah it's not a filter is it? But that's really good because then Twig won't worry about those double curly brackets and they'll get passed to the browser which means Vue will be able to deal with them. A second way around that is to not use the double curly brackets at all. So if you've got quite a simple situation where we have this span and we want to put some text in it we can use the V text directive. So what that means is update the inner text of this HTML element to the value of leader type in this case. If you want to get really creative you can also change the Vue delimiters. You can set something on the window object which does that or you can do it per app so you could have it as double dashes or triple underscores or whatever but then that's going to make it harder for people that are new to your project that have to figure out what the special delimiters are. So those two are my favourite ways of doing it. Next tip is switching between the minified version of Vue which is great for production but doesn't have the dev tools. The way we do that is we have a Vue Drupal library for the minified version then we have a library alter hook we check to see whether JavaScript pre-processing is turned on at a Drupal level and if it isn't then we switch out the minified version for the unminified version which gives us access to dev tools and sort of much nicer error reporting. Final tip Vue tries to be helpful and it strips out HTML comments from Vue templates. If your Vue template is also your twig template that means it's going to get rid of your nice Drupal theme debugging comments which tell you what templates are being used. To fix that, just add this comments true line to your Vue files and then it will leave the Drupal template comments as they are. So in conclusion, I love working with Vue I think it's really simple but it's also powerful and I think it's a really good fit with Drupal particularly because of how you can use it with existing markup and in twig files. And that's it, thank you very much. So we have three and a half minutes for questions so maybe we do one or two and then I'll be around at lunch if anyone wants to talk about any of this. Does anyone have a question? Hey, yeah definitely. So the question was we're using Vue on this project do we still use jQuery, do we use Drupal behaviors? And the answer is yes, absolutely. Maybe if I was a purist, if my team was a purist we wouldn't be doing that but the reality is we've got plugins on the page like our tabs plugin, we need to control that and that's done through jQuery events so we use jQuery there. I also ran into a problem where our lazy loading script, lazy sizes wasn't detecting some of Vue's changes so we used a little bit of quite dirty jQuery there to fix that. We used Drupal behaviors for the content on the page which isn't handled by Vue. We also call attached behaviors every time view updates certain parts of the pages so that our Drupal behaviors that handle things like the tabs run. So yeah, the two can coexist. We haven't really had any problems with integration there that haven't been problems of conflict. So it's kind of a mixed code base at the moment but we're using what feels like the right tool for the right job if there's a lot of really heavy DOM stuff that can't be done with this database approach then we use jQuery because that's kind of what it's made for and it's still good at that. You're welcome. Anyone else? Okay, add the back in red. Yeah, I can use the boxes but I'm really bad at throwing it. Yeah, can you run it back? I don't want to rear end my talk by breaking someone's glasses or something. Hey. Hi, I'm wondering what would be your suggestion in terms of strategy for progressive decoupling? For example, my team and I are playing with commerce side, so shop. We have a couple of things decoupled, not using view. We are considering it. But I don't know, first thing that comes to my mind is I don't know, product variation, switching, not to use Ajax but maybe switch to view. So back to my question is what about strategy? How to approach progressive decoupling? For example, with commerce sites, what is your experience and suggestion? It's a good question. Something I didn't mention was this was my first time using view of Drupal. I've used it for building SPAs, I've used it for hobbyist stuff but this is the first time I've done it with Drupal. So not by any means an expert. I think you're right in pointing out that the product variation has similarities with the course variations. So I can imagine that a similar approach to what we did here would work. In terms of strategy, perhaps consider building like an MVP, so a sort of prototype. Get one product which has a few variations and then maybe mock up quite a sort of rough and ready, simple looking app. Like I said, the view learning curve is gentle. There's a lot of really good learning resources. You could even just build it in a code pen or something. Maybe I'm not a good strategist, but I think maybe start with a sort of simple reduced case like that and then if you feel like it's great, if you really like it, you can look at doing it in Drupal. It's probably not the best possible answer, but I guess the advice is just to try it. Thanks. Yeah, just really one more. We are over, so feel free to go. But I think someone's waiting. I have a question about search and filtering for courses. On university pages on course catalogs, one of important features is searching. Question is, do you use search and filtering using Drupal filters or view functions? Okay, yeah, good question. So this piece of work was covering the course pages themselves. We had some other work, which was the course search functionality. We're not actually using Vue for that yet. We could do. I know some of the universities have really nice real-time searches. If you're interested in that, I think Algolia are really, really good at JavaScript-based search and they interact with Vue well. I know that their team uses it. But in our case, the course search is a search API of solar, which runs off the Drupal data. It's got facets, but they're handled by Drupal behaviors rather than Vue. But there's an area there to potentially look at improving in the future. Great, thank you very much. Don't forget to come to contribution and to leave your session feedback. Thanks a lot, guys.