503: Pull Request Issues, Checking in Node Dependencies, Nuxt and PropTypes, and Less Decomposing
We check in with Pull Request Issues guy, should you check in Node dependencies, how to pick technology to learn, and what does Nuxt or Vue do for PropTypes?
Guests
Chris Coyier and Dave Rupert
Time Jump Links
Transcript
Dave: Previously, on ShopTalk Show...
[Time Travel Vibrations]
Dave: "PRs are bad" - guy on Twitter.
Chris: Oh, we should have saved this for the next one. We're right at the end of the show.
Dave: Oh, we'll save it for the next one.
Chris: [Laughter]
Dave: We'll push it to the next because it is about a three-hour conversation about this.
Chris: It probably is.
[Banjo music]
MANTRA: Just Build Websites!
Dave: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about front-end Web design and development. I'm Dave--pull request--Rupert--
Chris: [Laughter]
Dave: --and with me is Chris--merge button--Coyier. Hey, Chris. How ya doin' today?
Chris: Good. Good. Good. Well, maybe I guess we've got to do it because we said we would do it. It just was a funny tweet that got dropped in the Discord. I honestly think the original tweet had some good points.
It's from a fellow named Allen Holub. I have no idea who Allen is, I'm afraid. Maybe you're famous. You seem at least a little bit famous. "I help you build software better & build better software," is his Twitter bio, and has a decent number of Twitter followers. That's who the case is here.
The tweet reads, "You need PRs," meaning pull requests "when you don't trust the code, you don't trust the person writing the code, you don't trust the process used to write the code, and you don't trust the system used to check in the code," so trust issues.
Then he says, "Maybe we should dump the pull requests and work on that trust thing instead." So, the good points of this being that maybe you're kind of right in that maybe if you are working with just yourself or a team of people you super-trust and you have really great checks and balances that are testing that code and that you have tests against the tests, like you can't even check in the code unless the tests exist and pass (and stuff like that). Maybe if you had everything just perfect, that maybe, when you're done, you just kick it to master. Maybe you don't even have branches.
I mean it sounds wild. Of course, this has (as I speak) 235 quote tweets. This is the main character of the day of dev Twitter.
Dave: Gotten a little bit ratioed. Yeah. Yeah.
Chris: I even went in.
Dave: [Laughter] The first quote Tweet is, "Who hurt you?"
[Laughter]
Dave: Thank you, Shantini, for that gem.
Chris: That was pretty funny. I happened to be watching Apocalypse Now for the 790th time, and so sometimes I even fast-forward to the part where Marlin Brando has got this little bowl of water. He's just rubbing it on his bald head because they've gone upriver. They've found Colonel Kurtz, you know. It's just the creepiest scene of cinema ever made where he's like, "Are my methods unsound?" He's like, "I don't see any method at all, sir."
Dave: [Laughter]
Chris: It's just the creepiest scene. Sometimes it gets in my head for like two weeks at a time. I quoted that while I quoted PR. I wasn't trying to pile on Allen, although I was. So, sorry, Allen, if it ruined your day or anything. But it's just funny because it's kind of like there are some pretty obvious reasons. I don't think PRs are a problem in the industry, let's say.
Dave: Right. Yeah. That's where I was like, "Wait. We're mad at PRs?"
[Laughter]
Chris: Yeah.
Dave: For me, I just treat PRs as like very helpful. It's a branch. It's like, "Can we put this branch on the big branch?" It's just like asking a question, and then you get a nice, little view that shows you all the differences between the thing you're trying to put on the main thing. That does not seem like a big piece of drama.
Chris: No. As a matter of fact, I find tremendous value in it. A good chunk of my life is in PRs. It's so interesting to be like, "Oh, what did you do there? That's interesting." And, like, "Oh, there's a little piece that maybe we should have a little conversation about." And "Hey, here's a thing that's just wrong." You know?
Dave: Mm-hmm.
Chris: There's all kinds of just stuff, and that's great. GitHub does a great job. PR is famously not a feature of Git itself. It's a feature of GitHub.
Dave: It's a feature of GitHub.
Chris: Yeah.
Dave: And GitLab.
Chris: And everything else because it's just a good idea.
Dave: I've never been mad at PR. If anything, I've been mad I didn't really dig into a PR, like go line-by-line.
Chris: Yep.
Dave: I've had regrets, if that makes sense. [Laughter] I've only had regrets for not doing PRs more better.
Chris: Yeah because there's a little pressure, isn't there, when there's one sitting there? You're like, "Oh, I can't let that sit there that much longer. I have to just get it in," so maybe you do a half-ass job of it. That's where the regret comes in.
Dave: Yeah, that's where the regret comes in. You have to hit merge - or whatever. Yeah, it's like I didn't nitpick some variable name when I probably should have. You know? Just because it ended up something got named wrong or didn't reflect the current understanding.
This is just - I don't know, man. What a world. It just is very interesting to me that this was a thing.
I think it's maybe connected. I don't know if Allen is part of it, but there's kind of an anti-branching. Isn't there kind of like an anti-branching thing because there are people who are like, "It creates a lot of problems"?
If you're in a Rails app and you branch and you run the DB and then you push it up and then it runs a test and creates a migration on the database and then it has to roll back the database, there's a lot of drama. Working on a branch can actually kind of really break a database or make it difficult to roll back and do all that stuff. I've seen situations like that, so I've heard there's this--
Chris: I don't even know how that would work.
Dave: --kind of like trunk-only development sort of thing, like you're always snapping off of trunk-only, or something. You only--
Chris: I was working on a branch this morning that was a branch of a branch, and that wasn't my favorite experience because then I was like, "Oh, why does this branch have a bunch of crap that's already committed to master?" Then I have to remember that you have to pull master to the secondary branch. And you can't just pull master to the thirdiary branch. You have to pull the secondary to the thirdiary if you want to clean up the-- It was just confusing, and so I could see not branching branches very much because that gets brain twisty to me.
Dave: Yeah. Well, I think there is an argument there, I guess, that floats around. But I don't know if I agree. That's the thing. I like feature branches. I like naming things. Why do computer scientists hate naming things? You just say it's a feature. And what's the name of the feature? It's the new avatar system.
Chris: Hmm.
Dave: It wasn't super hard, Chris.
Chris: [Laughter]
Dave: We all agreed. We put our new features in the feature one. You know? [Laughter] In the feature bucket. Why do we hate naming? It's so easy.
Chris: So easy.
Dave: I get that we do it bad. I get that we do naming bad. But it's not like of all the bajillion problems I have in my life, something like a branch being named weird or a function being named weird isn't a super-huge deal. But it can be a problem. But guess what. We have Grip, so we just fix it that way.
Chris: Yeah. Too much to wrap my head around. Speaking of controversial Git things, did you see -- it was back in December of last year, I guess -- Jack Franklin wrote this blog post "Why you should check in your Node dependencies"? Literally, slap that Node modules right up in there, yo.
Dave: Oh, whoa! Whoa!
Chris: He works on the Chrome dev tools team, and that's just how they roll.
Dave: Wow! Okay.
Chris: Yeah. You'd think there'd be a lot of commit noise, but maybe not because you just do anything where you change Node modules. That's just a separate commit. Never mix that with hand-authored code.
Then part of the deal, which I kind of get, is imagine how much work Netlify does on a daily basis, or Vercel - or whatever - or anything that runs your build process (Cloudflare Pages) that has to pull them.
Dave: Yeah.
Chris: How much computer churn there is because they're not sitting there. They promised to do that for you. Like your CI is going to run a lot faster because the code is just sitting right there, yo.
Dave: Well, and you're probably just doing implicit trust, too. Like I'm just trusting that the code in the NPM in the Node module is good. But if you put it up in your repo, maybe it gets checked a little better. I don't know. Like passes all your checks.
Chris: I don't know. I'm not going to start doing it, necessarily, because it sounds like--
Because I live it in not Node modules but WordPress plugins land. My Git Repo is all of WP Content, so it's not WordPress itself. That is separate and more secured and cannot be changed via FTP and crap like that. It's kind of locked down. But all the themes are because that's what's in there, and all the content is because that's in some includes directory - or whatever they call it. But plugins are too.
Dave: Mm-hmm.
Chris: So, the implication is that you have to deal with your plugins. Probably every day of my life. I have enough plugins on CSS-Tricks, for example, that every day one will be updated.
Dave: Mm-hmm.
Chris: But I don't do this every day, but I do it at least once a week. Update the plugins and then I don't just update the plugins. I have to go to check them into Git and push them up because that's how the deploy mechanism works. It is not my favorite; I'll tell you what.
Dave: Yeah. Yeah.
Chris: Don't love that because there are so many tools that are out there that just update your plugins for you, which I'd prefer because I just can't be bothered. You know?
Dave: Yeah. I wonder if there's a package manager, depend-a-bot for--
Chris: I'm sure there's a way around it. This is not the only way in the world.
Dave: Yeah. yeah.
Chris: But I have Git where I want it. I pointed it at the directory that I like to have it at. It just so happens that the fallout is that I have to do plugins.
Dave: How many times have you been working on something and you're like, "Oh, cool. I can't merge or I can't push because I have to pull," so I pull, and then I try to do it, and then everything is broke? You're like, "What is going on? What code changed?"
You spend half a day trying to figure it out, and it's like, "Oh, I had to NPM install. That was actually the issue that occurred."
Chris: Oh, that was it. Yeah.
Dave: You know? Or "Oh, somebody created a new environment variable and I forgot to add it."
Chris: Mm-hmm.
Dave: That's a thing we deal with all the time. We've been doing a lot of dev ops stuff lately. But you're like, "Oh, shoot. I'm missing an environment variable, so let me fix it."
Chris: Yeah. I also find I don't update my NPM dependencies as regularly on purpose.
Dave: Mm-hmm.
Chris: It's like, "I don't care. I don't really care what versions these things are at. They're working, so fricken' leave them alone." That's not a super great long-term strategy, and I like that there are tools that warn you when certain ones need updating and stuff. But it's much less common than WordPress plugins. WordPress plugins are flying with updates all the time.
Dave: Really? Really? Yeah.
Chris: Yeah.
Dave: I would have thought PHP was slower, but yeah, okay. I like it.
Chris: Well, that depends on what the company is. Maybe there are some marketing reasons behind it. I found it famously that Yoast updates (it feels like) every single day.
Dave: Mm-hmm.
Chris: It was too much for me because it's a rather large plugin and sometimes things go wrong with updates, like just the nature of moving bits around on servers. Sometimes one file wouldn't get transferred properly. The whole thing borks. The nature of PHP is such that it can white page your whole site. I was like, "Okay. Enough."
Dave: Have you used NPM Outdated, ever? You just type npmoutdated, and it'll give you a list of all your outdated modules.
Chris: Then you have to one-by-one it?
Dave: Then you have to one-by-one it, but this is where it gets frustrating is if I do NPM install this thing, NPM sometimes is like, "Yeah, okay. I installed it." You look and nothing changed. It just fetched the same version you had because something was hard--
Chris: Did it change your lock file, though, or something?
Dave: Well, no because, like you say, you're supposed to do NPM install - whatever - Vue showdown, and it'll update that.
Chris: Yeah.
Dave: But if it's pinned to a version in your package, it'll just fetch that version, basically. You know? You have to then go into the package and either delete it or reset it. Anyway, I've been dealing with that to some degree, too. It's just like, I've got plenty of stuff I need to update but there's a bit of a hassle in updating stuff. Then, not to be too critical, it's a bit of a house of cards because if I update - whatever - Babel Core to 7.0.0-bridge.0, what happens? [Laughter] Does it fall over? Do I really--?
Chris: It does worry me sometimes, even if you're doing pretty good diligence on those. You open up the site. You click around. You run your tests. But you're like, "Hmm... What if it's something deeper weird?" You know? I'm never super sure that it's going to be fine.
Dave: Well, and SemVer, right? It's like major, minor, patch. You know? Like major versions--
I like, actually, Melanie's and Amber's approach where the major versions contain breaking changes, for sure. They contain breaking changes.
Chris: Yeah.
Dave: That's what they're supposed to be. But sometimes people just do it as a major update, like ESLint 732 versus ESLint 8.8. Chris, I don't know what's going to happen. [Laughter]
Chris: Hmm.
Dave: That's a big one for me, you know? That controls a lot of things for me. Kind of everything looks like it jumped. Anyway, so--
Chris: Yeah.
Dave: You just have to figure that all out.
Chris: I really like when people adhere to that, and it seems like a vast majority of things do. But I was just looking at Three.js the other day on version 137. They don't. That's not SemVer.
Dave: Well, and maybe I need more E to E tests and then a depend-a-bot. That's probably my situation. If I get something that runs and it's like, "Can you get to the homepage?" and it's like, "Yes, I could get to the homepage," that's probably what I need. [Laughter] If it could do that, then I could do anything, I guess. I don't know. I have to figure that out.
[Banjo music starts]
Dave: This episode is brought to you by Axe-Con, a free digital accessibility conference. From our friends at Deque, makers of the Axe dev tools browser extension, comes a virtual conference welcoming developers to learn about building, testing, and maintaining accessible digital experiences.
I spoke at Axe-Con in 2021. It's an amazing event. There are so many people speaking. It's so filled that you get to see accessibility from a bunch of different angles. Some of the best things I got out of it were just kind of these summaries of the state of the union in accessibility. There's so much going on.
I'm just going to name some of the amazing speakers that are coming here. I'm just going through the website. There's this guy, Sir Tim Berners-Lee - I don't know - invented the Web; Seth Godin (seems popular); Liz Jackson (amazing speaker) - watched tons of her talks on YouTube; Regine Gilbert; Rachel Andrew; Stephanie Walter; Maria Lamardo (who does a lot in the Vue community); Jamie Knight + Lion are going to be there; Elle Waters; Nic Chan (fellow shop-o-manic); Scott Vinkle (who used to help me on the Accessibility Project); Stephanie Eckles; Glenda Sims (the Good Witch, she's been on ShopTalk Show before); Anna Cook (probably read her blog posts 150,000 times); and Jared Smith (the guy who maintains the WebAIM study that happens every year).
So many fantastic people, knowledgeable people. This is sort of the cream of the crop for people who practice and know a lot about accessibility. If that interests you, you should head over to deque.com/axe-con. It's March 15th through 17th. Full days of conference, multiple days of conference, so join us there. I'm probably going to be there, March 15th through 17th, at deque.com/axe-con.
[Banjo music stops]
Chris: All right. Here are two back-to-back user questions.
Dave: Hey! Been awhile. Let's get into it.
Chris: Not users. You're just listeners.
Dave: Listeners.
Chris: I'm going to read them both because they seem similar interesting.
Dave: Okay.
Chris: Anna writes in, "Web developer 12 years into the career. Formerly full-stack. Nowadays mostly front-end. I'm afraid my skills have become rather stale. I work with an older system using an old JavaScript library. I'm getting overwhelmed trying to refresh my knowledge. I'm not really looking for a new job but want to be more current. Do I do React, ES 6, Modern CSS? What should I do?"
There's Anna, 12 years deep, kind of trying to make sure she's probably not backed into a corner or anything. Seems a smart move.
Here's Nathan. "Uh, okay. I've heard jQuery is no longer cool."
Dave: [Laughter]
Chris: "The thing is, I've been writing jQuery for seven years and I've gotten really good at it. It already solves most of my problems, you know, along with PHP and Ajax. My sites are not slow. Is there any good reason to switch to something more modern? I'm not opposed to learning something new, but I'd like a framework that has the same level of functionality and simplicity. Where do I go from jQuery?"
Chris: It's just interesting that we got two questions so close to each other that were so similar, and we've heard this lots more times on ShopTalk Show as well. Lots of people in this position. These are the people I had in mind when I was thinking about "The Great Divide" stuff from a couple of years ago. There's a lot of people in that kind of like WordPress and jQuery and stuff, which is literally what CSS-Tricks is, by the way.
Dave: Yeah.
Chris: That it's like you can make a pretty good living at it, but there probably will come a day where it's even -- I don't know. It scares me that that eventually will die. Blah. Maybe.
Dave: Yeah. The jQuery thing is probably easier to tackle first for Nathan.
Chris: Oh, okay.
Dave: For me, at least. jQuery is probably not getting new, big feature releases. I don't know if there's going to be a jQuery 4. You know? [Laughter]
Chris: Right.
Dave: If it's working, it's working for you, that's great. The reason to upgrade would be purely a lot of the new -- in the last seven years that you're kind of talking about -- the new DOM features are jQuery features. Document query selector all is basically the dollar sign in jQuery.
Chris: Yeah. Right.
Dave: There's a for each for arrays, and that's $.each.
Chris: Yeah. Fetch is fine. You know?
Dave: Fetch is like $.ajax.
Chris: Yeah.
Dave: All these things now exist in the browser. If you figure it out, you save 30 GZIP kilobytes, which ends up being 100-something unzipped bytes, or something like that, or JavaScript.
Chris: Plus, it seems more future-friendly anyway. Going around calling yourself a jQuery developer is probably not doing you any good. A step forward in your career is maybe just drop it and do all that stuff in native JavaScript. It's certainly hip. [Laughter] You'd be kind of rad if you just did everything you did now but you never touched a library to do it.
Dave: Yeah. Well, there are ways. I think you can replace a lot of jQuery with not jQuery. There are a few functions, though, like closest. What would be another one? Like parents - plural - and wrap, that don't exist. There are ways. JQuery is just JavaScript. There are ways to do that. Chris Ferdinandi has a whole bunch of libraries and stuff to help you get off of jQuery, just using regular vanilla JavaScript.
Chris: Mm-hmm.
Dave: But that would be something to maybe look at. It depends on what you're using. If your use of jQuery is, "I use jQuery slider. I use jQuery lightbox. I use jQuery blah-blah-blah-blah-blah," you might just stay using jQuery because that's a lot of stuff to replace at that point.
Chris: Oh, I see. Yeah. If you're not just using utilities, but you're using plugins back from the day that use it internally.
Dave: jQuery UI, anything.
Chris: Yeah.
Dave: Yeah.
Chris: Yeah, that's a good point. There's a good discrepancy there. Not discrepancy but distinction between those things.
Dave: Yeah. If you're using FitVids, get off of it. [Laughter]
Chris: Yeah.
Dave: There's an aspect ratio in CSS that replaces FitVids.
Chris: Yeah, totally. Entirely.
Dave: Get off of FitVids.
Chris: Yeah. Even Clamp almost kills FitText.
Dave: FitText. I have a blog post half-written to use Clamp. It's probably better. With FitText, I had to remeasure the browser every time you resize. Clamp does not. Clamp just knows how wide your browser is.
Chris: Oh, it's so great. It's one of my favorite things in all of CSS right now.
Dave: You can get the min-max. You can get clamping. It's so easy to express what you're doing.
Chris: Part of me thinks, though, you're saying, "Oh, I'm using jQuery and Ajax for PHP and stuff." Part of me thinks that's a way to dip your toe into the future, if you want to, in that chances are then that means you're getting some data. Then you're going to do something with it on the front end.
Now, maybe that data is ready to go HTML. I know that's a school of thought that suggests that that's the best possible route and that the backend should be doing the templatizing in a way. But it's more common, I'd say, that the response is JSON and that you stringify into an object and then you map over it and template it and stuff. That's stuff jQuery sucks at. jQuery is not going to help you with that, but something like petite-vue will. That was built for that type of world.
If you're like, "Oh, I want click handlers and stuff," well, great. jQuery's way of click handlers was to have real separation between the HTML and the JavaScript saying, "I'm going to write a selector. I'm going to select that thing I want to be clicked on," and then write code.
It just turned out, over time, that I think as much as people like that and may still like that that it maybe wasn't as genius of an idea as everyone thought. Maybe just chucking click handlers right on the thing that you want to click is kind of like the right path.
Dave: Yeah. I think there are benefits. Even from components, too. You're just like, "When you click this thing, do this thing." You're not like, "I hope that ID stays the same forever." [Laughter] You're not doing that.
Chris: Yeah.
Dave: You know?
Chris: Yeah. That's dangerous stuff. It just will break at some point. Selectors are notoriously slippery. Anyway, I think that might be cool. You're certainly going to--
Something like petite-vue -- Dave and I have a video on that -- might be a step forwards into modernizing your way of thinking about building stuff.
Dave: Yeah. I think that's a good one. To Anna's thing, I've been doing it 12 years. What should I do? I don't know. There are a lot of things you could do.
For CSS, CSS has changed a lot in 12 years. I don't think anyone is up on everything. I had questions about this new cascade layers that came out recently - today.
Chris: Ooh... It is weird. Yeah.
Dave: It's melting my brain a bit. If you type it in the normal way, that's more powerful than an @layer. And so, I'm like, "Ah! What's going on?!" because usually the at something like @media is more powerful than the root.
Anyway, I'm figuring all that out. My brain is starting to wrap my head around it.
But there is web.dev/learn/css is really good. Obviously, CSS-Tricks, but web.dev/learn/css is just a CSS course, so you can catch up on everything. Skip the parts you know really well. That's pretty easy.
As far as JavaScript and stuff like that, to be more current, there are a lot of options there. I like Wes Bos's React for Beginners. It's a really great place to start because Wes is pretty good at teaching you, just, "Here's how to get started in this, and here's what it does." You know?
Chris: Yeah.
Dave: React, according to the Jamstack Survey, is very popular, and so you can probably get a job doing it.
Chris: You know how when you ever jump into a codebase that you're not really familiar with? At least, I think front-end developers do this. They're like, "I know I need to change stuff like styling and layout and content and stuff."
Let's say you Hello, World something like Next.js or Nuxt, because it's so easy. They always make the DX of installing it raw so easy.
Dave: Yeah.
Chris: You type three lines and it's already spun up a Web server and all that. Click that and open it, and it'll say, "Welcome to Next.js!" or something. Just do the old find in project for that line of text, and you'll find the file that it's in. Then change it and hit save and see what it does.
It might be a little eye-opening for you because, depending on what your stack is, these days it's going to instantly change that content. You find the styles that are styling that page and change it, it's going to instantly change this.
There's a world of, like, in better DX, that lives in some of these new frameworks that's freaking sweet.
Dave: Yeah.
Chris: It's so good that there's some value there. You might find that you're faster - and all that stuff. I find working in Next really great.
I would say I haven't actually used it, and they bring controversy wherever they go. But all that gang behind Remix has got a lot of stuff behind it, and a lot of the vibe is, "Just do things the classic way. Do it the HTML way. Do it the CSS way."
I do think that's really cool. Especially, it might be kind of a cool bridge framework for somebody that hasn't updated their skills in a while to go with a framework that's kind of embracing what they feel is kind of the past but to you is your present.
Dave: If you're going to stay in React, I liked Redwood. I thought it was pretty cool just because they have a pretty good example how to get you set up. They had a tutorial, yeah, in the tutorial section - learn. I thought that was pretty cool, and just how they do it.
Chris: Yeah.
Dave: This is the guy who made GitHub behind it, so it's very traditional Rails app kind of vibe. I found it to be pretty useful.
If you're very HTML forward in the way you do things, Vue is a really excellent choice. You could learn Nuxt. Mastering Nuxt is a course they have. I'd recommend that just because you learn Nuxt. Maybe you could work for me, but we'll figure that out. [Laughter]
But there are so many cool options for frameworks.
What I want to say is, modern JavaScript, there's one that fits your way of doing it. That's what I'd want to say. How you're used to making code.
Somebody that's been frustrated with React or Vue and created something that fits the way you do it, maybe that's Angular, maybe it's Ember.
Chris: Yeah.
Dave: But there are a lot of paths, but I think there's somebody who does it the way your brain thinks about it, so that's what I'd say.
Chris: Yeah. I think one of the biggest leaps is this, like, "I have never used a JavaScript framework, and now I know that lots of people do, so maybe I should start using them too." That's going to be a hard one to leap over because I think you'd know if you needed one at this point. You're going to have to kind of invent a reason to need one, in a way.
Dave: Yeah.
Chris: The work, I think, fairly obviously demands it when it demands it. It means that you haven't built anything particularly data and template heavy with lots of obvious interaction stuff. I shouldn't say that you just haven't because the Web is a big place and there are lots of people, but the world of -- use this horrible word -- Web app land has come to kind of need and rely on the feature set of JavaScript frameworks.
Dave: I mean it's really powerful. I was doing it in Nuxt. I'm working in Nuxt, and I was building out some user flows, trying to fix all this stuff up.
Chris: Mm-hmm.
Dave: I needed a "users that haven't logged in for the first time yet" view, and I just couldn't. I was able to spin that up. You know what I mean? [Laughter] I was able to get that going and that's kind of what you want.
Chris: Yeah.
Dave: You just want to make sure it all works.
[Banjo music starts]
Chris: This episode of ShopTalk Show is brought to you in part by Notion. That's notion.so. That's where you can go to get started for free with your team.
It's a collaborative tool. When I first got started working with Notion, this was kind of an unintended side effect of working with it. It wasn't even how it was necessarily marketed, really, but this is how it played out and I'm very happy about it is that it replaced a bunch of tools.
For example, we needed a tool at CodePen to work on shared tasks, like a Kanban board of who is working on what, who is talking about what, where do I go to reference information about this task, and all that stuff. We do all that in Notion, meaning we don't need a separate tool for project planning kind of stuff because it works in Notion.
Then we have meetings. Where do we keep those meeting notes? Well, we probably used some third-party app, but we don't need to anymore. We do it right within Notion. Then it's better because you go to work on a task and be like, "Oh, what did we say when we worked on that last time?" or "Last time we talked, where are the meeting notes for that? Who was commenting on it and giving extra context and information?" Well, it's all in Notion, which is great.
Then there's just general knowledge-based stuff that we need as well like who works for us and what's their phone number - or whatever - in case I need to call them. What's our policy on this? Where's some documentation about how we handle support requests for this? It's all in Notion, whereas that would have been stored somewhere else before.
Sometimes, those things were rather awkward, like, "Oh, it's in this buried Dropbox folder - or something. You didn't know that?" Now it's in Notion and not just in Notion but searchable and easily organized within Notion. That's one of the things I love about Notion.
Thanks for the sponsorship. That's notion.so.
[Banjo music stops]
Chris: I'll end with our last topic because I'm going to hit you with yet another one.
Dave: Ooh...
Chris: This is my strategy is to just mine Dave's brain for things. Actually--
Dave: It's the old free consulting move. No, I'm just kidding. [Laughter]
Chris: Yeah, it kind of is. Hell, yeah, it is. What does Nuxt and Vue generally do for PropTypes? Do you know what I even mean with PropTypes?
Dave: Yes, sir.
Chris: It's a heavy thing in React land and I don't know what the equivalent in Vue is.
Dave: So, every Vue component -- like, you think of a .view file, and then you have a template tag, a style tag, and a script tag. Right?
Chris: Right.
Dave: Scripts is export default curly braces.
Chris: That's where you're going to get your props?
Dave: Then you have a props key, I guess, in this object or class - I guess. It's like props: and you can just do an array in there, like an array of strings.
Chris: Okay.
Dave: Foo, bar, and baz, right?
Chris: Those are the names of the props that are on their way in?
Dave: Those are the names of the props that this thing accepts. That's what it's going to look for when it looks for props.
Chris: And it won't even look for anything else? I suppose--
Dave: Well, if you install Vetur and all the linting tools that you should probably have for Vue apps, it's going to complain about that. [Laughter] It says props should at least have a type. Right?
Chris: Okay.
Dave: And so, then you have to flip that array of props into an object.
Chris: Yeah.
Dave: Then it's an object {}, and then it's like - whatever - foo: and then another object {}. Then you have to say type=string.
Chris: Sure.
Dave: Or type:string.
Chris: So, that's built right into Vue itself.
Dave: That's built right into Vue. I'm not sure. Maybe it could possibly not be a Vue thing, but I think it is built into Vue because I'm using it from the Nuxt side of things. Then you define the type. Then it'll yell at you, and it says, "Provide a default," so you do default null. Something like that.
Chris: Oh, right, right, right. That way, yeah, if you don't pass it or something.
Dave: It's really helpful in bullions. So, if you have type bullion, like is dismissible was one I just did.
Chris: Mm-hmm.
Dave: It's like, well, I want the default to be true. I want it to always be dismissible. But if somebody really wants this alert to not be dismissible, they can turn it off.
Chris: Mm-hmm.
Dave: Type bullion default true, and then there are other things you can do. You can add - I think it is - validator. That's a function. Then you can pass a function that validates the input, the value.
Chris: Oh, nice. Yeah, yeah, yeah. Like a schema.
Dave: Yeah, so now you can basically be like, if - whatever - foo=A, B, or C - however you want to type that.
Chris: Yeah. Some enums or whatever.
Dave: Yeah, you can match it against an enum, so it has to exist in this list of values and, if it doesn't--
Chris: Yeah. Let's say you don't do any of this. Do you still have access to the props or is this your gateway to even getting access to touch them at all? Do you have to say, "This component is dismissible as a prop, I want to access it, and I'm not going to take these extra prop type steps"?
Can I use it, because I'm just being fast and sloppy and I don't care? Or do I have to define it to get it?
Dave: You don't have to. You can. I think there's the idea of children, like dollar children - or whatever - where any sort of things just sort of like -- that's sort of your big slip through gate. [Laughter]
Chris: Yeah.
Dave: Which is kind of how you do it in React, right? You're just like ...props - or whatever - and you just chuck those through.
Chris: Yeah. Kind of.
Dave: But I think, in Vue, what they really try to do is if you want this to be in here and you want it to -- because, in Vue, you have to go through because it's kind of more like a class. So, you say this.foo. In your template, you just type foo. But anywhere in the JavaScript realm, the script realm, you say this.foo.
Chris: Oh, it's not like this.props.vue. It just attaches them right to this?
Dave: Yeah, and so then you could do this children foo, maybe, and that might work. I'm not really feeling good about that.
Chris: It sounds like you generally do define your PropTypes - or whatever.
Dave: Man. Is children only elements? I might have this all wrong. I'm going to actually back out. [Laughter]
You should define your props. You basically just want to say this accepts this.
Chris: Right. It's kind of like -- but is it TypeScript? [Laughter] You know? Is it just like doing this instead of TypeScript?
Dave: Sort of. This is kind of like a faux TypeScript.
Chris: Yeah.
Dave: To be honest, I'm not sure how it totally works in Vue 3, which has a TypeScript background. It's backed by TypeScript, if you will. I could probably just look at Vue 3 props, or something.
Chris: I do kind of dig how it combines the types and the default values. That's a clever little twist.
Dave: Yeah. It's smart. Gosh. Oh, my... My brain is not working. Then they only show the regular way to do it. They don't show the composition API. Anyway... Sorry. [Laughter] It's probably like use prop foo.
Chris: I see, though, that it's just like a first-class citizen of your script, right? You just go props: and then you just say what they are. It is a nice little API.
Dave: Well, I like that it's built into it. I didn't have to go install another library for it.
Chris: Right. You don't have to import anything either.
Dave: Yeah.
Chris: Which is nice. I'm just curious about how because we've made the call. I've been working on this a bunch. We'd be like, "Okay. We used to enforce this. Then we stopped. But let's get more serious about code linting stuff. Let's put it all back."
Okay. Real easy to tell your ESLint in JSX land, "Hey, all props must be validated, and throw an arrow if you don't." Well, then you've got to go back in time and fix all your components. That's going to be annoying. I've been just doing a ton of PropTypes work -- interesting -- and just seeing how different things do it. Is that a moment where you move to TypeScript? We're not going to do that, but just kind of interesting because it's all types. Just all day long... types, types, types, types, types, types, types, types, types, types, types. You know?
Dave: Yeah. Yeah. No, I mean -- yeah. I think it's kind of funny. It's like you gateway yourself, right? You're like, "This is helpful," and then all of a sudden you're like, "We need to do something else."
Chris: Is it so smart that if you call that component with the wrong type, it will know from where you're calling it from? That would be nice, right?
Dave: What's that?
Chris: Let's say you have some modal component that is dismissible. Let's say you called is dismissible from somewhere else in the app and said, "Is dismissible eight." Would it be like, "No. I know that this component has told me that it must be a bullion, so I'm going to squiggle you in this other component"? You think that would be the real value.
Dave: That would be the real value, failing something. I know it does bark in console if you have something wrong.
Chris: Oh, I bet that's what it is! It's a console violation. You catch it as you're dev'ing.
Dave: Yeah, so it's a console violation. I don't think it craps your app out. I think what will crap your app out is you get not a number, and then it's just like, "I died because you--"
Chris: Yeah, because actual code failed.
Dave: Yeah, the 8+ABC did not work, and so that's what fails. Yeah, that's kind of--
Chris: And chances are, your dev tools are open all day as you're working on the app anyway, and so all that red stuff that comes, you're highly motivated to fix, and that's why it gets fixed. Although, it's funny. I think of Axe dev tool's whole move left philosophy, which is like, "Sure. You could have accessibility problems. Your users could tell you what they are." Well, that's way on the right. [Laughter]
You could move it to the left where it's like you test production. Well, you've moved a little bit to the left.
Well, but you could test it before it goes to production on staging. You've moved a little bit more left.
Oh, you could lint it before it even goes to staging. You've moved left even more.
Oh, you could test it in VS Code. That's left even more.
The idea of moving left is cool. I would think that would be yet another move left in this case is if you really did get the squiggles in VS Code when you even type a prop type that's wrong. That'd be cool.
Dave: Yeah. Yeah, and I'm trying to think. No, I don't think it does that.
Chris: I don't think it does.
Dave: Too often, you're dealing with data, like a remote object, and that's where it gets me. I'm dealing with item.firstname - or whatever - or user.firstname, not the number eight. I'm rarely passing actual data. I'm usually passing what I think the data is going to be. You know what I mean?
Chris: Yeah, it probably does this, but TypeScript would.
Dave: TypeScript is weird because, yeah, then you have this big bind between what is going in and out.
Chris: Yeah. Then there's this irony that one of the things that you can say -- and we've moved this direction over time -- is that you should pass. You should do less decomposing of the stuff. If you have an item, you should just pass the item to the component. Then you can really cheap out on your PropTypes and be like, "Oh, that's just an object, and it's required."
Dave: Oh, so you think that's bad?
Chris: Well, I think it's a little bad because it's like you didn't prove anything. "Oh, good job. You passed an object."
Dave: [Laughter]
Chris: What you need to describe is the shape of that object, which PropTypes totally supports. It's just a little more effort to do. Then if you pass it around a lot, you should really probably describe it once in some utility thing. Import that shape and then use it. Then in the ten components you have that pass that item around, you can use that same prop type shape in all of them. It's just a lot of abstraction.
Dave: Well, now I'm curious how that works in React. I will say, in Vue 3, I figured it out.
Chris: Yeah.
Dave: You do setup functions, and you can auto setup. In that, you get a props attribute or a props argument passthrough.
Chris: Yeah.
Dave: Then you can de-structure the props and get the ones you want, like title, body, comments, or something.
Chris: Yeah.
Dave: Anyway, I just wanted to clear that up. But in React, if you're like ...props - or something - does it yell at you if you pass too many?
Chris: Hmm...
Dave: Like if I pass ninja - or whatever - does it--?
Chris: I don't know about too many. Too many is an interesting one. I don't think it would... I don't know. It feels like there should be because you know what I also played with the other day was AJV, which is this JSON validator tool thing.
Dave: Mm-hmm.
Chris: That very much definitely did have an "expect these and no more" values in an object.
Dave: Interesting. Interesting. Yeah, yeah.
Chris: Which was kind of cool. I don't know. It seems like it should. You know? Obviously, if somebody typed out some prop that this other component just wasn't expecting at all, it seems like something you should want to flag.
Dave: I wonder if that creates some inflexibility, though, with, like, HTML. You know?
Chris: The problem is the ...props thing.
Dave: Yeah.
Chris: Because that's pretty common and I like it. I think it's cool because a lot of these things are just HTML bound. You know? Eventually, there's a div or something. If you ...props the end of it, that means that I have the opportunity whenever I'm calling this function to just chuck on stuff, like a data attribute or an ARIA role or whatever. I have that and I don't have to explicitly make it part of the API because I'm just saying, "Here's my props. But also accept whatever because I'm not trying to recreate the DOM. Just assume that I can do whatever the DOM can do also.
Dave: Yeah. Interesting. Yeah.
Chris: Tricky.
Dave: Because you're okay spreading the props, but if you pass props as an object, that would be a wrong-wrong.
Chris: Yeah.
Dave: Yeah. [Laughter]
Chris: No. I'm okay with spreading the rest of the props.
Dave: Oh, okay.
Chris: Because the way it works is, you--
I don't know what the Vue syntax is, but in the Vue syntax you go props: and then an array.
Dave: Yeah.
Chris: That's one of them. At the end of that array, it would be like, "And the rest of them." You know?
Dave: Yeah. Yeah. Okay. Yeah. Vue is more explicit - or whatever.
Chris: Yeah.
Dave: You say :foo=foo or whatever, foo.1.
Chris: Yeah. It kind of looks like you do have to declare them, though. If you want this.foo, you need to do props foo.
Dave: You said passing a giant object. Let's say post, the whole post object.
Chris: Yeah, just all of it.
Dave: You're kind of like, "Just pass it all in." I actually started doing that, and I've started using -- Vue has provide and inject, which is a lot like a React provider, React context sort of stuff. You set provide at the parent component and then inject in the child component. My child, whatever post-author metadata component. I can just say, "Inject post," or in the post component, I say, "Provide post," like all this post data. In my child component, I say, "Inject post," which basically to me means expect post to exist.
Chris: Yeah.
Dave: Like we're going to just use whatever post we have. That actually saved me a lot of prop passing because I was doing all this de-structuring, and I was doing all this sort of like trying to just ship this whole object down and stuff like that.
I just was like, you know if these sets of components expect a thing, if that's in the contract, if I can make a little contract--
Chris: Right.
Dave: This component will always expect a post object.
Chris: Yeah, you can totally do that. But that's data that probably came from a database.
Dave: Yeah.
Chris: I think that's in a different category than my button component. Those props should probably not because you could go that route, too. You could pass in a style object and the style object has properties that are big and full width and have outline and all that stuff.
Dave: Yeah.
Chris: I think it feels better to me to be explicit about those props.
Dave: Right. Right.
Chris: Because it's easier to provide defaults for them and all that. But if it's like, "This stuff came from database," just blast that crap around altogether.
[Laughter]
Dave: I like where we've summed it up. If it comes from database, just blast it.
Chris: Yeah, just blast it. Yeah.
Dave: But if it's the API of the component, like add a border here or go full width or whatever--
Chris: Then validate it more closely. Yeah.
Dave: Then validate it more. Yeah.
Chris: Okay. All right. We solved the Internet again. You're welcome, everybody.
Dave: Another classic ShopTalk Show.
Chris: [Laughter]
Dave: I wonder, moving left, if you move too much stuff left, what happens? Does the machine stop? You know what I mean?
Chris: Yeah. I mean, yeah, you just have a lot more work to do. You know?
Dave: Yeah. Everything -- because then it's like, "Okay, everything is left. Everything is on my computer. All the rules, all the - whatever - legal hoops are on the left side here now, so any time I type a character, it's going to yell at me. Now I'm going to--"
Chris: When it has a problem with bug prevention, moving left is the right place for it, though. You know?
Dave: There's some data. Microsoft. I could find it, maybe. Microsoft Research, who I have worked for, so full disclosure there. They have a lot of good research on technology, computers, and stuff like that. But one thing they have -- there's an article about strong typing and what it does. It's something like it eliminates, on average--just this big sample across Microsoft or something--like 15% of all errors. If you use strong types like TypeScript, is kind of maybe where they're coming from.
Chris: That sounds fair. Yeah.
Dave: Versus just no types, and maybe PropTypes are the middle ground there.
Chris: Yeah, maybe. 7.5% of all bugs.
Dave: But you solve something like 15% of all bugs just by using strong types.
Chris: Right.
Dave: Which, for Dave Rupert, it's maybe not worth it because I don't write bugs, right?
Chris: Yeah.
Dave: Just like I don't do PRs.
Chris: For just types, sure, but then if you're talking about TypeScript, there's other crap that you buy, like all the fancy IDE, auto-fill, IntelliSense, whack-a-doo--
Dave: You get a lot more features, right?
Chris: Yeah.
Dave: Yeah, and so anyway, there are some good details or just good ideas. I don't know. It's maybe a thing you should do. I'm not super zealous about TypeScript. I kind of wonder if it's going to go away faster than I'm going to get to it. We'll see.
Chris: I don't know.
Dave: I don't know.
Chris: I don't have anything in it just yet either. Yeah, I feel a little behind on that regard, but not enough to do anything about it. [Laughter]
Dave: That's the thing. There's sort of like, "Okay, we can jump in, but is it going to super make it better?" I think, for some people who have hit type issues, I think a lot of libraries are kind of starting to use it because they have to accept certain things, like Vue 3 is written in TypeScript. Angular is written in TypeScript. React, I think, is moving to TypeScript - if it's not already.
Chris: What?! Yeah, but there is a distinction there between your codebase and tools that are intended to be used by other people and not look at the source code because you deliver a bunch of value to your users of the library by virtue of it being TypeScript and the API. They're extra incentivized to do it.
Dave: Right, and you're still giving JavaScript to JavaScript users. They still get the same thing. But you get more bonus editor stuff if you're doing that.
Chris: Mm-hmm. All right, dude. Good stuff.
Dave: We'll wrap it up. All right.
Chris: Another famous episode.
Dave: Well, thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show - for real. Follow us on Twitter at ShopTalk Show for 16 tweets a month. Join us on the D-d-d-d-discord, patreon.com/shoptalkshow, and probably some YouTube over on the real CSS-Tricks YouTube channel. Chris, do you got anything else you'd like to say?
Chris: Oh... ShopTalkShow.com.