Breaking Vues: v-bind

EPISODE 56

[INTRODUCTION]

[00:00:00] AR: This episode is brought to you by Ionic. For more information, please see ionicframework.com/vue.

[EPISODE]

[00:00:20] AR: Hey, everybody, and welcome to Enjoy the Vue. I’m Alex. Today on our panel, we have Ari.

[00:00:27] AC: Hello.

[00:00:28] AR: Tessa.

[00:00:29] T: Hi.

[00:00:30] AR: Ben.

[00:00:31] BH: Hello.

[00:00:32] AR: And that's everybody. Hey, everybody.

[00:00:37] T: Hi.

[00:00:38] AR: Hi. Today, I have a question because I do that. I have questions. Sometimes, I’m kind of embarrassed about it but I’m going to ask. Could somebody explain to me a little bit about v-bind? Ben?

[00:00:54] BH: All right. I’ll kick it off. For those who are new to the Vue ecosystem, v-bind refers to a directive that's used in Vue. So if you're — I’m looking at Vue code base and you're looking at — in the HTML attributes, you see the, ‘v-’. Those are directives, basically special view magic, and the v-bind allows you to, based on my understanding, basically dynamically swap out values of the attributes. An example might be if you have an image with like a static path, for example, then that would normally just be source equals your double quote and then the path of your URL. But there are times when you want to use JavaScript to swap that out, and so v-bind tells Vue, “Hey. For this attribute, you do v-bind:src,” for example. Evaluate what's in here and swap it out using JavaScript for whatever you want it to be.

[00:01:40] AR: Cool. Okay, that kind of makes sense. Ari, do you have anything that you can maybe add to that at all?

[00:01:46] AC: Yeah. I guess like it's sort of funny because, like, when I think about v-bind, I immediately just think about, “Oh, that's how you pass props in.” But I’m like, “Oh, that's right. You can also dynamically assign attributes. That is a thing, isn't it?” Yeah. I think of it more as passing data down to a child component but, nope, absolutely. It’s how you bind any piece of reactive information from your component into a template.

[00:02:16] AR: Cool. Tessa, you have a look on your face? Do you have anything else that you have thoughts on that at all?

[00:02:22] T: I’m tempted to ask what look it was. But, no, not really. I mean, I think like generally both with v-bind and v-on, you're like, “I’m passing in a JavaScript expression or something that I want to evaluate, rather than being taken at face value.”

[00:02:38] AC: I like that explanation better than mine.

[00:02:41] AR: That makes a lot of sense. Cool. What else do we want to talk about?

[00:02:45] T: Well, how do you use v-binds for those of you who have used it before?

[00:02:50] BH: Yeah. Alex, what is the most common scenario you tend to use v-bind for?

[00:02:53] AR: Well, now that you've explained to me what it is, I think one of the places that I use v-bind the most is applying values to an input and saying, “Hey, here's the value of the input.” It’ll be able to see if I update it in my component that the input updates as well. Ari, how do you use v-bind?

[00:03:15] AC: Well, like I said, most often to pass data from a parent to a child, but I’ve definitely also used it for dynamic links and things like that and sometimes dynamic styles.

[00:03:32] BH: Totally legit.

[00:03:34] AR: That sounds super fancy. Tessa, how do you use v-bind?

[00:03:38] T: I think it's funny because when you first ask the question like, “What do you all think of v-bind,” I realized that a lot of times, just not in practice. But in my mind, when I’m thinking about it, I always conflate v-bind and v-model because it has ‘bind’ in the name. In my head, I’m always like, “Oh. Vue has two-way binding.” Then v-bind, I’m like, “Bam.”

But in practice, the way I use v-bind a lot of the time is if I want to use a value in the template but I know that I want to change it in the foreseeable future. If I have a counter for example and it's at one but I know that I want to make it two. Or if I have something but I know that I want to change it with a method, that's when I would use v-bind. Basically, if I can't depend on something to stay constant, v-bind comes into play.

[00:04:21] AC: I think the real question though is, when you guys are actually using v-bind, do you write out v-bind or do you use colon?

[00:04:30] T: Oh, my gosh. Never, never.

[00:04:32] BH: Depends.

[00:04:34] AC: Ew. No, I’m just kidding. It does depend. There are certain scenarios in which you really can't use the colon.

[00:04:40] T: Yeah. Like binding to add in.

