Console #144 -- Interview with Abdelrahman of VeeValidate - a Vue.js form library
Featuring DiceBear, Blaze, and VeeValidate
🤝 Sponsor
This space is reserved for sponsors that support us to keep the newsletter going! Want to support Console? Send us a note at osh@codesee.io
🏗️ Projects
Browse through open source projects on OpenSourceHub.io, add your project to get more exposure and connect with other maintainers and contributors!
🧑 DiceBear
DiceBear is an avatar library for designers and developers. With DiceBear you can create awesome avatars for your project in no time.
language: TypeScript stars: 5524 last commit: yesterday
repo: github.com/dicebear/dicebear
site: dicebear.com
⚡ Blaze
Blaze is a file sharing progressive web app that allows users to transfer files between multiple devices.
language: JavaScript stars:1632 last commit: Jan 3
repo: github.com/blenderskool/blaze
site: blaze.vercel.app
✅ VeeValidate
VeeValidate is the most popular Vue.js form library. It takes care of value tracking, validation, errors, submissions and more.
language: TypeScript stars: 9538 last commit: 3 days
repo: github.com/logaretm/vee-validate
site: vee-validate.logaretm.com/v4
Join thousands of other open-source enthusiasts and developers in the Open Source Hub Discord server to continue the discussion on the projects in this week's email!
🎙️ Interview With Abdelrahman of VeeValidate
Hey Abdelrahma! Thanks for joining us! Let us start with your background.
Hi, I’m from Egypt and I have worked for Baianat and Robusta. I started learning programming during college, I started with the classics C and C++ then I moved to C#.
Shortly after I was doing some PHP, Laravel and then jumped to the Node.js ecosystem, during which I started writing more frontend with a few frameworks mainly Angular.js.
I eventually loved Vue.js during its alpha release and stuck with it ever since. I eventually shifted my focus to be mostly frontend now doing TypeScript, Vue.js, Nuxt.js, TailwindCSS.
From time to time I try some other languages like Rust but am not focused on it.
Who or what are your biggest influences as a developer?
I loved Laravel and still do as it was both the beginning of my professional career and at the same time introduced me to a lot of ecosystems especially Vue.js which is my main thing right now.
I would say Taylor and the people behind me inspired me as a developer to build “fluent” APIs that were convenient and intuitive for everybody to use. Right now there are too many influences to name but that’s the very first and the one that had the biggest impact on my thinking as a developer.
What's an opinion you have that most people don't agree with?
I hate the MCU. But if we talk code. I think people should stop using React :p
What is your favorite software tool?
VSCode by far, I jumped editors a lot in the past but VSCode while I jumped off it a few times when it was still new but I always came back and found it better every time until it became a permanent and invaluable tool.
If I gave you $10 million to invest in one thing right now, where would you put it?
Definitely, some emerging AI companies will be hard to pick legit ones during all this hype. If not tech, then maybe real state.
Why was VeeValidate started?
Back then I was a backend developer using Larvel, but I was just getting deep into the frontend territory with Vue.js. The first problem that kind of presented itself to me was form validation. I needed a client-side form validation library for Vue.js and there was already a good one called “vue-validator” or something like that.
However, it didn’t click for me for a few reasons and I decided to build my own for my own use. I could bake in some of the Laravel familiarness that I loved and enjoyed with its validation framework. Apparently, that was a good idea and made it easy to popularize among people who were in the same shoes as mine at that time. A significant boost to its popularity was when Taylor Otwell (Creator of Laravel) starred it on GitHub which prompted many people to try it, later on, it was covered in talks/tutorials by various people and that was it.
It is now very different from when it started, but I think that the path of any library becoming more familiar with the needs it needs to solve and maturing in that regard.
How does VeeValidate work?
This is hard to answer since each release changed how vee-validate worked significantly. But I will try to summarise.
In v1 and v2, vee-validate was a Vue.js directive. To use it you needed to have `v-validate` directive/attribute added to your elements and that was it. It worked by creating JS classes representing fields and attaching listeners on the element it was on to update the validation state as the value changed.
In v3, vee-validate made a huge change to drop the directive syntax and adopt higher-order components as it was a better abstraction and an opportunity for vee-validate to do more than just validation. It worked by having 2 provider components, one for forms and one for fields and having a communication layer between them to aggregate and validate forms in a declarative style and manner.
It also had auto-input detection strategy where it traverses the VDOM and finds whatever nodes that had `v-model` on it.
Finally in v4, it was changed significantly and built upon the new composition API introduced in Vue 3. Mainly because the old detection logic doesn’t work reliably anymore in Vue 3 and because it had inherit problems with detecting the wrong components/elements as inputs. Now it uses a heavy inspiration from another excellent form library called Formik which is on the React ecosystem side.
Now it offers you the same concepts of a field and a form contexts that you can either declare with functions or components. And that transition allowed vee-validate to do so much more that it couldn’t do with the previous iterations.
Where did the name for VeeValidate come from? Why not VueValidate?
After I was satisfied with the initial release features, I still had no name for it. And I thought since it was a directive called “v-validate”. So why not just spell it, and there “vee-validate” as a name was chosen.
Sometimes I regret having that name since it doesn’t relate to how it works now or what it offers, but I guess it was too late to change it by the time I realized the other stuff it needed to do.
Are there any overarching goals of VeeValidate that drive design or implementation? If so, what trade-offs have been made in VeeValidate as a consequence of these goals?
Talking about v4, yes there are a few goals that I have in mind:
Offer the best TypeScript integration possible in the Vue.js ecosystem.
Offer the best DX in the Vue.js ecosystem.
Transition vee-validate to be a form toolkit offering primitives and heavy lifting for all form-things needs.
The first two definitely sound generic, but they did affect the design heavily. First off, everything is written into TypeScript, nothing is left to chance with very minor exceptions. At the same time, goal #2 meant that it can’t be too strict or it is more difficult to use. But I believe there is a line where both aren’t compromised. It also means that DevTools integration needs to be introduced and while it is far from perfect at the moment it offers a new way of debugging forms that weren’t there before in the Vue.js ecosystem.
The third one is the trickiest by far, since v4 came out it was not backward compatible nor it had the same feature sets the previous versions had. But in truth, it can do a lot more as a result of this. This goal meant I had to strip out all features that can be easily done in user-land while at the same time leaving the door open for more flexible solutions and having very aggressive scoping and dealing with feature requests. I think it is a true representation of “less is more”.
As a result of these decisions, it may have turned some people off from v4 but I think the library is more mature and flexible than ever and if you are willing to relearn the new API and its features then I believe you will see that as well.
What is the most challenging problem that’s been solved in VeeValidate, so far?
To keep it short, in the current release of vee-validate I have a few tricky problems. By far the hardest is the field arrays.
Field arrays are not fields that have an array as a value (although they expressed that). They are fields that exist in a repeatable context. So let’s call them “repeatable fields”.
While building an abstraction for them I got into all sorts of edge cases. For example, when you remove one field from a repeatable set, all the next items are effectively swapping their entire state with the one before them. So item 4 becomes item 3 and item 3 becomes item 2 and that cascade effect is one aspect of them. I can say that I’ve reached a very good stable abstraction for them but there are still some bugs to iron out. If you want to see the magic, it happens here.
Another hard problem that I can never explain is race conditions, like all the time.
Are there any projects similar to VeeValidate? If so, what were they lacking that made you consider building something new?
Starting off in 2016 there was only one project and while it was great, I wanted to have something more intuitive/easier to use.
Now the ecosystem is filled with a lot of great other libraries and while each has its own philosophy for tackling the forms problem.
I might be biased, but I think none offers what vee-validate offers when you really make the most of it.
What was the most surprising thing you learned while working on VeeValidate?
All sorts of things, not only do you get to learn more about your favorite framework (Vue.js) and how a lot of its internals work. But you also learn a lot about how other people build forms and how they submit/track/validate them.
Is VeeValidate intended to eventually be monetized?
I do not have plans for doing that. I’m on GitHub sponsors though, so I would appreciate it if people would sponsor it on GitHub.
What are you most proud of?
First of all, vee-validate is almost reaching 2M downloads per month and while that is an inflated metric, I cannot believe how many people are really using it.
I started the library with just the enthusiasm to give back to open-source and see my work judged, and I would say all those payless hours paid off because it exposed me to the great Vue.js community and people from all over the world, and it helped me land a few jobs and more opportunities than I would have normally had and naturally the recognition.
It made me a better developer as well and exposed me to really weird use-cases. For instance, there is this one person that decided to use vee-validate in their Node.js backend. If they are reading this interview, I would like them to know that they live rent-free in my head.
Also waiting for the moment vee-validate hits 10k stars on GitHub. They might mention it in a tweet, no?
How do you balance your work on open-source with your day job and other responsibilities?
In truth, I’m not sure if I am.
I work at Rasayel and enjoy my job a lot there but it is very tiring to go all day doing code and then later open-source in the evening. I did a lot of that and it drained a lot of my energy. But to have a semblance of sustainability here, I do the following:
Check issues on GitHub and tag/prioritize them and respond to questions/discussions. For around an hour a day during workdays.
Fix urgent issues during weekends
Of course, sometimes I break this routine when I have some big project coming up for a new release or a new exciting feature. Then all balance goes out of the window to be able to deliver.
Have you ever experienced burnout? How did you deal with it?
A few times during the journey since 2016. I would count about 2 times that I just couldn’t look at open-source code. I had major downtime during those to recharge.
While I’m unsure of the reason, I recognized that feeling and just didn’t force myself to do anything I didn’t want to. Eventually, it passed and I was back at it again.
Where do you see the project heading next?
The project currently is mostly stable but I have a few nice features that would complete vee-validate as a form solution for Vue.js.
I plan to introduce some abstractions for multi-step forms and value masking and a whole lot of DX improvements built around the VueJS Devtools and quality of life for TypeScript users.
After those, I’m sure I will come up with more but I may start tweaking some of the decisions that I made for v4 to refine the experience more in v5 and beyond.
What motivates you to continue contributing to VeeValidate?
Other than the joy of seeing people use my work and validate it, not much. I won’t say that’s enough because my motivation did dwindle over the years. Do you know what could motivate me more? Sponsors. I wish someday I could do open-source full-time but that doesn’t look in the near future for me.
Are there any other projects besides VeeValidate that you’re working on?
I’m working on `villus` which is a tiny GraphQL library. It felt necessary to have a similar library in the Vue ecosystem as a lighter/simpler choice for folks who don’t like to have their app bundle size inflated by apollo’s ecosystem.
Where do you see software development heading next?
To focus on my discipline. It is hard to tell where web development is going, for a very long time I believed PWAs are going to be the next big thing but they just sort of didn’t. At the very least the adoption didn’t meet the hype. And I guess we just saw how Web 3 took off to the moon but with no passengers. So I don’t know.
I can tell you one thing for sure, a lot of AIs will be integrated into many web SaaS apps in the upcoming years.
Where do you see open-source heading next?
Open source proved that it will be here to stay in the same thank-less capacity that it is in today for a lot of years in the future. But I see a major shift into taking care of DX more than ever and it seems to be the difference maker for a tool/software adoption.
Want to join the conversation about one of the projects featured this week? Drop a comment, or see what others are saying!
Interested in sponsoring the newsletter or know of any cool projects or interesting developers you want us to interview? Reach out at osh@codesee.io or mention us @ConsoleWeekly!