معلومات عن هذه الحلقة
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 that if the road stops building itself, they'll fall to their death. But it's just magically happening as they go.
I think that's the, the, and now I literally just came up with that right now. Um, it's pretty off the wall, but, uh, I think it's actually kind of. I think it's kind of accurate. That's what I want Livewire to be. I want it to be a road that assembles in front of you and you have no idea. You think you're just walking and whistling and happy tune.
But underneath the hood there's like crazy stuff happening, you know, to make this happen. Um, and from an implementation perspective, I tend towards the simple implementation. I tend towards wanting it to be a simple tool with a bare set of, that's another balance. I'm, everything in life is balances, but that's another balance that competes with this value of invisibility.
The value of a simple implementation, a simple set of tools that the user understands and can manipulate. I think of it kind of like the react versus view dichotomy where VJs has a lot of, um, it has a wider API because it caters to specific use cases with specific API APIs where react is more like a bare set of tools.
And for those use cases, you can use a, that set of tools to accomplish what you need to accomplish. Um, and certain people like. There's differences in both of them, and there's different things to like with view. It might cater to specific things really well, but because you don't, I actually think that this, this is not an all encompassing.
This is a reduction of view in react. I'm just saying that, but let's just go with the metaphor and let's just, uh, um, turn these two tools into characatures with view. With a wider API that is more specific for specific use cases for use cases, it, um, it fits the needs really well for those things.
But then when there's needs outside of it, you feel like you're hacking something, um, or you're doing something that's unintended because it's more opinionated, where react is less opinionated and it's more of a bare bones set of tools. You, uh, when you, it has a slimmer API, so you have to employ more mojo to figure out how to do something and you run the risk of doing it in a not ideal way because.
You don't understand it that well, the learning curve is higher, but when you run across something that you don't know how it solves you, you pretty much already do that for everything else. So you'll feel okay, you know, I'm mixing and matching techniques to get the job done. Okay, so that's a competing, those are competing values.
This like, I want to, I want live wear to feel invisible. And also I want live where to fear, feel like a bare bones set of tools that's implemented in a simple way and is a transparent tool. I think that, and that's where react is moving towards with this hooks thing. This like a, you know, this hooks reveal the nature, the true nature of react or whatever, and it.
Totally steepen the learning curve and a lot of people, it just kind of boggles their mind. Um, it's very confusing. They use effect hook specifically. Um, and it's something in that people talk about a lot. And this, I think this is an example of like maybe Dan AB off and I, I don't know that much about react.
So again, just go with the metaphor or analogy. So like Dan Habermas was saying, well, I'm going to, let's reveal what, let's provide an API that reveals the way react works. Then. People can use it too. It's two. It's op most optimal. You know, they, you know, I, it makes sense. I understand that temptation.
Um, where I imagine Avenue has a different approach to his tool, um, view. So anyway, so it's a competing thing where I want live, where to feel invisible. I also want it to feel like you understand how it works so that you can mix and match and be creative with it. It's a very, very hard thing to balance, but I'll say that in general, I choose in visibility as much as ...