[00:04:41] BH: Yes. Just one scenario in particular.

[00:04:43] T: Just give me colon equals dollar sign adders, Ben. Make it happen.

[00:04:49] AR: I want the walrus operator in Vue so that we can —

[00:04:52] T: I want a colon equals ligature.

[00:04:53] AR: Two eyes and a pair of teeth, and so it's a walrus operator.

[00:04:58] AC: I got it, yeah. I was like, “Wait, walrus operator.” But then you explained the teeth. I was like, “Oh. Equal sign and teeth. Got it.”

[00:05:05] AR: Yeah.

[00:05:05] T: It’s going to be like a regular equal sign but slightly longer. It'll be beautiful.

[00:05:11] BH: Speaking of, so we mentioned about the shorthand. It looks like some of you recognize that there is a limitation on the shorthand. Alex, what is the limitation of using shorthand? Is there —

What's the scenario with v-bind where you need to actually write it out, rather than use the colon?

[00:05:27] AR: The place where you really need to write it out is when you are taking several things that are pieces of data that you want to bind to attributes or props or what have you. And you want to pass that entire object in and say, “Take this object of things and apply them as attributes to this element or component.” In that case, you would use v-bind equals. Then the object that you want, which allows us to do things like passing attributes from a parent component down through to something inside of a child component. Or if you have multiple, like, you have class and style and something else, you can say, “Here’s an object with all of these things. Go put them on this other thing.” Vue will understand, “All right, I will watch this entire object and use that instead.”

[00:06:27] BH: If I’m hearing you correctly, it sounds like v-bind as the longhand is good for when you want to bind multiple properties using a single object, rather than individually declaring each one as its own attribute.

[00:06:41] AR: Yeah. That's probably a smarter way of putting it.

[00:06:43] BH: I don't know it’s smarter. It’s just another way of looking at it.

[00:06:47] AC: I think it's important that we note that when we are saying object, we mean object literal, as in if there are curly braces involved. Not just like if you're passing a prop that happens to be of the type object.

[00:07:01] T: Well, I mean —

[00:07:02] BH: Good clarification.

[00:07:03] T: Nothing in JavaScript is an object, except object literals, right?

[00:07:08] AR: We don't have time to discuss that today, Tessa.

[00:07:10] T: But, yeah, I think it's easy to forget or not have to pay mind to when you use v-binds the more common way, which is like either v-binds colon the name of your variable — or just colon and the name of your variable. That's essentially saying like, “Here's a key in that object, and I’m going to pass in the value after the equal sign.” Versus v-bind equals where you're like, “I’m going to just pass you the whole collection of all the things that I could have passed individually but I don't want to.”

[00:07:38] BH: Do you all have a preference as far as when you use the v-bind equals versus declaring each attribute individually?

[00:07:45] AC: 99% of the time, I will use the shorthand just because I like the way it looks. Having it on each line like very clearly marked out what is being passed in. But, yeah, that's really more of a visual preference than anything. I mean, just object destructure but no.

[00:08:08] BH: I mean, I think from a DX perspective, and so for those not familiar with the acronym Developer Experience, like when you obfuscate the attributes like v-bind equals, some object that you're calculating in the script, that does make it harder for people to figure out what exactly goes in here. Because it does seem like anything could be in there. I think to your argument, there actually is a valid reason to actually be declarative as much as humanly possible, so you don't have to hunt on multiple places for what's going — what’s getting passed down.

[00:08:35] T: I mean, I think also a lot of times the things that we bind to might be like it might be in the data option. It might be in the computed option. It might be in the method option if you're passing methods for some reason as a prop or something. I don't know. To like make a new arbitrary object to hold all those things just so you only have to pass one thing, maybe some people like it. It puts them at ease. But in terms of, like, the experience of working with that component, I don't know that it adds anything.

But to the other way of using it where you're saying v-bind equals in a bunch of stuff, generally I’ll do that if I have to pass the same set of data through a series of components. If I have some kind of like generic button component and I want to pass everything on to the button component but it has some kind of wrapper around it or something or if I had to go through multiple generations of components passing down the same group of data that I’m not really going to alter, then those are situations where I find myself using v-bind equals some object, usually dollar sign adders.

[00:09:36] BH: What about you, Alex?

