Episode Details

Hello again. Uh, this is a serial episode, so I'm recording this one second after I just recorded the last one. So the last episode, we talked about these hard validation problems, and hopefully I illustrated to you some of the issues that really STEM from a difference that I wasn't aware of that I wasn't really, that I hadn't formalized, but I cleared up the difference that there's two types of valid two types of things people are trying to do in an app.

Then I was able to solve it. When I separated out into two separate methods, validate and validate only, and I think it's going to be intuitive. I'm going to document it up and I think everybody is just going to think it. Uh, it works the way it should work and I'm, I'm so happy with it. Half. So happy with it.

Like I finally, this has been. Something nagging in the back of my mind that's not perfect. And now in my mind, it's perfect in my mind. Maybe it's not in reality, but I think it's perfect. So I'm putting it to bed, um, and I can move on with my life. Uh, but this brings me to a bit of a bigger discussion.

Um. This problem I, there's two ways I could have approached this. So, you know, the way I did approach it, um, I also could have approached it a different way, which is actually how I started approaching it. I. You get an a get hub issue where somebody says, Hey, it would be cool if the validation persisted from request to request, you know?

Oh, yeah, yeah. Okay. We should make that available. Well, how do we do that? Maybe we'll add a config option. Maybe we'll add someone. How would we configure that ability? Okay, well, what if we have a trait called persists validation that maybe you just add used, persists validation. We document it.

Okay. Right, right. So that's fine. And I actually started that way. I actually have a trait in a sample app called persist validation that I was messing with, and then, okay, that real time validation, they want maybe have a thing called persist validation and only validates specific fields or whatever.

Okay. Maybe we have used real time validation, whatever. You just keep adding in these options. That describe the functionality, but they don't describe the use case. Um, and this was the road I was starting down, but it felt fuzzy to me, and I just hate adding more documentation for specific functionality that you have to now understand and know you have to understand everything that I understand and, and it's hard for me to understand this stuff.

So why would I burden every user with that? So basically I had a choice. And I've had this choice a hundred times in Livewire, and every time I come across this choice, I don't realize it. It is that choice right away. But when I do realize that it's a choice between an invisible feature and a visible feature, and by that I mean an invisible feature is something that user will never notice.

A visible feature is like them looking up how to do a specific thing and adding a trait and whatever. Once I realized that it's, that, that, that, uh, that fork in the road, I just. Choose the invisible, the invisibility route. I just go with the invisible. Um, and that, that's been my path with this whole Livewire thing is like, find the way that people expect it should work, which is so hard.

And it takes like, user testing is super value. Interviewing people, using it yourself, dogfooding it, thinking about it a lot. Um, those are all the things I employ to anticipate how a user. Would expect it to work and then make it work the way they expect it to work. So basically I picture, like I picture a cartoon character, like walking in space and the road is like filling in as they walk, you know, like, it's like.

The road is maybe it's like a brick road and the bricks are floating up from the abyss and just kind of assembling in front of them and maybe their eyes are closed in, they're whistling a happy tune, and they have no idea