Component-driven development with Faker.js

Captions provided by White Coat Captioning (https://whitecoatcaptioning.com/). Communication Access Realtime Translation (CART) is provided in order to facilitate communication accessibility and may not be a totally verbatim record of the proceedings.

JASON: Hello, everyone. And welcome to another episode of Learn With Jason. Today on the show we have Jess Sachs. How are you doing?

JESSICA: Hey, Jason. Doing pretty well, how are you?

JASON: Doing great. So happy to have you on the show. I've been waiting a long time to learn from you, so I'm so happy that we've got it going. So, before I kind of jump into what I'm excited about, let's talk a little about you. For folks that aren't familiar, can you give us a bit of a background on who you are, what you do?

JESSICA: Sure, yeah. So, I'm just a free open source maintainer. I tend to go between dev tools companies. Most recently I found a home at Ionic and I'm really excited. I joined there in April. But before that, I worked at Cypress, the end to end testing company and component testing company, which is where I fell in love with Faker. Also been heavily involved with View Core, VCore, quite a lot of projects.

JASON: Yeah, you work on a you have a very impressive and packed with names I've heard of resume in open source. So, what we're talking about mostly today will be Faker.JS and component driven dev. So, before we talk about component driven dev, let's talk a bit about Faker. So, my understanding of Faker is pretty limited. What I understand it to be is it is a way to create fake but plausible data for testing projects. Is that correct?

JESSICA: Yeah. For any project. People use it for data, DevRels use it for demos to create really nice looking demos. And it's also not language specific. It's not just JavaScript, right.

JASON: Cool, okay.

JESSICA: Faker.JS, yeah, yeah, there's a lot of different bindings for it. It's just an idea, being able to create realistic mock data for reasons.

JASON: And I feel like that's such a useful it's a thing that I always want. And that I, you know, I'm always kind of unhappy with my own fake data, because, you know, you copy pasted a million times, you're editing a number. Blog post one, blog post two. Okay, but now every all of my styling is only optimized for three word titles. And I am never going to write a three word title. It's always going to be the maximum number of characters.

JESSICA: Yeah, exactly. And it's very helpful to have things like one of the most common ones I use for testing is the Lorem module. The other thing I use is domain specific APIs, like my other favorite is the BS module. I think we renamed it, but it stands for bullshit, and you can get little buzz words, and you can get phrases that you might say at work that nobody actually likes saying. So, you can get little company tag lines and stuff. And I like to use that one and product names. And it's all localized, as well. So, we support

JASON: Cool!

JESSICA: I had to count the number of languages. That's the other thing that is related to that issue, of just using three words, blog post one, two, and three, is then the moment you add like a right to left language, or a language that requires your fonts to be fixed with fonts, you know what I mean, per character. Things just look different. Yeah.

JASON: Yeah.

JESSICA: I think more than 50, 50 languages. The majority of our PRs, actually. And the bundle size.

JASON: Yeah, fair enough, right. Well, so, okay. So, that is something very cool, and, I mean, I'm seeing a couple folks mentioning use cases in the chat. But I am always very interested in just sort of like how did you come to this project? Because I saw you post somewhere that Faker.JS was created by a group of strangers, and it just kind of sounds like a how did this come to be?

JESSICA: Yeah. So, the origin story of why Faker needed a group of open source stewards is a longer one than how it all came how everybody came together. So, how everybody came together was I think friends of friends, right. So, like I wasn't heavily involved in Vite core, but somebody was, I was fairly active on Twitter, and they reached out. I was in the Boston JS Slack. That's how I heard about Faker needing help. We can talk about the back story if you want. But, yeah, we had somebody I was CEO at I think Gray Core. Damian had the most recent fork of Faker, and we all collectively both handled the fallout of needing a new organization, needing a new maintainer. The repo was deleted, so we had to have a fork of it. So, we took that fork, made an org on GitHub, and collectively made a community control project.

JASON: Yeah.

JESSICA: Everybody worked great together. Most of the team is actually from Germany by happenstance.

JASON: Okay.

JESSICA: I get to speak German. I used to live there, and I never get to speak it, so I'm always excited.

JASON: Cool. That's great. My German is limited to, like, I can say ham and cheese, I'm pretty sure. That's the only thing that I'm a polyglot in. I can speak every language as long as all I have to say is ham and cheese.

JESSICA: Wow, you're a polyglot. Ham and cheese polyglot. Also respect, also respect. But, yeah. The Faker story I'm very proud of, because we swarmed in less than two weeks. We had taken a repository that had no documentation. It had no official docs, had no type support, and hadn't been really touched since 2015, and this was 2020 when this was happening. Sorry, 2022 when this was happening. Wow, time.

JASON: Yeah.

JESSICA: All right. So, it hadn't been touched in seven years, really. And then it was just deleted. And we all used it. Strings don't change, right. Don't need to really update a library much. But documentation was nice, would have been a nice thing. There was a third party person, who was maintaining docs that were mostly correct for the library. Like mostly. Yeah. It was pretty bad. You would have to memorize the differences between the unofficial docs and the actual implementation when you used this library. So, we swarmed, and the whole thing was rewritten in TypeScript within two weeks. And, you know, official type support. Official documentation. Code gen documentation. It was treated with love and care, as it should have been.

JASON: But, I mean, I think that's such a cool example of what we want open source to be, right, is it's a thing that is useful to everybody, and when it needs maintenance, people step up and do that. You know, they make it accessible to the community again. And, so, that's great, especially when, you know, we see kind of other instances where it goes the opposite direction, where things that really do need maintenance, like nobody will prioritize the time to do it, and you end up with these great projects that just sort of fall into disrepair. So, let's talk about I know that we're going to go a little bit shorter than usual today, so I want to make sure I keep us moving. Let's talk about a bit about component driven dev, then I'm going to move us right into code. When you say component driven development, what my brain did was like, well, isn't that what I already do, where I make a component, and then I stick it into other parts of my code? So, when you say that, what do you mean by it, and sort of what's the strategy that you're going for?

JESSICA: So, have you heard of test driven development, right? That's a rhetorical question. Yeah. So, it's kind of like if you think of your components as functions, right, they have a contract. They have props. And some frameworks they have different ideas, like events in Vue. Really, they are like callbacks to a function. So, if you think of components as functions, you're trying to test that function. And it happens, happens, that many components are headed. And many components want to be rendered with CSS and styles, right, nobody is writing in Times New Roman. Component driven dev is isolating each component into its smallest pieces and putting it on a web page. Putting in resizable containers, making sure it smushes correctly, now that we have container queries, that becomes a much more satisfying experience. Smush is the technical term.

JASON: Smush is. I really wanted to yes, I love it.

JESSICA: But, yeah, scales correctly. So, component driven development is starting at these leaf nodes of our design and bubbling up all the way to the top of our component hierarchy. So, you can test everything from presentational layers, through container components, things that depend on GraphQL. You can test you can component drive most of your application. And then at the end, which is probably what you think you do at the beginning, I think I do this already. At the end you stitch it back into an application in its entirety. But you've isolated out each component already so that it's easily testable. That's the difference, is that you want to be able to mount the component in each contract you expect to use it, versus just being like I'm sure I'm going to want to have a small, medium, and large, but I don't have an app screen that needs it right now.

JASON: Right. Yeah. I feel like that's such a pitfall that we can land in, where we end up with, okay, I have a component, and, so, instead of building the app, I'm going to take a week or two to build out 9 million permutations of this that we don't actually have a use case for, but I love this idea of thinking about each because what you're basically saying is treat each component like a tiny little website, and make sure that in isolation it works. And that's, you know

JESSICA: And in German make sure it works.

JASON: Right.

JESSICA: Spoiler.

JASON: I feel like when you're saying... when you're saying to do this, originally wasn't following what you meant, and as soon as you said it, that common sense, oh, of course. This is what we always want. When you get told to debug, well, make the problem as small as you can. How can you turn off as many things as possible so you're just testing the one piece of logic and make sure that works, add more, add more, and finally see where the bug is. Why not do that with UI? This is a very logical way to solve that problem.

JESSICA: Yeah. If you take a virtualized list, for example, that's streaming data in, that's a lot to think about, right. You're building a dashboard or something like that, that needs to scroll, I don't know, Twitter or X timeline, you have to think a lot about asynchronousty and not thinking about the contract required to make your virtualized list work itself. Not thinking about the network layer, right. So, you end up thinking about the problems in isolation, versus in the context of your app. And being able to debug at each level, versus, you know, the whole app at once.

JASON: Absolutely. Well, amazing. All right. So, in the interest of time, I'm going to push us over into paired programming mode here. So, let me make sure I've got the right things up on screen, and then I'm going to switch us over. All right. So, first and foremost, this episode, like every episode, is being live captioned. We've Ashly here from White Coat Captioning, thank you, Ashly, and that's made possible through the support of our sponsors, Netlify and Vets Who Code. Thank you very much to both of them for making this work. We are talking to oh, no, there it is. We're talking to Jess today. Make sure you go give a follow on Twitter, and all those good things. And we are talking about Faker, as well. And then for component driven dev, I wasn't sure if there was a specific link you wanted me to throw around for everybody, or maybe a blog post or something.

JESSICA: There's actually a website championed by the team at Storybook. It's component I'm going to mess it up, like .org I think. TLD is one I don't usually use. Let me find it. Find it before I did?

JASON: Component driven user interfaces.

JESSICA: Sorry, Arc was being weird, autocorrecting for me. Yes, component driven user interfaces. So, there is an open standard that they championed called the CSF, the component story format, but it's basically the idea you should be able to render something in isolation on to a context, whether that's inside of an iframe, whether that's in a project we might put together and do one component at a time. You can component drive your development, so long as you're building the individual pieces one at a time. As a side effect almost, it becomes very easy to test once you've done that. I call it accidentally testable. Component driven development makes it really easy to test everything.

JASON: I think that's a good thing to point out, is like as you're choosing, like, how you're going to build things, that accidentally testable component is such a big deal, because it's so easy to talk yourself out of writing tests if it's not kind of part of the default, like out of the table stakes. And then the other problem that I've noticed is this happened to me was the opposite problem, where we had written no tests when I was at IBM, and then we decided that we wanted some testability, so that we could be more confident about shipping, and I got into super nerd focus mode, and I couldn't stop writing tests, and I was like I'm getting 100% code coverage. And because the code was so messy, I ended up I wasted so much time trying to test these weird edge cases that were hard to test because of the way the code was architected, right.

JESSICA: Yeah.

JASON: So, I love this idea of make it testable through the architecture, not go figure out how to do whatever loop deloop you did in the code because of the test.

JESSICA: Sometimes you can even just write the documentation, so I pretend I'm going to write internal documentation for how to use the component, and sometimes I component drive in Vite press, for example. Doesn't matter where you do it. You can do it in docs and write the code snippets for how you would explain to a coworker how to use your button, or how do I hook up A to B, A component to B component. Should the state be passed in. Have these conversations with yourself as you're doing component driven development. But just think of the Slack message you write when you explain to your coworker how to use your code. That should be how you mount your component. And from there, testing it, depending on your library, is actually not hard. It's just the mounting that's hard.

JASON: Sure. Excellent. I'm ready. I want to try this. So, if I want to get started, what should my first step be?

JESSICA: So, if you want to get started doing component driven development, you want to go into your project. Whatever project you may have. I'm speaking to the audience, right. Whatever project you may have. And you want to get an environment up. That environment could be a Cypress component testing thing, a playwright component testing thing, or for our purposes, we should probably just create a Vite sand box. So, let's go and create a Vite sandbox in whatever language you'd prefer. I'm very, very bad at React.

JASON: I will do it in Vue. NPM create Vite. We're going to call this project component, if I can spell it, driven dev Faker.

JESSICA: Big callout, by the way, to Storybook. If you have a Storybook project, you can you're probably already doing component driven development actually. Probably just don't know it.

JASON: That's what I was thinking about as you were saying that. Render it in isolation, make sure you can see all the variations. Yeah, that is what Storybook does, but I didn't want to derail us.

JESSICA: Yeah, that is the correct way, yeah not the correct way, but that is an environment you can play in. Let me make the window bigger.

JASON: All right, so, I have brand new project. It is a Vite Vue TypeScript.

JESSICA: Okay. So... how are we going to do this so that it feels right? We're going to overload your app, and we're going to pretend like it's the Storybook container or the docs site. So, we're going to basically treat your app like a docs site. So, you can maybe make an H1 tag and be like Jason Lengstorf's component driven development exploration.

JASON: See how many times I misspell today. There's our H1.

JESSICA: Cool. And let's think of some components that we want to build. So, we can either go one of two ways. We can go presentational, or we can go network. Like app style stuff. What do you want to do? Presentational is going to be easier.

JASON: Do you think we have time to do both? Let's start with something presentational, so we can see, you know, this is kind of how it works most easily, and then we'll put something together that would pull from an API, and then we can use Faker for that. I guess we can probably use Faker for both, huh?

JESSICA: Yeah, yeah, yeah, yeah. Yeah, we'll use Faker for both. Okay. So, what components are we building? What components are we building?

JASON: Maybe a maybe like a card component. That seems like the standard of everything that you would need. And then, yeah, I think that could be good. Maybe like a

JESSICA: Go from there, then we'll fetch in some products from a list. All right. So, we'll do three components. We'll do a card, which will be our lowest level. Let's make it can I speak in high level, or do you want me to go line by line?

JASON: Help me with the first one, because I haven't written Vue in a bit, then you can go high level.

JESSICA: Yeah, so, let's make a template tag. Then we're going to do div hello world.

JASON: Is that like a

JESSICA: Sorry. A div and then hello world inside of it. It's just HTML. Nice. Then below you actually don't need to do anything else. So, let's start up Vite. Did you use NPM? NPM run dev, I believe. Yep. Boom, I love it. So, we have our app component rendering. That's going to be our top level at any given moment, but we're not going to start there when we're building. We're going to start on our leafed ends, start on our card. So, let's render the card inside of app.Vue. We're going to do that by importing inside of the script. We're going to say import card from./card.Vue. Perfect. Then just render it. Love it. And we should get a hello world. Very nice. We can I'm so used to Tailwind. We can start just styling it. So, we have our hello world component here. And let's go ahead and make the architecture for the card component. Also, let's reset all the app we'll get to styles in a second. It's actually kind of interesting when we get to the networking stuff, it will get interesting. So, we'll keep the app page styles. This is a very important point to make, actually. In component driven development, if your sandbox, be that, you know, Storybook or Cypress or Playwright or whatever, your docs site, if that main .CSS that you expect to be imported is not there, you will build things completely incorrectly. You'll build things with like the wrong body height or something like that, and once you go to integrate your, you know, components that you built in the sandbox into prod, into your app, you'll be like, oh, goodness. Very important to make sure your main CSS is imported when building your components. Let's go into card view and let's pull up the Faker docs. So, we're going to play to Faker's strengths. It's really good with products. So, if we go to the API... type in products. We get a lot. You can just scroll through the whole

JASON: Let's do a quick roll here. Animals, colors, commerce, companies, databases, finance. This is dope. Plausible fake data. Address data, which is good to have.

JESSICA: Localized address data.

JASON: So good.

JESSICA: And the IPV6 stuff, finance information. It's... yeah. Everything from silliness, to domain specific stuff. You should be able to get anything you need from Faker. Or a combination of Faker things. It also exports kind of a mustache templating things. So if you need a mix between your custom stuff, so Cypress does this, when Cypress was component driven developed, the rewrite that I did for Cypress, you know, we have a lot of file paths and stuff like that. You can mix all of the window style file paths that you might have with the Unix ones when you're testing out your list of files, for example. Really versatile. So, we have a product, which gives us a string back, we have a product adjective. Let's come up with a contract for our card that seems e commerce y.

JASON: Install Faker first, right?

JESSICA: You do, yes.

JASON: Okay, Faker, or Faker.JS?

JESSICA: It has a name space. It is @Faker js/Faker. That's so we can extend it later on. Generally, it should be a dev dependency. It's about 10mgs.

JASON: Oh, geez. Let me un install, then we will do it again as a dev dependency.

JESSICA: Yep. Strings. They don't compress.

JASON: Fair. So, now we have I need to write a script, and what's the Vue, it's like an attribute, right. This one.

JESSICA: Yep. Yep. And then you're going to use Vue three style, like if you were writing TypeScript, but it works in JavaScript. Define props. As a function. So define props is, there you go, capital. It takes an object. If you're using TypeScript, it would take an interface or a type, but we're not. So, let's just say product name as a string, and we're going to use runtime string. We're in JavaScript, not TypeScript. Primitive, excuse me.

JASON: Like that?

JESSICA: No, just the data type string. String, capital S.

JASON: Getting there.

JESSICA: Now

JASON: I added TypeScript. We should be okay.

JESSICA: Yeah, then let's do this in TypeScript. So, Lang TS is what you need on the script tag now. So, Lang is TS.

JASON: Okay.

JESSICA: Perfect. So, the syntax now is going to be define props takes a generic. Triangle brackets instead of the parentheses. Define props is going to take a generic. Perfect. And take off that then invoke it, please. There you go. Cool. So, the H2 tag. Maybe let's use the product name instead.

JASON: Okay. And to do that in Vue is it a curly brace like this?

JESSICA: Just double curly brace. That's the only difference really between React and

JASON: Only difference. Basically the same thing.

JESSICA: I don't know why people no. It's all HTML, really. So, yeah, just save it. And let's go back to our app. And we shouldn't get anything, because we don't have any default values set for product name. Let's use Faker. Yeah, let's use Faker. And make one. So, at this point, our app is still we're considering our app our documentation site or sandbox, right. So, we might decide to say an H2 tag in the app should be card. And then we'll render a bunch of different cards with a bunch of different product names, maybe in German and such. So, let's go to app. And card now is yelling at us, because we're in TypeScript. Actually, this is a nice Vue thing, by the way. Velar doesn't really care if you're in no, no, you have line one set to TS. Anyway, let's import Faker for the first time. Yep. Yep. Cool. Let me find I think it needs to be a curly brace import. We removed the default export. Yeah, if you want to hover over it in the type school will work. Perfect. So, we should be able to call Faker inside of the card. You can just use a const there, yeah. Let's do const product name. Equal to Faker. Commerce product. And then in Vue, that's available globally with script setup. It's just a nice convenient way. And in Vue, when you want to make something yep, you got it. Yeah. That's the main difference. And then quotes. So, yeah.

JASON: Right, because when you preface with one of these, this becomes the JavaScript bit.

JESSICA: Yeah, that becomes the JavaScript bit. That's so that we have good support for native HTML. So, a lot of pass throughs in Vue, you have to redefine them in React, like you have to redefine the props. In Vue that passes through one of the reasons. But yeah, we have a product name now, we have a mouse. Get a mouse. Say that our mouse maybe should cost something, yeah? So, let's make a fake price and add the price prop.

JASON: Okay. And we... do this as a number?

JESSICA: Yeah.

JASON: Then we would want that to be like a you can do.

JESSICA: You can label it if you want.

JASON: Are we doing like a number format thing, or what's the right way to handle this?

JESSICA: It's going to give you realistic looking data. So, we're not going to format it, not going to do anything fun. It's just going to give you a realistic looking price. So, let's save that little buddy. Yep.

JASON: Under commerce?

JESSICA: Yep. Commerce commerce was right. Commerce had price on it.

JASON: Price, there it was, yeah.

JESSICA: They all use each other internally, by the way. So, I'm pretty sure price is going to give you like a let's see what we get off of here.

JASON: Gave me $6.68.

JESSICA: Perfect. So, let's see, we can add currency if you wanted to add the localization there. So, we could go back into that finance method again. And it takes arguments, by the way, if you want to make things min and max. If you have an over price, if there's things that are unreasonably.

JASON: Oh, cool.

JESSICA: There we go. Symbol, I think is a Boolean, yeah?

JASON: Oh, yeah?

JESSICA: I think so...

JASON: It wants... option, symbols, string.

JESSICA: So

JASON: I can tell it.

JESSICA: Yeah. You can get the current locale out, and then use that symbol. So, you could have gone to the commerce API. So, if we were going to do this for localization. And we'll notice that as you save, it's changing the price and everything, yeah. That becomes a problem in testing when you want the same results and you want snapshot testing over time. So, there's an API called seed. If you do Faker.seed at the top. You're going to say one maybe, and that makes it deterministic instead of random. That integer there.

JASON: Every time I load, doesn't change. But if I comment this out...

JESSICA: Or use it for a different number, yeah.

JASON: Right. So, you can... the seed sort of tells it where to go and keeps it right there. That's great. And if I remember correctly that so this also does when you seed, every time we call it, it's kind of starting from the same seed number, but not giving us the same one for every call. So, right, so every time we call it, it will give us the next one in the sequence, but it will always be the same sequence as long as the seed number matches.

JESSICA: Correct, yeah. So, if you were to render and also TypeScript is telling us we did it wrong, because it isn't a number anymore. We made it a string.

JASON: We did, didn't we?

JESSICA: We did. So, let's render another card just to show that off maybe.

JASON: Okay. Not like that we won't. So, we got another one. Should I just

JESSICA: Don't need to. Don't worry oh, oh, oh, yeah, yeah, yeah. If you want to map over it, just make const products. Or whatever you'd like to do.

JASON: Yeah, let's do it the right way.

JESSICA: Yeah, because then what becomes really nice is if you make a shit ton of products, you can slice them and grab like ten, and then you could easily go back and grab 10,000 if you were trying to test how lag y it is.

JASON: Got it.

JESSICA: That's the power of Faker and how much data it can produce. You can quickly component drive if your virtualized list will handle zero you know, will handle nothing, a few, many, or a lot of data. Stylistically. So, const products, you know, let's what's your favorite way of making a lot of something?

JASON: I feel like I would probably make like an array and then just do like, you know, give it whatever length and just map over it and do whatever I want, right?

JESSICA: Yeah, basically.

JASON: Whether or not I can do that from memory is a much different question. Array length, let's give it array length of 100. And then map. And then it should be item, and we should be able to return the product name, and I'm just going to pull this part in.

JESSICA: Oh, I found it. Here, it's with fill. New array. New array.fill and then map. I'm trying to pull up the box.

JASON: Takes a value of any.

JESSICA: Medium articles of powering the world until ChatGPT does

JASON: Will this work?

JESSICA: Fill with null and then map it. JavaScript's beautiful.

JASON: Am I doing this right, V4 product in products.

JESSICA: Little different from salt and solid. V4 is a directive, so like an attribute on card.

JASON: Oh, easier.

JESSICA: Only need to card. You don't have a pseudo existing element. You do it in Vite. Pseudo existing attribute.

JASON: Got it. And pulls it's going to be product.product name.

JESSICA: You can also do structure if you so choose. But yeah. There you are. There's all of our products. You can see the products currently is being laid out. You can see a bunch of things. Add a border, because it's very easy now to see layout. This is the second fancy part of fancy. Helpful part of component driven development. So, you can see now who owns the container. So, if when you're making a component and you have a style design choice, part of the API of a component is the style. Is the parent going to own the margin, is the child? Is the parent going to own the padding, is the child? So, you can say the parent app is now the container, and it's responsible for laying out or being able to lay out all of the cards in a grid view. The card doesn't really care about what's going on around it let's say.

JASON: Sure.

JESSICA: So, let's say now we're going to style the app realistically. And give it a grid probably.

JASON: So, we'll do like a div class products, get that out there. And then in here we can do products and we'll make oh, my goodness. Did this thing where I remapped my keys and I'm not sure I'm happy about it yet. Set this up as a display grid. Display grid, template, columns.

JESSICA: 3FR or something. Or fixed, yeah. Let's...

JASON: What's the one where it does auto it's

JESSICA: Min max 180 pixels to 1FR. I think. Or am I thinking the auto fill? I'm thinking auto fill, aren't I?

JASON: Yeah, what's the auto I'm doing this wrong.

JESSICA: I always have to look.

JASON: I'm going to do this like this instead. I know this one off the top of my head and I know we're short on time. That works. Then we'll say

JESSICA: Good wrap is true.

JASON: Wrap is wrap. Here we go.

JESSICA: Beautiful.

JASON: You know what, good enough.

JESSICA: Basically, basically. But we can see where the responsibilities lie, right. Everything in the red boxes are a problem right now as we're building our card. Everything outside the red box, ideally, should work. We do want to say that the card should take up the available either should be fixed or it should take up the available width. Right. So, I think we want to make this product... yeah, you're doing it. And we're going to say width is full, give it an intrinsic width. Sorry, 100%. Let's see. Why am I bad at styling CSS live? Let's see... two ways we could do it. Huh?

JASON: I would probably hit this with a, you know, a width of like min and we'll give it 200 pixels, and that way it will kind of force this way, but then if we make it teeny tiny, it will I guess it still whatever, it's close enough.

JESSICA: That's the parents' problem, not our problem. It's the parents' problem. So, we have our towels, we have our chicken, balls, and hats. Yeah, you're making it pretty. But this is good, though. We have our products, and we have our app. And the gist of it is that... let's see, what else do we want to do? Give me a hot second. How about break the styles. That's what we're going to do. Use Faker to break the styles. We're going to use a long word. So, instead of using a product name, we might fill it in with products, which is nice for demos sometimes. But sometimes you want long products. So, you could just add multiple words, or you could switch out of the domain context and really go for just testing the styles instead of demoing it. And do a Lorem. So, I use the Lorem module the most when I'm trying to break styles. Pick a, you know, line slug text, words, words of like five is probably good. For a product name, yeah. Words, you can do min/max again as an object.

JASON: Oh, cool, okay. Min of let's say 4, and max of we'll say 7, and that should break it for sure.

JESSICA: Yeah, that will make the overflow just like terrible.

JASON: Yeah.

JESSICA: This is when you call your designer, hey, I put more words in.

JASON: So, I did a thing, and you probably want to look at this.

JESSICA: But this is the aha moment of component driven development. I know we're doing a very cheap and dirty version of this, but you can imagine putting this entire workflow into a test situation, a headed test. So, using Cypress component testing or Playwright or Storybook, you take this workflow, you take Faker, and you start developing your components there. And you don't worry about the parent generally, but you call your designer more frequently, basically. You call your designer and you're like do we want the price at the bottom or the top? Do we want it, you know, how do we want to handle overflow? Do you want dashes between your word breaks? Yeah. You start asking yourself a lot more styling questions at this point when you're talking to your designer. Like that looks not great, but you can get some confidence as you're building, right.

JASON: Right.

JESSICA: That your stuff is going to look okay.

JASON: You can just start kind of you sit with your designer, you want it like that, what do you want this to do? And I think that's a nice I had a really good call once with Dan Mall and he talked about this. When you build like this, you are shortening the feedback loop, where you are increasing the opportunities to just high band width sit with a designer and solve a problem instead of the sort of waterfall process of, well, designers throw a design over the wall, dev has to deal with it, designers deal with it later or maybe it ships to production.

JESSICA: Exactly. You shorten the feedback cycle and you find the bugs before you even get to the point of saying like are we using Axios or making decisions about network layer stuff. So, you end up finding maybe that you're not building the right thing even. Or the right design. You kind of approach it differently. It's more product focused. And technology focused, I think. Let's see... a lot of time I spend developing components is actually handling overflow and handling the CSS cases that maybe weren't important. That's very helpful. Okay, cool. So, let's see. We have no test library to show how easy it would be to test and pass in these props, but the TLDR is we would have done this perhaps in something like a test runner that's headed. So, now the step between testing our card and developing our card would be basically nonexistent. It would be two method cards. It would be .contains product name that I just used and should be visible, and .contains price should be visible, and that would be our test. The difference between when you write the code and how easy it is to test, you shouldn't even feel it. If we added an event, let's say, if we wanted the parent to be notified whenever the card was clicked on, we could do that really quickly. That's kind of a method callback. So, in Vue, you use the at notation right after class. You use @click, and say dollar sign emit product selected. That's going to be that should be computer friendly. So, either camel case it or cabot it. Should be computer friendly. Let's save that. There's a TypeScript definition for define emits. We're not going to do it.

JASON: Okay.

JESSICA: But that would give us type safety. And now we can bind to we can bind to the card and say at click equals

JASON: Wait, am I doing something

JESSICA: No, you're

JASON: Need a bind?

JESSICA: No, at click. Yeah, so... sorry. Sorry. @productSelected. Sometimes live coding thank you, Valar. So, if we were testing, if we were testing, we would be, you know, making sure that a spy was invoked with a certain argument. Right. So, if we were testing, that's kind of what you would do. If we were in a sandbox, you might say like emit to whatever Storybook API lets it show up in the console. For us, because we're building a theoretical docs site for our card component, we might tell the developer, like, card was clicked.

JASON: Like that?

JESSICA: I don't know if console will work. Used to not, and I do not remember. Perfect.

JASON: Hooray!

JESSICA: I got in the habit of using window methods inside of templates. But yeah, console log was clicked. So, when you're in like a docs site if you're using component driven development in a docs site, you would tell a developer something. A really good example of this, because we're short on time, is if you go to Vueuse.org, I believe, yeah. And go to functions are cool, but go to the search and type in infinite. So, command K.

JASON: Here we go, infinite.

JESSICA: Might be called virtualized, but I'm looking for the infinitely scrollable list.

JASON: Use infinite scroll?

JESSICA: Yeah, perfect. How about the virtualized one? There should be that one has reactivity. Use virtual list. Yeah. This is what I built. You can filter the list by size or whatever, and you can below look at the contract, kind of like the usage. So, when I'm doing when I built that, I did it in the docs site. There's a playground component that exists that exercises the usage of the virtualized list. It exercises the composable or if you were in React, you would exercise the hook, which is a little bit it depends on your framework how you would build a playground component. But that's how this would end up looking if we were doing it for realsies. We went ahead and did a very quick and dirty demo just to demonstrate calling back to what I said at the beginning of this live stream, the functional nature of a component. But practically, what you end up building is something like this. So, that's the power for me. Yeah. Sandbox. Huh?

JASON: I was just going to say, this is super cool stuff, because I can see how quickly this, you know, doesn't feel that different from how I build components anyways, so with a couple small adjustments to the way that I'm building, we have a much more robust component coming out of the build process. And we have this very short path to testing. And also documentation. Like, with all of this that happened, this doesn't look like it took much more than, okay, this is what I built to show my components, so I'm going to put that on the page. And, you know, are you even is this even like custom written, or is this being pulled out of your implementation and kind of generated for you?

JESSICA: Yes to both. So, it if anybody's ever looking for a great way to build a library, the VueUse tooling is phenomenal. So, yes to both. If you piped over to the source and looked at all of the scripts that the team puts together in the scripts section, I think... yeah. Top level scripts. Yeah. The way that they ended up doing all the any library author watching this, this is my reference for when I'm building if I need to do something interesting to pull out from JSDoc or whatever. So, yeah, I love the tooling that they put together. That team is amazing. So, what we didn't talk about was we just talked about presentational components for a while. We didn't talk about two things. We didn't talk about language switching, which you can do very, very quickly on the right side if we pull up our sandbox again. We can just flex it. There we go. So, let's go maybe change it back to the product, because Lorem is not localized, doesn't need to be. Then we can switch the locale of Faker. Product name.

JASON: This out...

JESSICA: I think it's on commerce, not product.

JASON: Right, right, right. Sorry.

JESSICA: So, Faker dot so, I think we nest the locales, so you're going to import it. Let's look at the docs really quickly. It's like at the top level of the Faker docs.

JASON: Okay. Faker, top level.

JESSICA: Should talk about locale very, very quickly. Yep. So, we're going to say Faker.locale, I believe, will let us do it. We might need to instantiate a new instance of Faker. Deprecated.

JASON: Oh, so you have to pull in the different version?

JESSICA: Yeah, yeah. We do this because of package splitting. We changed this very recently. Yeah. So, you can pull it in from German, if you so choose. Then you can instantiate with different locales.

JASON: Okay. Just to show this, we'll do this. Then I'll get rid of this bit, and then we should see

JESSICA: If you change the import, yes. So, you didn't change the path of the import to be DE.

JASON: Oh.

JESSICA: Locale. Yeah.

JASON: DE.

JESSICA: I think locale there you go. No? Did I pick the one that we have

JASON: DE

JESSICA: No, no, no, you had it right. I think I picked one that didn't have localization. Addresses and stuff do, but there are some modules that we don't localize because of the size constraint, because we have 50 of them. Maybe German is one of them.

JASON: Okay.

JESSICA: Okay, I'll ignore that flex. That was a fail. This is live coding.

JASON: Back here, here.

JESSICA: It's likely that just products aren't localized for German in particular. But we have but the addresses are definitely localized. Okay. So, that was the one thing, was localization. We didn't touch on container components. We're a little over. Do you have a little more time?

JASON: I mean, I have all the time in the world. 29 minutes, to be exact.

JESSICA: Do you want to

JASON: It's up to you. If you want to demo it, we got time. If you have to be done, we can also be done.

JESSICA: I can talk about it and maybe the audience will understand. So, we did a bunch of stuff that was presentational in nature, right. We didn't touch any network layer, right. So, usually, what would happen is you would have a card list. Maybe the card list would be eventually a product card list. And that product card list on mount or whenever your application deemed necessary would eventually make an API call. Or, you know, set up some sort of connection, data store, fetch a thingy, fetch a lot of those products that we're currently passing in from app or, yeah, rendering from app. So... what component driven development forces you to think about is if you're going to, one, where you're going to put state, and it helps you figure out, hey, the product list is going to is going to be responsible for the network layer in state. So, that's the first thing you're thinking of. That might be obvious to some people. It's a thing you learn fairly early on. But when you're testing the product list, you're going to mock the network. And back in the day, we used things like Axios mocking in Jest. Nowadays what's kind of in fashion and VTest also has a browser mode. It's very experimental. It technically renders 3JS, but you can't do real clicks and stuff with it.

JASON: Okay.

JESSICA: Or full page navigation. So, it has a lot of limitations at this point, which is why I'm still using Cypress, which I will move off of as soon as VTest has a stable browser mode. But the fashion, the thing that's in fashion right now, is mock service worker. And it's fairly portable to every single environment. It's a little heavy weight. MSW, yeah. Mock service worker. And it gives you express level control by intercepting a request with service workers. It's pretty cool.

JASON: Oh, cool!

JESSICA: And that's where you put your Faker stuff. First names, your last names. That would all contain Faker.person, or Faker.name, right. That's where you would put your fake data.

JASON: Yeah, okay.

JESSICA: I will say, it also has a GraphQL API. I will say, while mock service worker is popular, I really prefer the Cypress intercept API, and I'm hunting for somebody who's going to somebody posted on Twitter asking if mock service worker, if anybody had gripes about it. This is me patting myself on the back so hard that my shoulder hurts. This is the first thing I designed when I was at Cypress. It's just much more intuitive, you know, you're trying to very simply, you're trying to take an URL and return some JSON. You don't have to and you can also write the express style syntax, so you can eject to the lower level stuff if you're doing stuff with web sockets or GraphQL. But, generally, you want to be able to respond with a bad status code, you want to wait a little bit if you want to test out in component driven development. If you want to test out the loading state for two seconds, Cy intercept, with a response of two seconds. That's I really like this API. It's one of the reasons I still develop in Cypress, even though Cypress is very slow and heavy. When I need, it has what I need very quickly. I don't have to write a lot of boilerplate. Anyway

JASON: Got it.

JESSICA: Those are the two ways you would start to mock the network for your container components that start to care about the domain model.

JASON: Nice. Okay. Well, I know you got to get going, so why don't I do another I'm going to toss everyone to the Faker site again. And I will also pass one more link to this component driven user interfaces site. Is there anything else that you want to make sure we reference as a resource for somebody who wants to do more?

JESSICA: So, for people who want to do more with Faker, we really want contributors. We have some great contributors, but we really love open source, right. There's a reason the team got together, the community got together. So, please come to chat.Faker.JS.dev and join us in the Discord. We have really great outside contributions. Most recently, we got the random color module that just gives you a random color, which is very convenient if you're in code sandbox and you want to demo. And I will also I'd also like to give a shout out, if possible, to Indeed, who sponsored the project twice for a total of $20,000, and that was that's what funded the project. I think I took $20 total out of that. Yeah. So, huge shout out to Indeed and the open source contributions. And also huge shout out to Airbnb, who's been giving us $50 a month, and it's been really helpful. Yeah, we have an open collective, opencollective.com/FakerJS if you want to see all the companies that sponsored us. Really helpful. That's all I got. Team is extremely responsive if you ask in Faker.JS in the Discord, you will get responses. And we'll be excited to hear from you.

JASON: Awesome. Well, thank you so much for taking time and teaching us today. You can all go follow Jess on Twitter. And go check out Faker, go build some of this stuff, and let us know how it goes, how you feel about it, and whether or not you feel like it's making your applications better. This episode, like every episode, has been live captioned. We've had Ashly here from White Coat Captioning today. Thank you so much. And that's made possible through the support of our sponsors. We've got Netlify and Vets Who Code, all kicking in to make this show more accessible to more people. And the schedule is not updated, but there are more shows coming. I'm going to get them up this week. We've got great stuff coming up. We have folks like Kravitz coming on, and we're going to learn about CouchBase and all sorts of good things. Make sure you're checking the schedule and add it to the calendar with this little button right there and get reminded when we go live. All right, y'all. That's it for today. Jess, any parting words before we call this one done?

JESSICA: No. Thank you. Thanks, everybody, for coming and watching. Thanks, Jason, for having me on. Thanks, Ashly, for doing the captioning. Yeah, that's all I got.

JASON: All right, y'all, we're going to find somebody to raid and we will see you next time.