[00:09:37] AR: I tend to use the v-bind shorthand with a named attribute most of the time. The one or two times that I don't do that is typically or where I’ve seen that primarily used is if you are making some form of complex component. So you have a component that is wrapping a couple of other components, and the person using your component that's wrapping those other couple of components may want to be able to apply a class to something inside of yours. You can give them a prop that says, “Hey. If you give this prop as an object, anything that's inside of it will be bound to this other component.” That way, you can say, “Hey. You can style this entire thing or you can just style this one component. You can style this other component, but it's all inside of this one big component.”

I tend not to use it as this is how I’m defining this component. It's more of a — “I have a base component that is going to get used everywhere.” Maybe every once in a while, I want to apply something weird somewhere but for the most part use the defaults. The other place that I use it all the time is v-bind adders. That is the key place that I just go v-bind is want to just pass everything through.

[00:11:02] AC: Can you just briefly describe what a base component is?

[00:11:05] AR: A base component is where you would create a component if you're in a larger codebase and you have multiple people — or maybe not multiple people. It doesn't matter one way or the other who may be using that code base. A base component is a way for you all to agree. If you are going to make an input for instance, the input will always be styled with rounded borders. If it's a text element, it's going to be styled with rounded borders. It's going to have this type of border. It’s going to just sort of have all of these sorts of things.

As a base component, it allows you to say, “This allows you to always use this one when you want an input.” Instead of every single time you define an input, you have to apply the right style, apply the right class. It’s all there already. When I talk about base components, what I’m really saying is things that you set up and then you kind of don't touch.

[00:12:04] BH: To also tack onto what Alex was saying, one of the things that we talk on the show, we want to try to offer our listeners, is the fact that a lot of the techniques we talk about, there are always trade-offs and there are always reasons to do something differently. Another example of where it doesn't make sense to use a shorthand because, again, like, I think a lot of us here on the show agree that usually declarative code is best when you write it out and it's easy for people to follow. V-bind, again, as the shorthand can obfuscate that.

[00:12:28] T: Can you define declarative code?

[00:12:30] BH: In my mind, when I think of declarative code, it's code that you — for me, I usually associate with being easy to understand. So it's just like whatever you tell it to do is like the thing. I’m trying a little small blank on this. Ari, you want to tap in on how you would describe it?

[00:12:45] AC: Being very explicit with what's happening, if that means that you're being verbose and say, “Yeah, instead of destructuring an object, assigning values to individual variables or properties so that it's very clear in the code what's happening,” as opposed to say assigning a single variable to an expression that chains filter onto a map.

[00:13:12] T: Who would do that? It looks like you’re looking at something right now.

[00:13:17] AC: I mean, I’ve never done that. No, I have done that, just because sometimes, like we say, there are always trade-offs. Because sometimes I think you can end up confusing the issue more by having more lines of code with a bunch of different variable names, trying to be like pieced out step by step. It sort of reminds me of like math class in middle school or high school where they always said show your work, as opposed to just kind of making the steps in your head and not really showing the steps. To me, that sort of encapsulates declarative code.

[00:13:54] T: Yeah. I think whenever I hear a declarative, I always just think, “Oh, that's the one that's not imperative,” but I never can keep the two straight. But I feel like it's something. Declarative is like where you say what you need or you want. You're like, “I want this button to be blue.” Or like, “This button is supposed to be blue,” would be declarative versus imperative, unless they got them flipped. It would be more manual. You would describe the process by which you would make the button blue. Yeah. That's how I see them, but I wasn't sure if that's what you were referring to, Ben.

[00:14:24] BH: Yeah. I know that it's a little different from the traditional like imperative-declarative programming paradigms that I think most people refer to. I feel like in these discussions I’ve had, it's come to be associated a bit with, also, to Ari’s point, like how you name variables and these sort of things. There's this bit of like a style to it and less about like whether or not you're being explicit of, to your point, how to make a button blue versus whether you want the button to be blue.

Most of us, it seems clearly prefer the shorthand with individually named attributes. But the one scenario where you would actually create more confusion is where you're actually using a dynamic component. If you have a component that says going to switch out the different layouts inside of a feed, for example, like it'll be add some time, it'll be a blog post sometimes, maybe a news article sometimes, your requirements for each component and the props they need are going to be vastly different. If you try to manage that in individual lines, you will definitely confuse the people who are maintaining that. So this is where it does make sense to go ahead and v-bind a single attribute that is then computed accordingly based on the correct component that is being pulled up.

