transcription.md

Hello, everybody. Welcome back to Vues on Vue. It's been a couple weeks. My name is Steve Edwards. I am the host with the face for radio and the voice for being a mime, but I'm still your host. Flying with me today on my panel, I have Mr. David Neal. How are you doing, David? I'm doing all right. Thanks for having me back on the show. Always good to have you. Always good to have you. For those of you who might not have heard, David is our resident artist who can draw things that I can only dream about, but got his book of dad jokes and does a lot of artist stuff with his presentations. If you want to listen to last week's episode, we talked about that and you can get the skinny there. Hey, folks, this is Charles Maxwood. I've been talking to a whole bunch of people that want to update their resume and find a better job. And I figure, well, why not just share my resume? If you go to topendevs.com slash resume, enter your name and email address, then you'll get a copy of the resume that I use, that I've used through freelancing, through most of my career, as I've kind of refined it and tweaked it to get me the jobs that I want. Like I said, topendevs.com slash resume will get you that. And you can just kind of use the formatting. It comes in word and pages formats, and you can just fill it in from there. Our guest today coming to us from Cairo, Egypt is Mr. Abdelrahman Awad. How are you doing, Abdel? Abdelrahman? Do you go Abdel or Abdelrahman? I would go Abdelrahman. Yeah, I'm good, Steve. Thank you for having me. It is our pleasure. Today, we are here to talk about vValidate, which is something if you're in the view world, you've probably heard of in terms of form validation, which is something that's so easy, a piece of cake in HTML, right? Anyway, before we get into vValidate, why don't you just tell us about yourself, why you're famous, what you do, and so on and so forth? Sure. I'm not sure if I'm famous, but I am from Cairo, Egypt. I started off as a backend engineer. I did a lot of PHP, Laravel, then I moved on to Node.js, naturally, I landed in the frontend world because of that. Then I started trying out new frameworks to learn Angular, some React, but I really liked Vue, and that was Vue 0.12, right before it was first released. Oh, wow. Yeah, I fell in love with it, so I started using it in my projects, and then eventually 1.0 came out. I started creating vValidate around that time because, yeah, I needed something like that. It was really early in the ecosystem then, but maybe I'm getting ahead of myself here. I stayed with frontend ever since, and it's been four years as a frontend engineer now. Right. Do you want to give a shameless plug about where you work and where you use Vue on your day-to-day? Of course. I work in Rasail. It's a company where it's a SaaS app that allows companies to communicate with their customers using WhatsApp. It's an inbox slash campaigns manager slash automations on bots, and it's all with Vue.js. All with Vue.js. All righty. Now, what's interesting, a couple things we'll touch on your history. Interestingly, you started with PHP and Laravel because that's my day-to-day, is I work in a very large Vue app with Laravel, and then I have another project that I do and maintain that uses Laravel with Vue and InertiaJS, if you're familiar with InertiaJS, which is completely awesome. Yeah, I came from a similar world. Now, what's interesting is that most anybody that I've talked to, when they talk about when they came into the Vue ecosystem and started using it, usually it's around at least 2.0. You're the first person I've ever talked to that's using it pre-1.0 or even pre-2.0, but that's quite interesting. You can blame Geoffrey Way for that. He did a course on 0.12. Did he really? Yeah, and I started then, he updated it, and I relearned it again, and here we are. Yeah, I had about almost exactly a year ago, I was able to get on Taylor Otwell, and part of the discussion was about how, at least for me, I started seeing when I would Google issues, as all developers do, what's this bug or how do I do this or that, I was getting a lot of Laracast's forums links, and I was like, okay, why am I seeing all this Vue stuff in Laravel? And so, we've talked about that whole history with Taylor about how his famous tweet about React is a mess, I'm going to try Vue or React is something, I don't remember what it is, and how that got him into the Vue world and how tightly integrated Laravel is with Vue, which to me is awesome. And I know Geoffrey, when Inertia first came out, he did a course on Inertia, and then he ended up converting his whole site to Inertia and then doing more course on Inertia, so that's sort of been fascinating to watch. Did you ever use any other PHP frameworks or CMSs, like WordPress is a real common one for PHP, or is Laravel your real starting point into PHP? I'm not sure if it's a framework, I used something, if I remember correctly, called Smarty, I'm not sure if it's a framework, it's just a templating engine, I think it's SmartyPHP or something. Then I jumped immediately to Laravel 5.0, and it was beta then, but I started learning on Laracast as well. Yes, Smarty has a true, I would say, late 1990s, early 2005 on their website for sure, I recognize it. It's like a 960 grid layout or something like that. It's really old. How did you make that jump from Laravel to Node.js? What was the motivation for that? We mostly wanted to try a few things. We were experimenting with a lot of technologies in my company then called Bayonet. We wanted to try multiple different things like WebSockets, so real-time and stuff like that. Node.js seemed like the better tool to use then for that kind of applications. Also, we wanted to try NoSQL, so MongoDB went really well with Node.js, so it's just an experiment. We tested a few things, and we really liked the results with Node.js, although we used Express, there wasn't really a framework like Laravel that helps you stitch things together like Laravel does, so it was really hard to ship applications with it, but it was mostly experiments. But I liked JavaScript because of that, because of Node, because of how it seemed to work. Are you still using Express or are you using some other backend system today? I don't write a lot of backend Node.js applications at the moment, but when I do, I use Nitro, which is a new-ish kind of framework. It's really nice. I used NestJS before it, but it's mostly Express or Nitro because I don't write a lot of backend, not production-ready stuff. I know Nuxt has something called Nitro in it. I'm guessing that's different? It's the same one. It's the same framework that's powering Nuxt. So Nuxt is built on Nitro, and Nitro you can use on its own. Oh, it's a standalone tool. Okay, I see. So is it similar to Express in terms of that API layer? It's way better because it does some kind of, you know how Nuxt pages thing work, where you generate files based on the pages directory. Nitro does the same for your API endpoints. So you just create a file and that's your endpoint. Oh, okay, gotcha. Yeah, it's really cool. Yeah, I remember when Node was sort of becoming a thing, or at least when I was becoming aware of it, or in Mongo in particular, I was in the Drupal world at the time, and there was a couple people that were really pushing to allow Drupal to use a Mongo type database. And so I started digging in that and Node itself, excuse me, Mongo University had a course on Mongo for Node developers. And so I went through and learned, you know, a little bit of Node and how to query and a lot of the basics and stuff, but never really went down the Node path too much. Now, my day-to-day at my app, GovTribe, we have a huge Mongo database, huge just because the amount of data that we take in that we make available to our users that we host on Atlas. So it's been interesting. They're sort of combined these different worlds in that from Laravel up until a few months ago, a guy named Jen Seegers maintained the MongoDB integration for Laravel to Mongo, Jen Seegers, MongoDB. And then, so it was really getting a lot of use. Well, then he wasn't keeping up with it. Things weren't getting committed and changed. And so the Laravel community took over that library. And so now it's MongoDB, Laravel instead of the Jen Seegers, and then they've made some changes. And I've actually been wrestling with some Laravel 10 upgrades in Mongo for the past couple of weeks. So yeah, that's interesting. Mongo certainly has it, and that's a whole different topic that we've talked about elsewhere. Mongo has its use cases. In some cases, it's good. In other cases, it's not so good. You know, if you use it, when you have more dynamic database structure needs, then it's definitely better than SQL. But anyway, cool. So 0.2. So let's talk about VValidate then. It sounds like the way you were describing it, that it was sort of a scratch your own itch, right? You've got a need. You're tired of messing around with HTML forms and form validation and so on and so forth. So you decide to write this and put it out there. So tell me how that all started. Okay. So at the beginning with the Vue community, it wasn't really big then, so it lacked a lot of what you would expect from an ecosystem, right? It lacked localization, it lacked forms, it lacked a bunch of things, but everybody was trying to build this kind of community libraries or ecosystem libraries. So there was already a form validation library. I think it was called Vue Validator. Yeah, I've seen that. I have used it and I liked it at the beginning, but I didn't like the way that allowed developers to extend validators and the way that it just didn't feel it felt really unwieldy. So I decided to, okay, I can build my own thing using my own projects. I had no plans to publish it or share it with anybody. It's just a me thing. So I started with a simple JS file that I put in my lot of applications and I decided to give it some syntax similar to a lot of our rules, right? When you have this required pipe, min, colon, eight kind of string expressions for rules. So I decided to give it the same syntax. It seems easier to write, easier to extend, easier to parse and so on. So I built that. It worked well for my small projects. It worked well for my company projects at the time. And then I decided to give it a go and publish it, just to make it easier for me to install it on other projects. So I just gave it a random name. I didn't really think about it. It used to be, the API used to use a directive, a Vue.js directive. So directives start with the V dash, the directive name. So it's V validate and that's how we split. So that's how it got the name. I didn't really think about it. So I published it and start sharing it in the Alarakast community forums and a lot of related communities, because that's my demographic kind of like, I am a level developer who wants to have this easy way to have real-time phone validation in my projects. So I just shared it with the people who I think would appreciate it the most. And a lot of people liked it. Downloads started going up. A lot of people started on GitHub, so it went really well. And then I guess the moment where it just shot up with popularity is when Taylor Otwell started on GitHub. So then just got better from here. In terms of popularity, people started downloading it. People started using it more. I started getting a lot of issues and yeah, that's how it started. Awesome. So now with any validation, this is strictly front-end validation, right? And if you have a back-end, you're also going to want to do validation on your back-end, because you can't always trust the front-end. Yeah, you can't always trust it. But this gives you at least an easy way to plug into your forms and get some validation. Now, does it also do... I'm sorry, I haven't really looked through all the docs yet, but is it... Can you also do things like, say, auto-formatting of a field? So let's say you have a phone number field and you always want it to be in a certain format based on your locality or an email address or something like that. Does it provide those capabilities as well? So VValidation has changed a lot since... So it used to be a directive, like I said. Then it became a component, headless component. Then it became, right now, the Composition API with Vue 3. So it changed a lot, and the features it offered changed with that. So back then, it was just validation with the directive. With the components, it was still about validation, but it gave you some UX improvements, like you could find some classes, you could find some area attributes, you could track some values. That's about it. But with version 4, which is the current one for Vue 3, Composition API, it does a lot of things. It does value tracking, form handling, submissions, but it doesn't do the formatting or masking because you can really easily do it using another library like Vue. There's a lot of libraries. One of them is Vue Currency Input. You can import it, use your Composition API, and compose the two together. So VValidate Composition API can be composed with the Vue Currency Input, and you get both the Currency Input that is validatable, submittable, and so on. Okay. Yeah, I'm looking at your docs here. Just curiosity, what are you using for your docs? Do you use like Vuetify or something like that? Not Vuetify, but what's the framework, David? Astro. Oh, you're using Astro. Okay, cool. Yeah, I like Astro. I've used that for a static side or two, and it's pretty cool with what it can do. Yeah, it's pretty cool. What's the docs framework built on Vue? I'm brain farting on it now, and I can't think what it was that Evan had released. I'm brain farting here, but you could just plug in. The one for the docs? Yeah. Vietpress, I think. There you go. Vietpress, yeah. Okay, that's what I was thinking it was, but okay. Yeah, so how do you like Astro? Just side note, because I've had Fred shot on here, and then another episode. So we've talked about Astro quite extensively. I think for my use case, which is just static content, it just works amazingly. It's really simple to use. This island architecture makes it really easy to incorporate your favorite framework, so it's Vue.js for me, of course, but it can be confusing at first. It can be weird at first. I would say it's a little bit harder than Nuxt at the beginning, but I really like their... I think I like having more control over my content, how it's generated, how it's being typed. So yeah, I really like that, but Nuxt content is just as great right now. Right. I could switch at any moment. Really? So are you using just straight Tailwind components, or are you using Vue components within... Not Tailwind, I'm sorry. Astro components. Yeah, I'm using a bunch of Astro components, but mostly for the static stuff, like the site header, site footer, just simple components. Well, I guess the article cards are... Well, no. With V-Validate... No, that's my blog, sorry. With V-Validate, it's documentation. I don't use a lot of Astro components, like none, almost. It's all Vue components. I'm curious, as your open source project has evolved over time with the different versions and iterations that you've gone through, what's been some of the challenges and most difficult parts of maintaining this project? There is a lot of learnings here, but I guess I'll start from what I learned first, and then I go to what I learned last. So what I learned first is you can't satisfy everybody. At the beginning, I was really excited. My project got some attention, it got some spotlight, so I need to make as many people as happy as possible. So when everybody wanted a feature, it was like, it would be cool if we can do this. And I was like, you got it, and just implement it the next day. And I kept doing that for a very long time, and I ended up with a really messy API, because when I started writing, I didn't have documentation at first, it was just a README, so I decided, yeah, it should have a documentation. And when I started writing documentation, I started to see how messy the API was. You could do this thing in five different ways, and none of them is kind of perfect. It's really hard to write documentation, especially if it's really easy if you are the one who is writing the library, but at the same time, it's hard if you are trying to explain it to somebody else, because, okay, in what way I want them to write this API or this feature that they should be implementing. So that's the first thing. Don't do everything. You shouldn't even try to do everything. You should have a clear direction of what the library should be, and what to say no to, and what to consider. So I learned that after version two, so I started doing that with version three. And with version four, I'm even more aggressive with it in terms of people asking for something and telling them, no, we aren't doing that, and just rejecting it. For a lot of things, we can just spark it like it's an enhancement, so it needs some thinking. I can't just say, okay, let's implement the first thing that comes to my mind, but no, that shouldn't work like that. So that's, I guess, my first lesson. Second is people really hate breaking changes. So shocking. Yeah, like they absolutely hate it with a passion, like we validate change a lot, like a lot across releases. So v2 to v3, that's the directive gone. That's the main way of using the library. It's completely changed. With v3 to v4, it's also completely changed, because we now encourage the composition API more, and the API is widely different. And the reasons are, it's not like I wanted to do that. Sometimes it's outside of my control. For example, during the transition from v1 to v2, the directives are no longer instance-based. So that means I couldn't store data on a directive instance. So that means I can't use a directive to maintain a field state. So that meant the API had to change, and we ended up with a much better pattern with headless components. But then came the composition API, which is similar to React hooks, which is a better pattern for headless or provider patterns or that kind of functionality. So and also some internal change, it made the old API impossible to implement. So that's another breaking change. But people don't understand that or try to acknowledge that all they care about is whether it's a migration guide or why is this not working the way it was before. And I met a lot of enemies. Like I didn't think you can make enemies. Yeah, I got a lot of like angry messages. So that's interesting. But I kind of understand it's a huge change. But at the same time, it's hard when you're making a library or maintaining an API, and then you recognize something that you shipped. Okay, I made a mistake with this. I want to change it now. So not a lot of people can rely on it, you know. But then if you kind of deprecate it, it's a breaking change. So yeah, it's a tricky balance. Respecting semantic versioning has been really important for this project. But I don't follow it to the letter. Like sometimes I would introduce a breaking change just because it's causing too much DX issues. A lot of people are complaining about it. So I would just introduce a breaking change, put it in a change log, and it's worked well for this project so far. But it's not something I would recommend for every other project. So, yeah, I think these are my e-learnings. What have you learned about involving other people in the open source? And, you know, do you have like more folks that you can rely on to help implement features or do reviews or, you know, have you been able to share some of the load and responsibility as the project has matured? Yeah, I guess I forgot about saying that as a learning. Like it's hard to foster a community around the library. Building a core team is extremely hard. So far, I'm the only guy that's been constantly on the project. During times I had some people be around for a month or two before jumping off. I'm not sure what I should be doing. It's a hard thing. People are interested in the project. They keep contributing to it. And a lot of them, once they got the features they wanted in, they simply didn't continue contributing. I tried to create an organization, invited a few people that were active in the library, but they said they don't want the they don't want to be tasked with maintaining the library. They want to be doing it whenever they can. And they want this freedom of source. They don't want the responsibility. Exactly. So I failed completely in that regard in fostering a community around it. And yeah, I'm the only guy working on it actively at the moment. But I do appreciate every single contribution that comes in. Yeah, I was looking at the GitHub repo, and it looks like a lot of people have contributed to pull requests or bug fixes or whatever, or feature ideas. So that's great to see. I wonder, just curious, how have you maintained energy and motivation to continue working on the project if it's pretty much just you doing it? Hey, have you heard about our book club? I keep hearing from people who have heard about the book club. I'd love to see you there this month. We are talking about Docker Deep Dive. That's the book we're reading. It's by Nigel Polson. And we're going to be talking about all things Docker, just how it works, how to set it up on your machine, how to go about taking advantage of all the things it offers, and using it as a dev tool to make sure that what you're running in production mirrors what you're running on your machine. And it's just one of those tools a lot of people use. We're really looking forward to diving into it. That's February and March. April and May, we're going to be doing the Pragmatic Programmer. And we're going to be talking about all of the kinds of things you should be doing in order to further your career, according to that book. Now, of course, I have my own methodology for these kinds of things. But we're going to be able to dovetail a lot of them, because a lot of the ideas really mesh really nicely. So if you're looking for ways to advance your career, you're looking to learn some skills that are going to get you ahead in your career, then definitely come join the book club. You can sign up at topendevs.com slash book club. I think this is going to sound cheesy, but it's because I like it. I like writing code. So after work, I would just open up, v-validate and say, OK, we need to fix this and this. Sometimes I don't have any energy at all during the week. So I would maybe contribute on the weekends only. Sometimes I don't have any energy for an entire month. And sometimes I have like, I'm here in Egypt, you serve in the military for all males serve in the military. So I maintain v-validate during my service in the military, which was really hard because I don't have internet. So I had to visualize what I wanted to do. When I get a vacation for about four days, then I come type it down, pull request it, go back to the military and so on. It's because I like it, I think. It's because I like it. Yeah, I mean, what's interesting listening to you is what you really stated is common knowledge for people who maintain open source libraries. You know, you can't make everybody happy. You got to have a plan. You got to stick to it. It's hard getting contributors. People make assumptions and sort of have, what's the word I'm looking for? They sort of assume that you owe them something as users of your library as compared to the other way around, especially those that, you know, that don't contribute to it. So yeah, it's nothing, nothing too surprising there. And there, you know, as you said, there are users that will contribute, but only when they really need it. You know, I can, you know, just thinking of my own development history at times, I've been using a project or a library or something. And so I'll contribute to it. And then once as my day-to-day, I'm off that, or even on a side project, not using it, then I really don't have any interest of going back and contributing. But it sounds like you've done a pretty good job in terms of a balance. You know, I could see it for me, you know, if I'm working all day on Vue and then I want to go spend my evening hours doing some more Vue, that can lead to some pretty bad burnout. So, you know, striking a good balance, you know, work-life balance is definitely an important thing. It sounds, you know, if you take off a week here or a month there or something like that, and come back to it, then, hey, great. You can always say, if people are screaming, hey, what about this? And what about that? You can say, hey, patch is welcome. You know, it's always the classic open source phrase. If you want to contribute something, I am more than happy to review it and check it out, but I need some help from you. So, yeah, that's definitely just a common experience across the board that I've heard from open source over the years, over the last, you know, 20 years that I've been involved in open source. What's been something that you feel like is one of the most interesting uses of your library that you maybe came across or heard about or, you know, discovered, you know, that someone was using your code to do something that you wouldn't have imagined? Yeah, that's an amazing question, because I have an exact one case that lives rent-free in my head, because of how mind-blowing it was for me. So, when people come to me and say, well, they are building multi-step forums, they are building, like, this state management form thingy, yeah, this is what I designed the library for. Like, you should be able to do these things, it's impressive and all, but it is possible, like, I can see it happening. But one guy decided to use it on the backend, decided to use it on Node.js, and it works, apparently. I never tried it, I never thought it, like, to even imagine trying it, but apparently it does, it works well for them, so that blew my mind. So, they're doing form validation in Node.js on the backend? Yes, they are using VValidate to validate the requests that are coming from the road to their endpoints, which, yeah, it's possible, but I never imagined it. Interesting. So, they're just using the API, then, obviously. Yes, nothing that's UI-related. Validate function, yeah, validate function, the rule system, and that's what they need, and, yeah, it's definitely possible, but I never considered doing that. Well, I guess it makes sense, I mean, isn't that the whole purpose of isomorphic JavaScript, you know, JavaScript, one language to rule them all, and in the darkness, bind them, to borrow a quote from a famous book. So, that's awesome, you know, it's, yeah, one of the things I've discovered over the years when I put out, you know, a project or an application, one of the benefits of doing, you know, getting testing outside of yourself is, it's amazing the use cases that people will find that you never would have considered in your head, in your limited scope, right, of use, but people, oh, great, I can use it here, this is great. Yeah, sometimes people send me emails about something they are building, and I would jump on a call with them to see what, if it's, like, too interesting, I would just tell them, okay, let's schedule a call, let me see what you are building with it, and I learned a lot from people, watching people use the library and build with it, and it definitely influenced my decisions moving forward, like, okay, this API doesn't feel, need some adjustments, because they used it pretty horribly, because it forced them to be used pretty horribly, so, yeah. Is there a project or story of someone using your component that you're, like, really proud to be associated with, that they feel good about having contributed to some project? Like, famous apps or projects, there is a lot, so there's this app called Vue Telescope, it's built by the Nuxt team, and you basically can search if any app in the world is using a certain Vue library, and when I looked through it using Vue Validator, I saw all kinds of crazy, like, I wouldn't have imagined these companies using it. Can I say some of them, or I'm not sure? I don't know, if they're available in Vue Telescope, they're certainly public, then. Yes, so Blizzard apparently is using it in their account pages, and I verified that, I reached out to them, they didn't reply, so. There is also, I think, Hyundai India or something, so a bunch of, there is a lot of big projects using Vue Validator, so using Vue Telescope, I can't remember what, there is a lot of big names there, but I don't remember a lot of them, just that Blizzard, because I like their games, so. Yeah, yeah, that's cool. So you had mentioned, I wanted to, there was one technical thing I wanted to ask you about, just in terms of composition API, so one of the things you had mentioned was, you had to go away from directives because you couldn't save state, I believe, or something like that within it, so now you can do that with the composition API, correct? Use a composable, because you can store state within a composable? Yes, so the way it evolved is, since you no longer had state with directives, then the next best thing is components, that's version 3, with Vue Validator version 3, but then we got the, but that was just a hack around not being able to be able to have reactive data that's associated from components, but that's possible now with the composition API, so it kind of also evolved to using that composition API instead of components to drive this functionality. It makes it much easier to integrate into your components than, say, a headless component, and it's true of the same thing in the React world, like certain hooks or certain functionalities are easier to build using hooks or custom hooks than with headless components because of how the whole slots thing works, if you are using a headless Vue component or even a headful Vue component, and you have like slot props and you want to use, you couldn't move these slot props to the script deck, so you had no control over them, you had to make some nasty hacks to make it work, but that's like, the slot props wasn't really meant for mutating stuff, it's mostly meant for reading stuff, so with the composition API, that's all, I think, solved, so you can compose this validation logic, this value tracking logic, submission logic into your component, and it should just work, so that's why it changed a lot along with Vue.js available API. So were there any other, so with Vue 3, did you have to, was it like a full rewrite of the library? I know like Vue.defy has done that, where they pull a full rewrite to incorporate a lot of the Vue 3 changes, or was it just a few minor changes, or how much did that impact your library? Initially, I thought I was fine, just changing a few bits there, and just keep the headless component, because there is no need to break everything for everyone, right, but then I think Vue alpha release came out, and it just like changed the one thing I was relying on, so I have to explain how Vue 3 used to work, so it worked by checking the V DOM tree, so it checked the slot, and then it starts searching for the V model directive, and once it finds it, then that's the input node, that's what you want to validate, so it worked like that by searching the DOM tree. With Vue 3, it was working until they decided to drop directive names from the V DOM nodes, so I could no longer find the V model directive, which just that it's impossible now to have the same API, so I had to go back to the board and re-plan everything, see what I can do, what I can do, then I experimented with the composition API, and it worked great, and that was the direction it needed to go. I thought about starting another library, since that's a huge change, but there is no point in starting another library, because I would get another questions like, why is this not migrated to Vue 3, so it's the same thing, so forcing everybody to migrate is better than forcing them to move to another library, easier at least. Okay, so I'm still trying to get my head around this, I haven't got quite into the internals as you did, so you were, what did the composition API do that allowed you to get around that problem? You said it would just start using the composition API. Yes, so that's how I like to explain it, so before V-Validate was trying to look for the V model, right? If it can't find the V model, then it can become the V model, so that's what the composition API kind of does for V-Validate, it allows it to provide this reactive reference or riffs, and then that you can use that as your model, instead of creating your own model, and through that, if you change that, then V-Validate knows you changed the value, and then since it owns that state kind of, then it can definitely do validation, do submission, do all kinds of stuff. So you talked about how you're using headless components, is that your current implementation? No, that's the version 3 implementation, version 4 has some headless, yeah, version 4 still have some headless components, just to maintain some form of backward compatibility, but the main way to use V-Validate version 4 is the composition API. Okay, so just for the curious who might not know that, what do you mean by a headless component? It's a component, yeah, it's a component that provides you some functionality, and it doesn't render anything, so there are, I think, a bunch of different kind of definitions for it. Some people call it renderless components, because headless components are now like unstyled components, right? So it's kind of the definitions, like back then, I think I thought of them as headless components, because they don't have any elements to render, they just render whatever you put inside them, inside their slots. So regardless of what they are named, I think the most correct one is renderless components, or provider components. Regardless of that, it's just, so you put your stuff inside its slot, and it offers you the functionality through scoped slots. So scoped slot props are like certain data that passes through your slot, like the value you should bind to, the classes that you can bind to your elements, and various functions like validate, set value, maybe set certain flags like setTouchTrue, stuff like that. But you were using those forwards away, then you can define your state values in there and handle your state management, since you'd lost that, right? Yeah, exactly. The renderless components still works, because it's still the same thing, but the composition is just much better, because I think the main problem was people struggled with the scoped slots, like, okay, I have the value in the template, how can I move it to my script? I want to do some arbitrary logic on that value, like I want to format it, I want to submit it to an API, I want to do various things with it. So that was really almost impossible to do with scoped slots without some really like black magic view, just black magic, like function, and that function captures the reference and weird stuff like that. But that's just a hack, like you shouldn't rely on that. But that's true for all renderless components in Vue.js. It's not something specific to Vue.validate, it's just how this pattern works. You can't move stuff to your script. So the composition API already lives in your script, so you can easily move stuff to the template, because the template uses whatever in your script. That's why it's the better way to do it now. It's why I recommend using it over anything else in the library or the Vue.js ecosystem. So you said version four of Vue.validate corresponds to Vue.3, is that correct? Yes, that's correct. Okay, so do you have a roadmap, or where are you going with that? Anything down the road, or are you just sort of adding things as the need arises? Yeah, exactly like that. I'm just winging it, in a way. I have some long-term goals, like multi-step forms, I need to support it in some capacity. Value masking or formatting, I need to support some form of it, it doesn't have to do the entire thing. So these are long-term goals, I haven't decided how to yet move towards them. But what I'm focusing mostly on is the DX of building forms, like how hard it is or how easy it is to get a form running and hook your stuff to it. Because a lot of libraries started emerging with Vue.3, so each library needs to find this kind of niche audience or a niche way of doing forms. So Vue.validate, I think, is more geared towards those who don't use third-party components. It supports them, you can validate whatever you want with Vue.validate, you can support an empty span or an empty div if you really want to, or Vue.ify components, Quasar components, whatever you really want. But it's not optimized for that, it's mostly optimized for people building their own components, like you are building your own component library with a little bit of the form component library, input text, selects, and stuff like that. So it kind of abstracts a lot of the things related to building forms, like value tracking. You can't really rely on remodeling every single input you have, it's just akin to having a listener on every single input. So that can become hard while building a really large form or a dynamic form. So having a declarative way of saying, okay, this is my field, I want it to be automatically tracked just because I have it in my template. So I think that's something we can discuss first before I go further into this, which is Vue. had always had two schools of thought when it comes to forms. So it had this imperative way of writing forms and declarative way of writing forms. So Vue.validate always lied in the camp of it being declarative. So it means the forms are declared in the template, in the HTML, it doesn't live in the script as other imperative libraries would do. A good example of an imperative library is Vue.validate. But at the same time, Vue.validate is mostly about validating anything, really. So any value, arbitrary values, doesn't have to be related to inputs. But this allows it or prevents it from providing certain abstractions, like is the field touched? Sure. It depends on how it can know that information. Or if the developer can hook up that information to Vue.validate, it becomes harder then. But with a declarative library, it already lives in your template. It has access to your template. You declare the value just by typing the field. So it kind of can track itself, kind of can track all sorts of events. I know it's hard to imagine over just saying it like this. But it's mostly about these two schools of thought, like having template-based forms and imperative-based forms. Now, with composition API, the lines are becoming really blurry because the composition forces you to write stuff into the script and move them to the template, if I may say so. But at the same time, Vue.validate's main optimization or main focus is it allows you to build your own declarative forms through the composition API. So that's how the direction shifted. It's not an imperative library, as in it allows you to validate stuff. It still allows you to build forms. It still allows you to build inputs. But through the composition API, through a declarative API, if you want to make the most out of it. Sorry, I went on long. Oh, no. Not a problem. Not a problem. So now one of the things I was looking at, Daxa, noticing is, and you were just talking about how your forms are generated and stuff, is it looks like you can, one, you can integrate with, was it Formulate, I think it looks like you have some good, which is another library that helps generate your forms. I think it looks like it's your JavaScript, right? You define your forms in JavaScript, and then it renders your form for you. And then you have some pretty good integration with your library so they can validate those forms. Is that a fair statement? Yeah, but that library is discontinued. It's no longer maintained. But it used to work like that. That library allowed you to define forms dynamically using a schema. And then you could have a validation provider that could be Validate or VValidate. So that's how it worked. But unfortunately, it's no longer being worked on. Oh, okay, because you still have it in your docs. And then I think, is that the only option? It looks like you can do it yourself inside with, was it Formulate? I'm looking at your Build a Form Generator section in your docs. Was Formulate the only way to do it? Or can you do it with VValidate as well, just using a schema? VValidate doesn't really give you a way to make it easier for you, like how Formulate used to do. But you can pretty much come up with your own schema and build it with VValidate. Right. Yeah, I used to, my very first foray into working with JavaScript frameworks was with Angular 1. I think what they refer to as AngularJS now. And it was with a platform called FormIO. And that's what they did. It was JavaScript defined form rendering capabilities. And there's all kind of really cool functionality that you could use behind the scene. You could really do some crazy dynamic stuff with forms and with their backend that used Mongo. It was initially just Angular, but then they extrapolated it to make it generic so that you could use anything. But the idea of form rendering based on strictly in JavaScript schemas is pretty cool. A little more complex than just defining your form in your single file component, but it gives you a lot of really neat functionality once you sort of grasp it and get your head around it. All right, so before we move on to pics, is there anything else you wanted to cover about VValidate that we haven't talked about yet? I think just discussing the current ecosystem of the Vue.js form libraries and how it's not like a comparison. It's mostly a summary of what the landscape looks like. So we have three, I think, main libraries right now. VValidate is one of them. We have FormKit and we have Vuelidate. So like I said, VValidate is mostly focused on validating values. It's up to you to hook it up to everything you need to. And then there is FormKit, which is providing you with components that you can style, extend, and they have a wide range of components that make it really easy to build a form with FormKit. Like you drop a bunch of components and that's it, that's your form. But it's more of a component library than a form validation library. So that's because of how they think. I think in a recent talk in Vue.js Conf in the US, they said their philosophy is deciding about forms that can be abstracted. And they think forms should always live in the template. So they are declarative in the same way that VValidate likes declarative forms. But they think that it's hard to abstract certain concepts from forms without inputs or without components. Like you need to have your input. There's a lot of things state related to it. So what's the point of abstracting just the minimal stuff about that without giving you the whole thing or a lot of the things that you might need, like minimum length, maximum length, and other stuff. But for VValidate, I think that's my personal opinion. I think having a form component library is the same issue that faces us every time you build a huge app or an app that's meant to last a long time. It's how much can I extend it and how much can I override it. Overriding styles, basically, is an age-old problem of component libraries. Even with headless components or unstyled components, you have to adhere to most of the HTML. And then you are forced to style that structure. You can customize some stuff. You can extend some stuff. But you can't really write something from scratch that freedom takes away from you. Now, VValidate kind of offers you just state. It's up to you how you hook it up. So it kind of optimizes for people building their own components. So if you are someone who is looking to build a component library, then VValidate is going to be a better option than the others. However, if you want to have forms and get up quickly, ship something that's really high quality in a really quick way, then FormKit or other libraries can do it for you. Hey, this is Charles Maxwood. I just wanted to talk really briefly about the Top End Devs membership and let you know what we've got coming up this month. So in February, we have a whole bunch of workshops that we're providing to members. You can go sign up at topendevs.com slash sign up. If you do, you're going to get access to our book club. We're reading Docker Deep Dive. And we're going to be going into Docker and how to use it and things like that. We also have workshops on the following topics. And I'm just going to dive in and talk about what they are real quick. First, it's how to negotiate a raise. I've talked to a lot of people that they're not necessarily keen on leaving their job, but at the same time, they also want to make more money. And so we're going to talk about the different ways that you can approach talking to your boss or HR or whoever about getting that raise that you want and having it support the lifestyle you want. That one's going to be on February 7th, February 9th, we're going to have a career freedom mastermind. Basically, you show up, you talk about what's holding you back, what you dream about doing in your career, all of that kind of stuff. And then we're going to actually brainstorm together, you and whoever else is there. And I, all of us are going to brainstorm on how you can get ahead. The next week on the 14th, we're going to talk about how to grow from junior developer to senior developer, the kinds of things you need to be doing, how to do them, that kind of a thing. On the 16th, we're going to do a Visual Studio or VS Code tips and tricks. On the 21st, we're going to talk about how to build a software course. And on the 23rd, we're going to talk about how to go freelance. And then finally, on February 28th, we're going to talk about how to set up a YouTube channel. So those are the meetups that we're going to have along with the book club. And I hope to see you there. That's going to be at top end devs.com slash sign up. All right. So with that, we'll move to picks. Picks are the part of the show where we get to talk about anything we want to talk about within reason that's not going to get us kicked off by the FCC or something like that. Not that they monitor podcasts. I will go first with the what I like to refer to as the dad jokes of the week, the high point of every episode. And still missing my sound effects. Got to get off my rear and get those figured out because without the rim shots, it's just not the same. But just do your best to imagine the rim shot in your head when I say a great joke. So my son asked if I was named after my dad. And I said, well, of course I was. He was born many years before me. You know, named after. So. Oh, good. Thank you. Thank you. And then I was making a cake the other day and my wife asked me why I put it in the oven upside down. I said, well, I was just following the instructions. It said that it should go into the oven at 180 degrees. I suppose I could have turned it to the side instead of upside down and it would have been the same. But that was how I was thinking. And then finally, people say they pick their nose, but I feel like I was born with mine. Anyway, that's it. David, do you have any picks for us today? Oh, I do have a timely joke from like, you know, the holidays here in the US, you know, with Thanksgiving and Christmas coming up. So there's a, how does a gingerbread man make his bed? I've heard this, but I do not recall. With a cookie sheet. Very good. Very good. I will tell my son that one. He'll love that one. You'll love that one. Thank you. It's always good to have people add to the joke repertoire on our show. All right. What do you have for us? Well, I don't really have any dad jokes. That's okay. We all can't be perfect. So I think, I guess I recently went to Europe for the first time in my life. I went to give a talk in Berlin and then to Italy to give another talk there. So it was, it's my first time outside Egypt, kind of like I went to other countries, but outside that part of the world, you know, so it was really an amazing experience because I think like you said before the show, I didn't get to experience it as a tourist. I experienced it as someone who, you know, I landed on a plane, figure out how to move, how to go to the destination and without having, luckily I had some friends there who helped me figure things out, especially the public transportation system in Berlin, which it's words, but I fell in love with it. It's amazing. Like it's really amazing. Yeah. Is it mostly like trains, subways or buses or all of that? Almost everything. Like you, if I missed my bus, there is a train on the other side of the street. If I miss that train, then I go back to the bus and it's all five minutes away from each other in terms of timing. So I don't have to wait a lot. And the Google maps integration is just amazing. Like, I'm not sure if you, like it's for us or for from my part of the world, it's non-existent as public transportation is almost non-existent. You kind of have to know it to, to know how it works. But as someone who's, you know, a strange man in a strange land, you know, you kind of just open Google maps. And then I was like, I want to get there. And it's like, okay, just get on that bus. That's going to be in front of you in two minutes. And in two minutes in front of me, no delays. And if there was some delays sometimes, but the app said there is a delay because of a medical emergency. So it's three minutes late and it's then on time. So it was amazing. Awesome. For Italy, it was just the food, which is amazing. There you go. Yeah, we have, I have, that's one thing I'd love to experience is, is the food, actually Italian food in Italy. You know, I, I'm a Spanish speaker and grew up learning Spanish and, and, you know, Mexican food is quite prevalent here in the U S to varying levels of quality and authenticity. And so I had always, you know, I've always had Mexican food tacos and burritos and my famous favorite food had always been a chili relleno. And so I'd always liked that here. And then when I went to Mexico, I had a real chili relleno and it wasn't some little flat thing. It was like a big, you know, chili relleno was like, Oh my gosh, that's what they're supposed to be like. So and I was, I lived down there for a few months and, you know, lived in a house with a family and stuff. So got to experience quite a bit of non-touristy food. And ever since then, when I've come back, I've always differentiated between American Mexican food and real Mexican food. And it's not too often that I see a lot of the authentic stuff up here. Like I do. It's funny. I found one place that made a chili relleno like the one I had in Mexico and David, you'll, you'll understand this a little better than Abdelrahman, but it was in a small town in Tennessee. Um, you know, it wasn't anywhere down by the border. It was, I can't remember the name of the town. It was years ago, but I was struck. I was like, Oh, this is a great place. I just happened to be there on business. But yeah, I know like you're, you know, and you can tell me if this is true out there. Um, pizza, you know, here we have pizza, we've got pizza joints and pizza restaurants and you go anything from, you know, your thin crust pizza, something like a pizza hut to your custom places to Chicago where you have quote unquote deep dish pizza, which was really thick. Um, now my understanding from what I've heard from people who've been to Italy and had real pizzas that it's very different, you know, it's, it's pretty thin crust. It's not this whole thick crust thing with injecting stuff into the crust, you know, and stuff like that. Is that correct? Yeah, absolutely. It was a thin, really thin. Um, it was kinda like, I expected more, you know, like I had pizza in it. I went to the first place of pizza. I'm going to have the mother of all pizzas, you know, like that kind of, but I just had really good pizzas, but yeah, I would be considered a heretic because I, my favorite pizza is what I call pine and swine, which is Canadian bacon and pineapple. And I'm, I'm gonna, you know, people will call me heretics for, for liking that, but I'm going to assume they didn't have that, those kinds of toppings in Italy, right? Never found them. Maybe we'll get like, I think people told me you will get kicked out for asking. There is a pizza like this. Why do you insult my food? Right. I could totally, what kind of topping, what kind of things did you have on, on your pizza when you were there? Uh, it was mostly cheese. Uh, and, uh, I think it's margarita cheese, uh, or a bunch of other types of cheese. And then I had, uh, there was this really weird small shop near my hotel, which I mean, weird as in weird pizzas, they had this square pizzas, not circular. And you can ask for, yes. And you ask for how much you can slice from that big square pizza. So you kind of have like a mix of multiple pizzas with multiple flavors, multiple toppings, multiple everything. So I had a pizza was like cucumber on it. It was really weird. It was, it was good. Uh, if, uh, there was this potato pizza and there was this, I can't remember what it was, but they were all fantastic, but no fruits allowed on pizzas there apparently. So, oh boy, that sounds good. And here me thinking, I thought pizzas always had to be around. I'm, I'm shocked that they would use another shape for sure. Do they do like meats, you know, like we always have pepperoni or have a lot of meats, but because I can't eat pork meat, so they kind of have, uh, I kind of had to avoid them. So chicken, uh, beef, if they had it, but yeah, a lot of pork meat. Right. Interesting. Oh, so I want to try that sometime. All right. Well, enough talking about food. I'm really hungry. It's lunchtime and I'm past my lunch. So this has not helped, but, uh, anyway, thank you for coming on. I'm there. I mean, it's, uh, it was good to finally be able to get you on. I know we were scheduled a while ago, but you, you got sick. If I remember correctly as quite a bit, I'm sorry about that. No, no, it's not your, not your fault. It's good that we finally got you on to talk about the V-Validate for sure. I know it's something I've looked at and haven't actually used before, uh, but, uh, definitely have to give it a try. Um, thank you, David, for joining us, uh, for the addition of the jokes. It's always makes the show better and we'll say goodbye for now and talk to you next time on views on view.