Kate: Hello, welcome to PodRocket. I'm Kate, the producer of PodRocket. With me today is Michael Chan, formally known as Chantastic on Twitter and Discord. Michael, how's it going? Michael Chan: It's going great. So happy to be here again. Kate: Thanks for joining us again. You were on back in November and we talked about The React Podcast Michael Chan: And we talked about Community and Discord and all the cool stuff happening there. Yeah. That was fun. That was a lot of fun. I had fun that day. Kate: Yeah, but now we're going to be talking about Storybook and Chromatic. We can also talk about Community and all the fun stuff too, but yeah, maybe just to start, kind of tell us about your role, and kind of what you've been working on lately. Michael Chan: Yeah. In September, I guess just a little bit before I came on that PodRocket episode, I joined the team at Chromatic. Chromatic is the company who maintains and builds Storybook. I joined and I think technically, my role is something like DX Community Engineer. Honestly, I don't remember. What that means, I guess in the abstract, is that I help people understand how to utilize and use Storybook. And mostly my part of that is doing that through media. Michael Chan: So I have a show on the Storybook YouTube channel called Storytime With Chantastic, where I just interview people who know a lot more about me, in terms of design systems, front end engineering, kind of like what's happening in that space, and ask them what we should know about building design systems, both like, Storybook, Chromatic, and then as an industry, what we can learn from this stuff that's happening inside of the space, inside frameworks, all that kind of stuff. Michael Chan: So tons of really cool interviews over there. If anyone is interested more in this stuff that shows fun, we have, I think like three episodes now, and it's just like a monthly interview. Super cool. Super fun. But yeah, that's mostly what I do, building up some, Egghead courses to help engineers understand the value of Storybook as a testing tool. That's effectively what I'm doing these days. I guess that's one definition of what a DX Community Engineer means. Noel: Nice. Yes. Do you find that your role as a DX community engineer, do you think that's specific to kind of Chromatics' situation where maintaining this open source tool, like Storybook's open source. Is your role kind of intrinsically tied to that, or could you see similar roles to your own, like a more traditional proprietary software company? Michael Chan: Yeah, that's interesting. So there has been some spontaneous evolution at other companies. A good friend of mine, Dometrius Clark, over at Netlify now, also joined the Netlify team as a, I think similar, if not identical, title of DX Community Engineer, which we have a pretty good laugh over that because neither of us understood what it meant, but we both got jobs with that thing. I think it kind of maybe means we don't know what you do, but we want you to keep doing it here, which is, I don't know, maybe a good place to be. Michael Chan: It's like a... what is it? Almost that like intrapreneur kind of like mindset, like, okay, so you understand media and community and just keeping people happy and interested. And at one point, you programmed, so like this is your bucket now. But yeah, I kind of like it. I kind of like ambiguous spaces, as I'm learning. I like staring into the fog and then trying to put shapes together and figure out what's on the other side. I'm into it. Noel: Yeah. I guess what led me to my question is, I feel like it's kind of a pillar of open source in general. It's like, "Oh, well, we'll have this organic community built around it. The thing will advertise itself, and we'll have involvement with all these people and everything will be very transparent." Do you think about that a lot in this role or figuring out, trying to discern those shapes in the fog, does Storybook being open source, kind help you in that regard, or do you have to keep that in mind? Michael Chan: Yeah, that's a great question. So Chromatic has a really fun DX team right now. Chromatic is not a big company. I think as of this episode, we're at about like 24 people, and just a few weeks ago, it was like 18. So super small company, doing a lot of stuff. Five of us are on the DX team, and it's been really fun because everyone on that team has a different specialty, whether it be like documentation or a community organization, or kind of like big product releases that kind of like garner interest in the Storybook ecosystem. And so it's been really fun to see everybody specialize and because it's a small team, we kind of like go out as far on our interests as possible. Michael Chan: I'm less involved in that piece of it, but I think that there is this really interesting separation in a lot of these startups today, where it's like you have the open source part of it, which kind of belongs exclusively to the community, and then you have the business side of it, which supports the open source stuff. But maybe it's less exciting to the general population that there's this service that you pay money for and does a thing than the thing that's free and you can install and unlock some new capability in your application. It's a really interesting... Michael Chan: I've never been close to startup culture at all before this, and so it is really interesting to see that thing that you're talking about, the kind of open source marketing funnel, for a service that businesses actually take part of. It's really interesting, because it's like B2B, but then there's this kind of like human layer in the middle, where the developers are actually making the decision, and so you have to meet the developers where they're at, by being a developer who talks about the open source stuff. Michael Chan: It's truly fascinating. This kind of like judo kind of thing where it's like, we can't just be B2B because engineers hate having used tools that were just mandated from the top down. So we have to kind of catch them on the engineering side and then have those decisions filter up through the company. Noel: Yeah. We kind of feel that energy here, as well as LogRocket, like, "Oh, it's going for the human element of engineering," but it is like a B2B product kind of at its core. But yeah, I was curious about kind of having that open source angle there, I feel like that tugs at the heartstrings of a lot of devs just inherently, people are excited about it. Michael Chan: I think it challenges us too, because something that's happening right now, technically, is that Vite as like ES module builder, is taking off, in Mindshare. Right now, in terms of what companies actually use to deliver software right now, the vast majority of it, if you're building a front end app is Webpack, but there's so much excitement and hype over Vite, like that's the next thing that's going to come up. But that's very like engineering led, and so it's really of cool because we get to kind of see those things, try to adapt to them, and build a better product, that's a little bit more agnostic of some of those tools. Michael Chan: I think that's the thing that's really fun about open source is that you can find a lot of people who are really excited about helping you with that. So you don't have to be an expert. Like none of us are experts in this new tool yet, but we can actually utilize other people's excitement, to kind of like help other people in the community. And that's one thing I really love about open source in general, and any part of your platform that you can open source, is great because you can... even if you don't take open source contributions, being able to just share what you're working on, to someone else who is not in your company, and doesn't have authorization to your GitHub repos and all that stuff, just makes the conversation so much easier. Michael Chan: I feel like it's only, almost always helpful on both ends, people seeing legitimate problems in real production apps, and then also people helping out with knowledge that they have. It's a very virtuous kind of fun thing right now, and I like it. I like this collaborative space we're in. Noel: Nice. Yeah, I feel like something about the developed tool chain in particular, so it's just like, people are excited about it. Like back to your Vite example, it's like, everyone wants to use the hot new thing. Everybody's like they install it, once they do and it's like, "Oh, this is amazing. This blows, and by the way, I'm going to be 50% more productive now." But then, you got to like, "Okay, now how do I get my giant company's tool chain all switched over? We've got to commit like 160 hours of resources to getting any... like the first project, switched over. How do we even begin?" Noel: Yeah. So that's an interesting dichotomy for sure. I guess maybe, to take a step back and frame everything a little bit more. Let's talk about Storybook more specifically., for those that aren't familiar. Like, what is Storybook, how does it compare to other tools in its space, and what is it, what is the transit to do? Michael Chan: Oh, I'm so glad that you asked. Storybook is so many things and we're actually just kind of unlocking a handful of features that I think would change what it means to people. I know that sounds super abstract, so I'm going to kind of like dive into that. Effectively Storybook, as my friend, Brad Frost describes it, is a front end workshop environment. And he's had this term kind of indifferent to Storybook, but I really like it, because the notion is that you have a space that you can work on front end components, front end UI, all that kind of stuff, that's completely dedicated to you as a front end engineer. Michael Chan: I think we've all had that experience in monolithic applications. So I came from a rails background. In a monolithic app, you have to run the entire... you're building front ends through the entire application stack, effectively, and there are a handful of things that are really irritating about that. Specifically, if I want to test this UI for a certain user type, with a certain authorization, I have to actually go into the database, fiddle around with some settings, or have fixtures for all of the permutations of various users that I might have in my application. Michael Chan: There's a lot of fiddling that goes on, and then maybe I edit my profile inside of a model, and so I have to change the database and then I have to go, and I have to navigate to my profile. I click the button, that enacts the model, and then I do the thing that I wanted to do. There's like always a lot of steps that we have as front end engineers, and it always sucks. And that's effectively the problem that Storybook is trying to solve, is having a dedicated front end workspace. Michael Chan: It says, "Hey, now that we have this component model, and a lot of things are driven by props, the data that somebody sees is driven by props, the parts of the UI that they see, based on their authorization is driven by props. The end in state of the model itself, whether it's an error page, or the actual page that you're supposed to see, or a loading screen, often driven by props. So how can we separate what we test, the things that we want to see, the permutations of this component, indifferent to the way the database is set up, or the connections and whatnot?" That's a really powerful thing with components because a lot of this is just like data in, and then it renders the thing. Michael Chan: Now that we have this really isolated way of showing complex UIs, I think the tools that have existed in the past, aren't very, very good at this particular space. I think that the beauty of something like Storybook, is having a place that's kind of isolated from your development environment. So you don't have to test things front, through your development environment, it's just like, :Hey, with these props, what do you look like? In this set, with this mock data, what do you look like? With this mock user, what do you look like? In this network state, what do you look like?" And it's all driven by props, instead of having to kind of fake all of the environment around you, just to see certain things. Michael Chan: So that's kind of the value of Storybook. I think that it is living in a space where just like unit testing drops off, and before end to end testing, like Cypress, begins giving us an environment where we can kind of stress test components, from a visual browser specific interest. I absolutely love it. Noel: Are people mainly using it? I guess, I mean, I'm sure there's a whole variety of use cases, but are most people using kind of in the design processes, they're building components or maybe implementing what a designer is handed off, or is it in the testing stack primarily, where people for finding value? Michael Chan: Yeah, that's an interesting thing, and I think that every company handles it a little bit differently. Up to this point, Storybook's been extremely popular with the subset of people who are doing component libraries that are an artifact of a broader design system. So, when you look at companies like big companies that have dedicated design system departments, I think that is who Storybook has resonated with the most, because there's a really close mapping, when you look at a Storybook, and you look at maybe storyboards that exist inside of something like Figma, there's a really close mapping where it's kind of like you're seeing all the various permutations in a visual state, and now you're bringing that over to a codified version of that, where these now exist in code. They have different things that you can manipulate to see like, oh, what does this look like with a long name or a short name, or emoji as a name. And it's something that you can actually manipulate and maintain, in a versioned way from a code perspective. Michael Chan: It always sucks to have representation in two places, but we definitely haven't arrived at that place where it's like, oh, design and development are a single process now. As much as I'd like it to be, I think it's been something that I've wanted since the days of front page in the mid '90s, when I started front end development. And I don't know, I'm not sure it's ever going to happen at this point. Noel: Yeah. It's hard to know what that'll look like in however many... or it's hard to have that longer view, I guess. I mean, it's getting better, like it's getting better. Michael Chan: It is. Noel: We get better results out of Figma now than we did before and out of some other tools. People were giving things and we had an image and it's like, "Okay, go dev, figure this out now." It's better than that world. Michael Chan: It is, yeah. Man, I have absolutely loved Figma. Figma is kind of design, developer, handoff tool that I've always wanted. Like the fact that you can just inspect stuff really easily, and there's a component notion there as well, makes it really easy to kind of connect to these things, to props or whatever your framework of choice, uses for that. There's a natural connection, and I love that logically, we're landing on some similar primitives, because it makes it a lot easier to talk about, even if that handoff isn't like one to one. Noel: Yeah. Totally. I mean, this is a very broad question, but do you think it makes... I don't know the correct way to frame this, I guess, but does it seem like it'd be feasible for something like Storybook to start reaching into that space further? It's like, "Well, we've already got kind of like the dev side here, we do everything from props to rendering, to running tests on it," does it feel like a tool that designers would ever be using or is there interest in that? Michael Chan: Yeah, so I know right now there's a lot of interest on Teams and a big part of my job right now is to try and figure out how we can communicate better to developers, because I think there's so many great tools inside of Storybook that would help with every UI component on NPM, and so I want to try to get more into that open source, developer type of workflow mindset. The designer thing is a little bit more challenging because I think that there's always going to be some type of tool that's better suited for that UI manipulation part of things, and Figma is really great at this. Michael Chan: I think one of the reasons that is resonated so much with the web community is because of its overlap with web concepts, even like auto layout. You can squint and see that's a flex box or a flex container. When you see an auto layout, you're like, "Oh, okay. I know how to actually codify this up." And I think that there's something really beautiful about that. Michael Chan: I've looked at so many things that actually take that and put that into code, and I think, unfortunately, there's just always going to be a growing number of concerns that can't easily be represented in a UI tool like Figma. I think specifically like accessibility, it's something that we're all learning and getting better at, but it's very much a page by page, component by component, kind of thing, and I'm not sure how you would abstract that in something like a Figma, without just making Figma, also a code editor. Noel: Right. Beyond just like the CSS and stuff that you're doing there already. Michael Chan: Yeah, absolutely. Like in terms of the interface of a component, I'm just not sure that even if you could provide that, it seems like I would be weary of that actually committing code in a way that is going to maintain the flexibility that is required from front end developers, to actually construct a page that's accessible to everyone. Noel: Yeah. That's a super tricky problem for sure. So I guess with that in mind, what process have you found works the best, in your experience when you're spinning up a new user interface, or a team is going up to spin up a new user interface. Do you start by like trying to think of the small components, like this is what we're going to have buttons look like, or do you start big and work your way down, or do you start small and work your way out? Michael Chan: That's such a great question too. I love that. So we have this concept of component driven design, and we may talk about that a little bit more, but up to this point, that concept has been really addressed to teams who have some kind of component library design system like team. So big companies basically. But I mean, as engineers, that's not really the way that we work typically. If I'm going to go make a new page, I'm going to make a new app, I'm going to make a new, I don't know, whatever, I usually start from the biggest thing and then just kind of chisel it out, get it working. One component, I make one file and this is the new page or whatever, and then go from there. Michael Chan: I hope that over the next handful of months, this year 2022, that we develop a better story for that. So I think you'd mentioned that kind of like outside-in, big to small, small to big, kind of thing. We're starting to think about it a little bit more in terms of the complexity that you need to represent, because I think there's something really interesting about the kind of progressive nature of building a full page, and then shipping that, and then kind of looking over it and thinking, "Okay, what can and should be pulled out of this?" Whether that's to be shared or if it's just to document the full complexity of the thing that represents. Michael Chan: I mean, it's amazing, just the reality of posting someone's name to the screen, has so much complexity to it, whether it's a long name, and if that breaks layout, or if it's short name, or like I said earlier, maybe they just put a single emoji, maybe it's non-Latin characters, or you have to support right to left. There's so much complexity that you need to be able to visualize and test, in a way that's repeatable, re-visitable, that has nothing to do with the idea of sharing that component. Yeah, sure, sharing it's great, but also testing it in isolation, allows us to create a catalog of the things that we know that we support, and be able to revisit that when new criteria come and we realize, "Oh, we had a glossy picture of what this thing is." Michael Chan: And so yes, from that, I guess that would be more like a top down or like outside in approach. I don't think that we've talked about it enough, but I really do hope that we can get better about talking about that, because I think that's where a lot of developers, entrepreneurs, indie hackers, where they live, not that whole, like, "Yeah, let's spend a year, and millions of dollars building a design system that's designed for perfect reuse and shareability, so that everyone doesn't have to worry about making these tiny little components." Michael Chan: That is a big company problem, and we see Storybook as like, if you have components, you should be able to use Storybook and be better off for it. Noel: Got you. Are people using, I guess these smaller companies then, that have already decided, "We're going to use some existing design system or component library or whatever. We're going to have someone else that's got time and energy to figure all these hard problems out. We're trying to build functionality. We want it to look good, but we don't have the resources to do it." Noel: Are there companies doing that with Storybook where they're using some component library, that's doing a lot of that legwork for them, but then kind of having Storybook help bridge the gap of like, "Well now we're in UX territory. Our app has to be usable, but we are not doing super low level stuff here." Michael Chan: Yeah. So if I understand that correctly, the question correctly, yeah. We are developing an answer for that, so there's two things that are actually really cool right now. Just a couple months ago, we released a component encyclopedia. So it was a friend on the DX team, Kyle Gach, and a bunch of people on the engineering staff, that created an encyclopedia of a handful of, I think... I mean, you can go it's on the Storybook.js.org site. There's this really cool encyclopedia that shows a lot of public Storybooks, that people have created. So things from Shopify, and Audi and GitHub, and all that kind of stuff. Michael Chan: There's that; we don't have a lot of stuff up there yet. We're continually adding to include more things like I think things that would be more beneficial to indie developers, would be a Storybook for like Chakra UI, or MUI, and showing those, because I think those are things that people kind of pull off the shelf and say like, "Okay, I'm going to make an app, and I'm going to use this thing." If you do decide to do that, and there's a Storybook available for the framework that you choose, we have this really awesome feature. It's one of my favorite things, and most people don't know about it. Michael Chan: It's called Storybook Composition, and it's a way to have in your sidebar, full Storybook libraries added to your thing. So you have your Storybook and all the stories that you're doing for your pages and your components and all that kind of stuff but then you can also include the Chakra UI Storybook inside of there with all of its documentation, et cetera, pinned to the specific version that you use and now that's part of your documentation as a small team. It's one of my favorite features. It's super cool. Michael Chan: I think it's also handy, even for big companies where you have a CoreUI library, but then this team focuses on the Ads UI and this team focuses on whatever, because now each team can have their own storybook and just include the version documentation for the CoreUI library that they're using. Michael Chan: I think that, again, a story that we're getting better at telling, but yeah, I think that there's a lot of cool things that you can do if you want to just pull off one of those UI libraries right off the shelf, which I think is a really good idea if you're start or have a small company and then not even think about the design system thing at all, except for your more composed views, pages and models and components that actually apply to your specific domain. Noel: Right. Yeah. That makes sense. I just feel like, riffing off what you said before, displaying a username is hard. There are such tricky problems out there, that most little shops do not have time to get super in the weeds on a design system. Yeah. I think a little bit ago you mentioned component driven development. Can you talk about that a little more? What does that mean? Michael Chan: Yeah. The way I see component driven development is again, on that continuum of testing things that a front end engineer needs to concern themselves with. On one side you have something like unit tests, which are going to just test like, “With these inputs, I get these outputs.” Michael Chan: Now that falls short somewhere on the UI side. So if you think about Jest, I know that there's a concept of snapshotting things in Jest where you can render a component and it's going to show you the, I feel like output to the browser, so effectively the markup, I guess, which isn't particularly useful. I mean, I guess it is kind of useful as a backstop to be like, “Oh, this component, it didn't render at all, or it rendered markedly different from what we expected before.” Michael Chan: But in terms of whether or not that actually is going to render in a browser or render in one of your target browsers, it's like, who knows? So there's this big cliff right there and up to this point, it's really just been like, I guess, from the other end is like end-to-end testing where you have to test your whole application, before every test you have to set up a whole login routine for various user types and authorizations and whatever, and then once they're logged in, then you can run various states whatnot. Michael Chan: I find those tests really painful, brittle to write, but absolutely necessary. But for me, if I'm going to write them at all, it's basically, “Can any user login? Can they pay me money?” and maybe basic cred operations on the major domain of the app. So if you're a to-do list app, can I create, edit and delete a to-do? But after that, I'm done. Noel: Right. You can come up with infinite permutations, it's just like, “Well, the five things are done. I don't know.” Yeah, Michael Chan: Totally. Noel: Yeah. Michael Chan: I think that those are the extremes of our testing and what we think is sitting in the middle is this idea of component driven testing, which is, “Hey, you have the components, you're testing them as a developer through the browser, and so we want to give you tools that allow you to do that job more effectively.” Michael Chan: So instead of creating a UI and then grabbing the [inaudible 00:30:34] with the corner of the browser and then moving it back and forth to see if your site is responsive in the ways that you expect. We'll give you a tool for actually representing that UI with various break points that yo know you support. Michael Chan: And so you can see the whole thing up front every time. So you make a change, you see it across all of them. Cool. Being able to do things like that feels like we don't have a good domain for that. I don't even know how I would… I know it's possible to do an end-to-end testing, but as you said, there's so many permutations. Michael Chan: I don't want to write a test for all of those things and then I don't want to do it manually either. Having to turn the network off in my Chrome dev tools to test that this modal shows a 404 or a 500 or whatever. I guess it wouldn't be either of those. Some type of error that isn't either of those errors. Noel: Yeah. Whatever. However you expect your app to break. Yeah. Michael Chan: Yeah. However, I expect my app to break, I can create things for that I can see all the time instead of having to poke and prod and pry at my UI, and I really like that. I think it's a really interesting space where you can capture a lot of complexity using a browser without having to have a full command over that browser. Michael Chan: And then also not assuming that other people are going to able to, or capable of running through that entire gauntlet every time they add a feature, being able to create stories for those and just to be able to look at it and be like, “Oh yeah, no, we have considered the 404 versus the 500 versus the never ends up loading states.” I think that is a really powerful thing that we're really just at the beginning of. Michael Chan: I think that we, as UI front end engineers use fairly primitive tools at this point and so we're trying to just elevate the repeatability of our pieing and pro poking and prodding. Noel: Right. Just help me close the loop a little bit mentally. Before you were saying you'd make a tweak to your list component or something, and then you got to, the old school way, like you grab your browser corner and try it and all these heights and widths and try to make sure everything works. How specifically is this way of thinking and using tooling like Storybook, how does it help me not have to do that? Michael Chan: Yeah. A big part of the idea is that if you… One of the beauties of components is that there's a lot of complexity inside them, but the interface for that is props. So with the component, we have this way of creating, or, I don't want to say forcing, but artificially creating an environment that doesn't necessarily have to be recreated. Because the interface is just props, we don't need a component that knows that we're using Redux and that Redux store goes and fetches information from this API in this way, we can just say, “This is your information.” Michael Chan: And Storybook allows us to create a story for an indefinite amount of states. So instead of thinking about things in terms of all of the connective tissue, we're just like, “Hey, we know that an authorized user would see it this way. We're just going to give it the data for this, like if they got this request so that we can see this.” Because it's so important that we see it in these various widths or whatever, we're going to make stories for those as well, where we see it at the like mobile width, the middle width and the big width. Michael Chan: And so the more stories you make, the more you have this lens outside of time, I guess. And one of the ways that I think about component driven development as being different from some of these other type of testing tools is there's been a lot of talk like in the Marvel Universe in particular about Multiverse. And with Spiderman and the, what is it? Dr. Strange and all that overlap that's happening right now, there's a lot of this idea of these things that are just true and parallel, I guess. Michael Chan: They're like fractured realities. And when I think about Storybook, I think about it as a tool for capturing some of those fractured realities. So I can see multiple dimensions of a thing. I can see what the Miles Morales profile looks like on mobile, with all of Miles Morale's permissions, but then I can see also what Peter Parker that profile looks like at desktop size with all of their permissions. Michael Chan: It's fun when you think about it, from this perspective of almost like a minority report type of thing where you just see the full picture of everything indifferent to what state something is in. And it unlocks, for me, just a different way of thinking of like, “Oh, okay. If there's a possible UI state, I can add it to Storybook and then capture that a concern for myself in the future and every other developer on my team,” which I think hasn't been the case up to this point. Michael Chan: Because I might do a really thorough job of making sure that my components are tested for all the various break points and all the different authorizations and user types and all that kind of stuff, but there's no guarantee that someone else does the same thing. Maybe I go into notion and I'm like, “Hey, if you really want to be thorough about updating this UI, here are the 170 criteria that it needs to pass in order for…” Michael Chan: But instead, we just have it visually. It's just like, “Here. This is everything that we know.” And maybe that's a lossy picture of the universe, but if it is, then when we discover a new thing, we're just going to… We discover a new Peter Parker, a new Spiderman, we just add them to this gauntlet and then let the machinestell us whether or not we did it correctly. Noel: Yeah. Nice. I'm not a Storybook user, but what currently, I keep hearing more and all these people are grabbing it and are like, “Man, maybe I should be checking this out for even personal projects. This sounds great,” but I guess if I add a story for something, what does the pass criteria usually look like? What is valid? How do I know when I add a new, Miles Morale, it's like, “Okay, that works in this stage.”” What does that look like? Michael Chan: All the things that I love talking about. Thank you for asking these. One thing that's really interesting about UI, and I think another way in which Storybook differentiates itself from the other testing tools, in UI, you are allowed soft exceptions. So if I run a unit test suite, there's no concept of a soft exception. It passes as a whole, or it fails as a whole. And I'm never going to merge something that fails. Michael Chan: So what's interesting about UI though, is that we accept a lossy view of what is accurate, I guess. So even the name thing, your first iteration of this component that renders a name, maybe does some kind of juncture of first and last name, and then you realize like, “Well, that's a very Western concept and so we have to have a more complex idea of how to handle these, these fields and represent them given demographics and regions and whatnot.” Almost lost my… I mean, I definitely lost my train of thought. Noel: No, that's okay. Yeah. But what passing criteria? Michael Chan: Yeah. Passing criteria. So in a lot of cases with components, you could then without actually adding any code, just put a filling case up there. So you can add a story for like, “Hey, this is what this looks like now and it shouldn't look like that, but we want to put it in there for when we eventually fix the code and this snaps into place and becomes correct.” So first there's this idea of soft exceptions in UI, which I really like and I think that it's a big differentiator between the end to end and unit testing tools. Michael Chan: So we have that as something that we need to consider. Storybook itself, doesn't have a passing or failing criteria and so that's where Chromatic comes in. With Chromatic, you can connect to a Storybook, it knows everything about your Storybook, and it will take visual snapshots of everything you tested or every UI permutation that you have a story for. It'll make snapshots for all of those that you have, and it will do a visual diff, and I think also a code snapshot diff of the, assuming that you're on Git or whatnot, it'll do a visual diff of the proposed change versus the last baseline snapshot that you have accepted. Michael Chan: So, as you make changes… Additions you're always going to accept, but you're going to have these warnings as well saying like, “Oh, Hey. You changed this code over here, but then this permutation of this code in desktop orientation, well, now it looks a little bit different. You can go through, look at it and say like, “Oh yeah. Actually, that's what I want. Update the baseline,”” and then once that's good we have a integration with GitHub, GitLab, Bitbucket that you'll now see that PR check goes green and you can merge it. Michael Chan: So that's the criteria right now. You could accept it in a known exceptional state if you wanted to, and then see that it fell into place later on when you update it. But yeah, that's the one, two punch of Storybook and Chromatic. Storybook's the place where you author all of your stories and then Chromatic is that CI check that does all of the automatic checking for you, it does automated checking across multiple browsers if you want. So yeah, really cool stuff, which honestly, that was the unlock for me. Michael Chan: I was just like you. I was like, “Yeah, Storybook, it's fine. Whatever, that's cool. I can also just put a page and render components, on it, no big deal and it's probably faster that way,” but when I started getting into browser testing specifically, and having to make sure that every component that we built continued to work across all of the browsers, I was like, “I am not long for this world if I have to do this every day of my life.” Michael Chan: That was the day I installed Chromatic and just let the machines do it. I was just like, “I just needed to know that they looked the same is the last time that I checked them, and if they do, that's good enough for me.” Noel: Nice. Yeah. I'm making it sound like I haven't been convinced sufficiently yet, but we are users here at LogRocket and stuff, I haven't had the opportunity to touch the front-end component since we started into that path. I'm in an isolated role right now. Michael Chan: No. Yeah. I hope that it doesn't come off as defensive either, because I was seriously in the same boat. I was like, “Yeah, that's cute.” It's cute that you have a dedicated space where you can look at your components. That's cute. Now when it came to time for a thing that I absolutely did not want to do ever again in my entire life, I was like, “I'm sold. Sign me up.” Noel: Yeah. I think even, again, even without the CICD component there and that first layer of automated checking, is there any visual diff at all? I just feel like having the tooling in place to make it, so even like a manual visual check is easier and faster to perform is hugely beneficial, just in like, you don't have to have an army of QA that are just going through these motions every time and testing all these things. “Well, no. Here.” That work is done for you already. Just go, “Does this all look right?” That is huge in and of itself. Michael Chan: Yeah. And to that QA thing as well, I don't want anyone at any part of the component development product life cycle to have to repeatedly do something every single time. What a huge waste of effort. I would love for that specialty to be able to figure out new ways in which our application breaks, instead of just testing the 500 ways we know that it could possibly break. Michael Chan: I feel like that is a really great tie in because now you can take those failures and now incorporate them into your test suite. Even if they're soft like, “Oh, hey. We actually have a lot of people asking this type of support of names. Can we put some condition… Not conditions. Can we put some cases in there so that we can see what it looks like now, but then know that it changed when it changed?” Michael Chan: I think it just makes a more integrated feature life across the board, which I like. I mean, if there's something that we know enough that it's just a process that someone has to do the same way every time, we should just have a robot do that. That's what robots are for. Noel: Yeah. Totally. Have you found QA teams to be Storybook users? Is that a demographic you guys target at all? Michael Chan: That's a good question. I don't know. I know that a lot of… Like at my last job, there was an overlap of QA and then some of the… I can't even remember what the… There's a tool for browser testing and you can actually record scripts and whatnot. Noel: I've used a couple of them. There's so many. Michael Chan: Yeah. One of those. Yeah. So, yeah, I haven't actually heard a lot with Storybook, but again, we have up to this point focused mostly on design systems teams and so I think that as we focus more into communicating for engineers and feature work, I think that we will naturally have a little bit more inclusion in the development feature product space. Noel: Yeah. Cool. Awesome. I guess you mentioned a little bit briefly, having that first CICD check of image diffing and stuff that Chromatic can Supercharge storybook with. Is there anything else cool that Chromatic is doing currently that's exciting or on the horizon that kind of… Michael Chan: Yeah. Chromatic is a lot of things, so the visual regression testing across browsers and the code diffing or the output diffing is all stuff that get access to and it's super great, but it's actually built out as a collaboration platform. And so it's really nice to have a place where people can communicate without having to go to the GitHub issue. So that's something that I've noticed on a lot of my teams is, engineering has this full conversation on the GitHub issue and how do strict designers or stakeholders or managers speak into that process when really the thing that they're reviewing is more of a visual thing? Michael Chan: So Chromatic solves that problem as well, giving people a place to have that conversation, drop pins and say like, “Hey, is this what we expected for this thing?” Have those conversations in a way that ties into CI, but in a way that that person never has to actually log into GitHub and talk about an issue in reviewing code. Cool. So yeah. That part is really cool and a huge benefit once you start integrating that into your life cycle. Noel: Nice. I guess. Yeah. Anything else on a more personal level, you're excited about coming up? Anything you want to plug? Michael Chan: Yeah. Oh man. That's a good question. I think honestly… I'd mentioned at the top of the show, but something I'm doing right now is with Storybook is Storytime with Chantastic. It's on the Storybook YouTube page, so youtube.com/storybookjs or /c/storybookjs. However you get to channels. Michael Chan: And that's been super fun. I really enjoyed talking with people. I got to talk with Brad Frost. That was the first episode we talked about the front end workshop Ironman in the abstract. Super cool. Talked with Ryan Bahan at Shopify and how to manage design system designer. Handoffs, talked with Tom Preston-Werner, recently co-founder of GitHub, and so many other things about their new framework, RedwoodJS, and how it, by default, out of the box, would generate Storybook for your components. Michael Chan: And they have this model, for anybody interested, they have this model called a Cell and they use Storybook to document the error loading and loaded states for you for this concept right out of the box. So generator, it works right off the bat. All the data is mocked through… They have a Prisma for their various backends and all the data gets mocked based on the Prisma schema. It's freaking rad. Michael Chan: This is the dream state of Storybook front end web development, future development integration. Totally check it out. Even if you're not a Redwood user, it's really interesting inspiration. Personally, I don't know. I'm kind of figuring out what's next for me on the personal front. I am doing a lot in Community. We have a Discord Community, discord.gg/lunchdev where I hang out a lot, just getting to know a lot of people doing cool stuff in the front-end space. Kate: It's where a lot of our guests come from on the podcast. Michael Chan: Yeah. Huge amount of crossover there, which is really fun. And then I'm working on doing some more YouTube stuff on content creation for software engineers, which is a funny intersection, but it's where I live right now, so that's youtube.com/chantastic if you're in and that kind of stuff, if you want to learn how to edit or use a camera or how to make microphones work, all that kind of stuff. Super fun and yeah, that's me. Noel: Nice. Yeah. Your lighting looks great right now. I was going to ask. You're killing it. If you needed a plug, it looks so good. Yeah. Michael Chan: Oh, thank you. Kate: Awesome. Well, thank you so much, Michael. We appreciate it and we will certainly see you around. Michael Chan: Yeah. Thanks for having me. Always a pleasure. Kate: Thanks for listening to PodRocket. You can find us @PodRocketpod on Twitter, and don't forget to subscribe, rate and review on Apple Podcasts. Thanks.