[00:15:27] T: Yeah. I guess when I think about that situation, to me it feels less so of a, “Do I use v-bind and pass in an object versus the individual key situation?” And more, like, I think about like state machines? Or if I have to decide to turn on and off five different Boolean switches to determine the state of the component, it feels kind of that territory where I’m like, “No, it should all be a single thing. You're either that thing or you're not that thing.”

[00:15:54] AC: The sum of parts rather than the whole. If you just want to show like, “Here's all the parts. You do the sum.” Or you can just be like, “Here’s what it is.”

[00:16:04] T: Yeah. That's a great way to think of it. Yeah. Don't do math, kids. You heard it here first.

[00:16:14] AC: Yeah. Some of us did plenty of math that we no longer use. So, yeah, I appreciate the encouragement to not continue to do math.

[00:16:22] T: But I feel like the way that v-bind works in Vue 3, it sounds like there may be some changes that could affect applications if you just think you can flip it from Vue 2 to Vue 3 without having to fix anything. What do we know about these upcoming, or I guess they're already here, these breaking changes to v-bind behavior? If only there were someone on the core team who —

[00:16:46] AC: I know. I was just thinking that.

[00:16:47] BH: I was going to let someone else say first but I guess I can kick off the discussion.

[00:16:51] AC: We let you be the voice of authority because technically and officially you are. Yeah.

[00:16:57] BH: Okay. To be clear, there is one specific v-bind behavior that changes. We'll start it off sort of like — let's do this a little bit more like a game show a bit. We have a div here, and the div has an explicitly bound ID of red. So div ID equals red. Now, if after the ID I say v-bind equals — and I have an object with also an ID in it and I’m going to say blue as the value, starting with Vue 2, or at least based on what you understand right now, which one should take precedence? The one that was described, should it be ID red when it's rendered or ID blue?

[00:17:36] AR: Let me think about that one for a second. Let me make a sample pen here. Hold on.

[00:17:44] T: Wait. Are you saying that —

[00:17:46] AR: Okay, yes.

[00:17:47] BH: Cheating.

[00:17:48] AR: I’m not cheating. What are you talking about? No, I knew this red off the top of my head. It would say if you had an ID of red and then an object that is v-bound with an id of blue, it would show red in Vue 2.

[00:18:05] BH: What do you think, Ari?

[00:18:06] AC: I mean, I already know the answer is ID equals red because I have to be looking at the documentation.

[00:18:14] AR: I could’ve done that.

[00:18:14] AC: We are totally taking this straight from the docs.

[00:18:17] BH: Well, I did that intentionally.

[00:18:19] T: Yeah. I think it —

[00:18:20] AC: — That way, if you want to go back and look at it, it will be exactly what we just described.

[00:18:26] BH: So I guess, Tessa, since you didn't get the chance to answer, why is it that in Vue 2 it is ID red rather than ID blue?

[00:18:33] T: Oh, I see. Tessa, since you didn't get the chance to weigh in, here's a way harder question for you. I don't know. To me, it would be nice if it were blue because then I feel like — that's kind of feels in line with CSS where I feel like something dynamic. The idea there is that you would get the data later, so it makes sense that the latest data would override. But at the same time, I’ve run into issues where it's like the inline thing is the thing. That makes sense to me as well because, like, when it comes to CSS generally, one of the hardest things to override is when you have an attribute directly on the DOM element, which that is kind of a corollary for. I would guess it's something — an attempt to like mimic that expectation. But, I mean, really who knows. Maybe Evan had [inaudible 00:19:18] had an issue, and so he randomly decided it.

[00:19:21] BH: That's a wonderful explanation. That's a wonderful explanation of the two paradigms that govern it. To Tessa’s point, yes, in Vue 2, Alex is right. It will render out red because —

[00:19:33] T: Well, Alex’s CodePen is right.

[00:19:38] BH: Fair enough. Fair enough. Let's give credit where credit is due. But Alex did type it into the CodePen. CodePen did not know inherently this answer or at least would not have revealed itself without Alex's magic typing. But to test this point, at least in the two-point — or not two-point. Just like Vue 2 syntax, yes, explicitly defined on the element ID would take precedence over the v-bound ID blue, even though it comes later in as far as the order of attributes. But this is changing in Vue 3, so I’m going to toss the ball to Ari. Ari, what's changing in Vue 3?

[00:20:15] AC: In Vue 3, it will behave more like Tessa's first musing that down the cascade should win. So whatever is declared last in the attributes will win.

[00:20:28] BH: In the scenario we gave, it will be —

[00:20:31] AC: Blue.

[00:20:31] BH: It will be blue.

[00:20:33] AC: Just to reiterate, we said div ID equals red and v-bind equals ID blue, because I would have forgotten by now what we said.

[00:20:46] BH: Just to reinforce it one more time as we have in the docs, in the event now, we flip it. It has nothing to do with whether it's v-bind or not. If it's div v-bind ID blue and then an explicitly stated ID red because ID red is the last one, it will then be red.

[00:21:01] T: Oh, no.

[00:21:02] BH: Order of operation is back to math.

[00:21:04] T: It's based on the order of the attributes but it's not based on the order of the attributes in Vue 2.

[00:21:09] BH: Correct.

[00:21:10] T: That scares me. I don't know if I like that.

[00:21:12] AC: Why does that scare you?

[00:21:13] T: Well, because like so many times I’ll —

[00:21:15] AC: Are you trying to think of, like, all the codes you wrote that might break now?

[00:21:18] T: I mean, theoretically a lot of times there wouldn't be a reason for it to conflict because this situation like our contrived one, I mean, it's contrived, so I can't think of a good reason why one would do that. But a lot of times, I’ll use an extension in my IDE to order all the attributes alphabetically, automatically. And then ESLint and the style guide, depending on your settings. Or if you check the style guide, you generally put the elements in a certain order where v-bind comes first. I guess, I mean, theoretically maybe you would just get into a pattern of like whatever comes later would override. But I don't think that that's something that I would expect just looking at the template initially.

[00:21:59] AC: It’s an excellent point.

[00:22:00] BH: There’s something to be said that with the tooling with Vue 3, it's possible that we should be probably being — we should either change the rules, for example, and not automatically sending people's v-bind call it up. Because as far as like people thinking, like, where would this actually happen is probably when you're trying to merge attributes together. If you just can imagine, you can't. It’s not something where you would explicitly set out to have multiple ones that are the same. It's just to Ari, Alex, or Tessa’s point, you're bringing in a bunch of parent attributes and you're just sort of spreading them on to the child. Then this is where you might have accidental conflicts. Because, if the parent happens to pass on something that's named the same exact thing as a child, for example.

That’s why, for example, I think this is one of the reasons why we're doing it this way is because that way you could probably declare the parent stuff first. Then all the child stuff that comes afterward would then override by default all the stuff that comes from the parent but —

[00:22:49] T: I feel like I would always —

[00:22:50] AC: I’m still with Tessa on this one.

[00:22:52] T: — Yeah. I would expect the child to always override the parent, similar to like if you have a mix in or like component import. Whatever is in the component itself would override those.

[BREAK]

[00:23:01] T: Hey there, Alex.

[00:23:03] AR: Hey, Tessa.

[00:23:05] T: What's got you so down?

[00:23:07] AR: I need to write a native mobile app but I’m just a simple Vue developer and I don't know how.

[00:23:14] T: Well, have you looked at Ionic?

[00:23:18] AR: The Alanis Morissette song?

[00:23:22] T: No, silly. Ionic. Ionic is a platform for building mobile apps with the web.

[00:23:28] AR: Well, what is happening?

[00:23:30] T: With over 100 components and pre-build animations, Ionic gives you building blocks to make awesome apps with ease.

[00:23:38] AR: Oh, no. We're trapped in an ad read.

[00:23:41] T: Best of all, it integrates with Vue, so getting up and running is easy. You can use your existing skills to shift native iOS apps, native android apps, and progressive web apps without any hassle.

[00:23:54] AR: Wait. I can use Vue to write a mobile app?

[00:23:58] T: Yeah. That's what I’ve been saying this whole time.

[00:24:01] AR: Well, hot dang. I guess it's high time I give Ionic a try.

[00:24:06] NARRATOR: To get started, visit ionicframework.com/vue.

[00:24:14] AR: The heck was that.

[00:24:16] T: Just a narrator. Don't worry about it.

[00:24:19] AR: All right, okay. Be sure to tell Ionic you Enjoy the Vue.

[EPISODE CONTINUED]

[00:24:30] AC: Having spent the last two days deep in ESLint configs, her concern about tooling, overriding the order in which you may have originally written things, which I much prefer there to be always an expected order that things are declared. To me, listeners should always be the last thing, last attributes declared. I can see that inadvertently overwriting the developer's intent, which then Vue is apparently inferring developer intent by the order of properties, even though tooling can very easily make that different. I’m just going to say maybe this was a bad call.

[00:25:13] T: Because I feel like also we don't really have a good way in the template of showing intent with a specific order. You can't put a comment in the middle of your list of attributes, for example. “So how did they know that the order is deliberate or if it's just arbitrary?” I think in general, at least for me, in templates with these kinds of frameworks, I’m not really used to a lot of decision making being yielded to the template. So it's surprising to me that something like the order of attributes would be something that the template is responsible for.

[00:25:48] AR: I think I can see it both ways to a certain extent. I’m kind of flip-floppy on this. On the one hand, I like that. If it goes in a certain order in the template, then that's how it's going to show up. That’s how it's going to be handled in the component. But at the same time, I definitely have an ESLint rule that says v-bind goes to the bottom, always. So I can go both ways on this one.

[00:26:19] T: It's also like, yeah, because there's also additional ordering rules in the script tag, you would necessarily have to flip between the two of them to understand all of the ways that the order is being determined. It’s just confusing to me that some of it would be determined by the template and some of it would be determined by the script tag. Now, you have two different places to check to see why your data is coming in, in a certain way.

[00:26:44] AR: I suppose what you could do is, you could — if you are pulling in an object to do v-bind on, you could deconstruct the incoming object that you are wanting to put on there and pull out the specific things that you do not want them to be able to reassign. And just define some extra variables that are never used because you are pulling them out of an object.

[00:27:10] AC: Okay. If we're going back to examples we just used in scenarios where you would use v-bind explicitly instead of, say, the shorthand, we may be passing in things we're not aware of.

[00:27:23] AR: And that's what I’m saying is that if you do not want —

[00:27:25] AC: But if we're just trying to batch, like, pass props down, chances are if we wanted to destructure, we would have done that somewhere higher up. But if we're just trying to pass things through, it seems like it sort of defeats the purpose of how we decided to handle it in the first place. I’m actually now firmly of the opinion that Vue 2 behavior was better.

[00:27:49] AR: Or maybe a toggle to be able to toggle between the two so that you can —

[00:27:50] T: Oh, no.

[00:27:52] AC: Yeah, a configuration.

[00:27:53] AR: More options.

[00:27:55] T: I mean, I think —

[00:27:55] AR: That never goes wrong.

[00:27:57] AC: One other point I want to make is that something I want so desperately is the ability to have comments in the middle of attributes into place.

[00:28:05] T: That would be amazing.

[00:28:06] AC: I can't tell you how many times I have wished for that.

[00:28:08] T: Comments in templates is the worst.

[00:28:11] AC: Just being able to say, like, comment out an attribute.

[00:28:14] T: Oh, my god. Yes.

[00:28:14] AC: Just to see how the behaviors — I have tried to do that so many times like, “Nope, that's not a thing.”

[00:28:18] T: I always end up making a second copy and then deleting the thing and commenting out the other whole thing. It’s like, “Come on.” Especially if it's, the order is important, I would want to be able to leave a note being like, “Don't change this order. Here's why,” because like when it comes to —

[00:28:33] AC: Yeah. And like have an ESLint rule, like, disable thing for that line. Yeah. That’s the other reason I want comments is because sometimes I need to overwrite the ‘don't use index as the key when I’m actually using an object.’ Index is the key, so screw you.

[00:28:53] T: Yeah. Or sometimes you just don't need that key behaviors but you have to put it because the [inaudible 00:28:57] said so and it's like —

[00:28:59] AR: I have a solution for that for you. You could always just use JSX.

[00:29:04] T: I thought you said you had a solution but then you just spewed —

[00:29:09] AC: — I was about to use an obscenity but we're not supposed to do that, so F you.

[00:29:15] T: Just kidding. I’m sure there's valid reasons to use JSX but for the declarative purposes.

[00:29:20] AC: By the way, Ben is looking —

[00:29:21] AR: Yeah. Ben is deep in study.

[00:29:22] AC: He’s looking like we just ruined his world.

[00:29:25] AR: And he’s deep in thought and concentration.

[00:29:28] T: I mean, it's just when I think of merging multiple component data together, I always think of it as like Object.assign, so maybe it's just a matter of readjusting my mental model. But I like that — that was really predictable, and I know no matter what the children are going to follow a predictable pattern and the ways that they merge the data. Now, I guess it's technically predictable but it's like, I have to look at the same thing. Like Ari said earlier, do the math to see what the sum is, rather than just knowing it's always going to be merged in a specific constant order.

[00:30:00] BH: And this is why software is an iterative process. Who knows? I actually do see an RSC. Actually, that's why I was a bit heads down on the discussion on this very thing, and then people have been bringing up the very issue that we all talk about as far as the unpredictability of order in HTML attributes. So there very well could be — as anything else, when you're looking to do these things, check the docs for the latest updates because sometimes we are human when we make these design decisions. So it's very possible this could certainly change. I mean, definitely let me be very clear. This is not a promise it would but this is just part of patching and trying to figure out things as people use them. And whether or not we sort of went down the wrong path on this one or not.

[00:30:41 AC: For reference, today is January 7th, 2021, so yeah. If it's any significant amount of time after that date, check the docs.

[00:30:51] BH: Yeah. Check the docs. Yeah. You know what? I’m going to drop this for those listening, so I’m just going to make sure. In our resources, we'll make sure to drop the RSC sort of being discussed. If this is something you feel very passionate about and also have your own opinions, please be sure to add your comments to the RSC. Hearing from the community is something that can be very helpful, as far as letting sort of the authors and the team know what people's thoughts are on it.

[00:31:16] T: Yeah. I’m imagining the code base that both uses the current breaking change as discussed and also a functional CSS library like Tachyons or Tailwind. That’s a little scary. Anyway, yeah. Potentially, if this changes, does that mean that there would be no breaking changes in v-binds behavior in version three?

[00:31:36] BH: Theoretically.

[00:31:37] T: Okay. Otherwise, v-bind [inaudible 00:31:39] behavior.

[00:31:38] AR: Yay. No breaking changes.

[00:31:42] T: It is the same.

[00:31:43] BH: Too soon to celebrate.

[00:31:44] AR: All right, okay.

[00:31:46] T: Well, we'll edit that in if anything changes before the episode goes out.

[00:31:51] AR: We’ll save that clip.

[00:31:52] T: Yeah. Because I know like the model, there are some big changes, so I just wanted to make sure that this is the only breaking change in terms of v-bind as of now.

[00:32:00] BH: To my knowledge it is.

[00:32:01] T: Cool.

[00:32:02] BH: But for all of us, again, looking, I do not hold an encyclopedia of all the docs. Please check the docs for any additional things.

[00:32:09] T: Ben, this whole time I thought Ben was short for bencyclopedia, but I was wrong.

[00:32:15] AC: You heard it here first. Ben does not know everything.

[00:32:20] BH: Please tell everyone that.

[00:32:24] AR: With that, it's time for us to move on to this week's picks. Ben, you get to go first.

[00:32:32] BH: Alrighty. Well, in that case, my very first pick. A lot of times, when it comes to reading books, I don't know about you all, but there's just so much content out there. A lot of times, there are books that you hear that are highly recommended like 7 Habits of Highly Effective People or How to Win Friends and Influence People, like friends and whatever. But it's just like these are the books you're kind of like, “Oh, that would be interesting to read but I also don't want to dedicate like hours on end to this because after all, like even as someone who is like a self-proclaimed productivity nerd, I like reading non-fiction.” There are times these books still take me either months to get through, just because I’ll get like I’ll lose motivation 30% through.

All of that to say is Blinkist is a service and one of my picks for this week where basically they take really popular books like the ones I mentioned, and they basically sum it up within 15 to 20 minutes. So they have an audio version, as well as a basically short-handed like sort of notes. For those who of us who grew up in the ‘90s, you might think this just like Sparknotes essentially but —

[00:33:34] AC: I was about to say that, which I sparked out at like every book report.

[00:33:39] BH: Yeah. It’s just a fantastic use of your time because you basically can go, “Oh, I got like the seven habits that highly effective people use. That was interesting. I’ll like take those two things and, nah, I’m not going to read the book anymore. I’m good. I’m going to move on.” I think there's something really valuable about being able to iterate that way, as also maybe you're like, “You know what? What was really interesting. I want to deep dive further.” Now, you have reason to buy the full book and read. Make something actionable of it. I think that's one of the, at least —

[00:34:04] T: But the seven habits were spoiled. Why would you read it after it was spoiled? Now, you know the ending. You know the seven points.

[00:34:09] BH: You need more anecdotes. You need more examples. You can figure out how to apply it to your own life. But anyhow, I digress. Yes, Blinkist. There are other services. It's just Blinkist is the one I’ve tried. So far, I’ve been happy with the quality of content, the highlightings. If you're a big person into highlighting and exporting notes, that part is less than optimal. But, again, for the content, it is still worth the time and money.

For my second pick, I know I picked this the last episode but I think it's worth repeating again, just because, as the more I’ve dove into, the more I’ve enjoyed it is the Obsidian Markdown editor but also for note taking, second brain Zetacast and stuff. I’ve been really enjoying that. Probably I think by the time this episode is released I’ll have released a night owl theme for the Obsidian theme based on Sarah Drasner's VS Code Night Owl. Be on the lookout for that. With that, I’ll pass it back to you, Alex.

[00:35:00] AR: Cool. Those all sound really awesome. Tessa, what are your picks for the week?

[00:35:09] T: My first pick since Ben talked about not reading books will be a book, but it has lots of pictures. It's called Draw Stronger. A friend of mine recommended it, and it is a book kind of about ergonomics and limb strength and how to I guess maintain a healthy posture, do stretches that are good for your arms and your core. It’s basically like how to not debilitate yourself when you're a working artist. I read most of it when I got it a couple days ago, and it seems like not just a nice light overview of all the different muscles that you use when you're working at your desk and also gives a lot of different stretch routines and things you can try.

But also, of course, because you are sitting at your desk, leaning over for extended periods of time, there is potentially a lot of overlap with issues that people who, I don't know, might be working at a computer all day could face. If that's you, you may want to check out this book. It's print only. There's no e-book. I tried.

Then my other two picks are for the dry winter season. One of them is a lotion called XeraCalm A.D. from a french company, Avene. This is great if you've ever had extremely severe skin dryness to the point where maybe you couldn't even do anything. I hope that this can be helpful to you and also just for less severe skin dryness issues. It's a great lotion. It doesn't have preservatives I believe, it doesn't have a scent, and it doesn't leave your hands greasy. I mean, they are moisturized but it's not greasy compared to other lotions that I’ve tried, so I really appreciate that about it.

Then the last pick, some of you may know that I do have hair, and hair in the winter can get very staticky. So depending on your hair type, this may work better for you when your hair is wet or dry. For me, it works better when it's wet, but I like to put this oil called Mermaid Hair Oil from Captain Blankenship in my hair sometimes. It smells nice. It doesn't weigh my hair down like other oils I’ve tried, and it keeps the static from getting out of control. Those are my picks.

[00:37:15] AC: I might have to try that because I also have hair.

[00:37:19] T: Oh, my gosh. Yeah, we do.

[00:37:21] AC: I have —

[00:37:21] AR: I had never noticed.

[00:37:22] AC: I know. I have very fine hair which gets real staticky. I live in Colorado, so it's real dry, so yeah.

[00:37:31] T: When I’m feeling really on my self-care game, I’ll put in the oil. I’ll brush my hair and braid it. So many times I have fallen off the wagon and then suffered for hours on end trying to undo that work.

[00:37:43] AR: Okay. Next up, Ari.

[00:37:45] AC: I don't have any picks. All the shows I binged watched over the break were so soapy that I’m not willing to admit to them here, so sorry. Not this week.

[00:37:58] T: I finally started watching your other pick, The Queen's Gambit, so I’m like halfway through now.

[00:38:02] AC: It’s so good, right?

[00:38:03] T: It’s very stylistic and lush.

[00:38:05] AR: Nice. Cool. Well, that comes to me then, and my one pick for this week is the book SVG Animations by Sarah Drasner. I just received it as a gift and I am super excited to be able to start looking into it and learning about SVG animations, so yeah. That’s it for this episode. Thank you for listening. And remember, Enjoy the Vue.

[END]