React Summit

React Summit 2022

A look into Preview.js, an open-source extension for Visual Studio Code, IntelliJ and WebStorm that lets you preview individual React components instantly, updated as you type. by <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Improving Developer Happiness with Preview.js

Hi, my name is Francois. I'm a developer happiness engineer from Sydney, Australia. You might be wondering what is a developer happiness engineer? What it means is that I'm a regular software engineer who likes to work on refactoring stuff or fixing flaky tests or making CI faster. But sometimes it's also about creating new tools to make other engineers faster. So one of those tools is called PreviewJS. And I'm going to be talking about that now. You might be familiar with this XKCD comic. I think it was drawn quite a while ago. But it's still somewhat relevant today. I'll give you a few seconds to read through it. So this, I think, was especially relevant back in the days of a lot of programmers using C++ or some other really, really slow language where you had to wait for five minutes, maybe 10 minutes, maybe even an hour for your code to recompile. It's not that relevant today for JavaScript. Or is it? It's actually not that uncommon these days to work on a large code base that uses maybe an old version of Webpack or a misconfigured version of Webpack that takes a couple of minutes to run the build. Maybe even worse, maybe you have to wait 30 seconds every single time you make a change to a file. Which is, if you think about it, when you add that up over a day, every single time you want to see the impact of the code change you made, that's quite a while just spent waiting. And not only is it waiting, but it also breaks your flow. So you're usually going to switch context, going to start doing something else and then you go back and it's just, you kind of lost track of what you were trying to do or whatever was in your mind is just kind of not there anymore. And it's really not very good for productivity or for engineering happiness. So let's take this example. This is a food delivery app that I called Hungry. And it's really just for the purpose of this presentation. So here we have a bunch of restaurants and let's say I feel like some French crepes. So I'm going to say crepes. Okay. There's a restaurant called Creperie François. And I'm going to go there and check out. Okay. So there are some really yummy things. Caramelized banana and chocolate. That sounds good. Fresh and candied orange. Okay. That sounds good. Okay. That sounds good. Okay. That too. Okay. I'm going to get everything. Maybe two of each. Cool. Great. And this is pretty much what you would expect from a delivery food app. And we're in the early days of releasing that to users. And the first piece of feedback that we get is that some users are surprised that sometimes the menu doesn't contain the items that they expected. So that's because sometimes if an item is unavailable, right now the API just removes it from the menu. So let's say this restaurant ran out of chicken. This first item, Kung Pao chicken, will actually be missing entirely. Which surprises users because they're like, well, did this restaurant remove this from the menu forever? Should I just completely boycott this restaurant because they removed my favorite item? But no, that's not the case. It's just unavailable today. And really that's our responsibility as designers of this app to make it clear. So instead we get a feature request from our product manager which says now we should still show unavailable menu items but just make it clear that they're not available. So you know how here we have this counter. Instead of this counter, we'll just say unavailable today, right? This should be a lot less confusing for users. Of course, the first way that we can implement this is by just running the app locally. So we're going to go to our terminal, run Yarn dev and wait a little bit. Okay, so it's running at local host. Cool. I do need to wait a little bit for this to spin up. I'm actually not entirely sure why. But there's something in here that takes quite a while. This is exactly what I meant by spending the time that you spend waiting. Like I might just go on Twitter and completely forget about this and go back here and just maybe have to wait again because I need to reload the page or something. Okay, cool. So that's our app. It's running. Now I need to find a restaurant that has a menu item that is not currently available. So I'm going to go through and try to find one. But wait, I said earlier that the API actually does not return menu items that are not available. So that's not going to work. All of them are by definition available because they're returned by the API. So I have a couple of ways to approach this. One is if I'm myself an engineer who works on the API, then I might change the API to return unavailable items. Although I have to be careful not to return them to versions of the app that don't support that yet. Or if I don't know anything about the API, I'm going to have to mock it out. So I'm going to go into my code base and find the restaurant page. And I'm going to go into that. So that's using this restaurant details page state, which is a MobX state. And really, at the end of the day, all it does is fetch. Okay, so it's fetching that, it's getting the data, it's a restaurant details response. Cool, at least this is well typed. And okay, that returns a menu item, and menu item has unavailable, which is an optional Boolean. Okay, cool. So I'm going to hack this up and say that menu zero dot unavailable equals true. And I'm going to go back to here. And so this first one, because number zero should be unavailable. But of course, we haven't implemented this, right now it still shows the counter. And now, I do know that this component is called restaurant menu item. So I'm going to go in here and say, okay, so here, instead of the counter, we want to say that if unavailable, then we show unavailable instead. So maybe the unavailable, unavailable. Cool. Nice. Cool, done. That's it. Now, of course, I need to remember to remove this, because if I don't remove this, it's going to break the experience for users. But other than that, we're done. So luckily, this is a pretty nice good base to work with. Thank you, Next.js. And yeah, we're pretty much done. So running the app locally is a lot of times the right solution, right? It's super straightforward. It doesn't require any additional setup. The only thing is that mocking data can be hard, depending on what is the specific use case that you're working with. And iteration speed can be slow. Again, only if you're working on a really complex code base or something that is not very well configured. But that's more common than you would think. Option two, we could use Storybook. In case you're not familiar with Storybook already, it's pretty much a gallery app for all of your UI components. So it's called Storybook, because you define stories for your components. Each story is a specific version of your components. So in our case, for example, we have the unavailable story, and we have the available story. So let me show you what that means. I'm going to go in here and run your Storybook. And this can take a while, depending on how many components you have. Okay, this in our case is very fast. Cool. And you can see, okay, we have this counter story, we have the no-match story, the restaurant header story, restaurant list, and so on and so on. So what we're interested in here is restaurant menu item, where we have two different stories, default and picked. So you can see that when it's picked, there is already a counter created. And I can go back in here, and let me show you how that's implemented. So we have this file next to restaurant menu item, which is the restaurant menu item.stories. And it has a little bit of boilerplate for Storybook. And then each story is this. So we have args that we define for story. So here we have two stories, default and picked. And default and picked are here. So you can see the difference is with the args that we pass, which are pretty much the props. So in our case, we want to create a new story called unavailable with a menu item that is of course unavailable. Oops, forgot a comma. Available, true. That's pretty good. And now it should appear. Okay, perfect. We have it here. But of course, we haven't, I reverted the change already. So let's do that again. Just simulating the experience from scratch. Menu item.unavailable, unavailable. Okay, perfect. And it updated pretty quickly, which is great. And let me revert that again, because we're going to do this again yet another way. Cool. The nice thing with Storybook is that it encourages good design, not just from a UX design perspective, but also from a software design perspective. So because you want stories for each of your components, you need to think about what components you want in the first place and how you want them to be designed in terms of the props that it takes, et cetera. And the way that Storybook structures stories means that you are pushed in the direction of creating dumb components that are kind of agnostic of the state, so they're not capable to Redux or anything like that. And usually that's a pretty good thing because it means that your components are really easy to test, really easy to reuse as well across code bases. So lots of good things there. It also acts as documentation, which again, is super useful. So if you want to say, tell your UX designer, hey, I have this component that is currently in this particular implementation, you can check it out at this URL. That's really super useful and reconciling that versus the box that your designer is working with. It can be a little bit slow to spin up in that it depends on how many components you have and really is something that the Storybook team is working on improving anyway. So it's not really something I would worry about too much. It does require a little bit of boilerplate. So we saw that you really can only look at components that have stories defined for them. So first you need to define the stories. If you find a component and you're wondering what it looks like and there's no story for it, you're going to have to write a story first. Cool. Is there an option three? You know how when you write markdown in your ID, let's say in VS Code, you can actually see a preview of it. So let me show you. Let's create a readme and say hello world. I'm on a max. I'm going to press command K and V, I think. Yep. And this is going to say this is instantly updated with a nice preview. I can see this is pretty cool. Cool. So what if we had something like that, but for React components? And I kept looking for that, but I never could quite find the right solution. There were a couple of contenders, but the problem is that they only work with components that don't take any props or that are super, super simple. So I decided to build it. And it's called Preview.js. It was actually earlier called React Preview because it was for React components, but then I realized that it could also work with other frameworks like Vue and Solid. So I renamed it to Preview.js and also in the process kind of reworked pretty much all of it. So Preview.js works with React, Vue 2, Vue 3, and Solid. And it's available on VS Code and IntelliJ. So let's look at what Preview.js looks like. Let's go back to VS Code. We have our restaurant menu item here, which I reverted back to the previous state. And I'm going to here have this button, open restaurant menu item in Preview.js. So I'm going to click on that. And oh, proof. That's pretty cool. Okay. So I can see a preview of that. And I, again, did not have to write any code for this. This is just out of the box. Basically what it did is it looked at the props of this. It's so, oh, okay. This specific, first, this is a React component. Therefore, I can show this thing. But also it sees, okay, that takes menu item counts on update. And it can actually look at the type of menu item and kind of generate a valid value for it. Well, at least as much as it can guess. So here, let's make it a little bit more realistic. So let's say brownies. And let's use cute kitten pictures. Although we're not going to eat the kitten. So yep, this is really just for illustration. And now this is a little bit more realistic. Now we want to implement the unavailable state. So what I'm going to do is provide an example value. Okay. And now I should be able to see what it looks like. So do unavailable. Oh, cool. That actually updates live. That's pretty cool. And I'm going to make it prettier then given I have instant feedback. That's pretty cool. Okay. A bit of padding. Maybe rounded corners. Yep. Maybe a drop shadow. Drop shadow. Yep. Oh, cool. Maybe a border as well. Border to border. Red. Oops. Sorry, typos. Lots of typos. Okay. That's what you get for recording a presentation at 11 p.m. Okay. Yep. One more time. Okay. Cool. I keep pressing save when I actually don't even need to save because privilege doesn't require you to save. Okay. So that's pretty cool. Okay. Unavailable right now. Okay. Okay. How does it look when I make it wider? Okay. Cool. That's fine. Okay. Maybe just a little. Okay. Cool. Done. That's Preview.js in a gist. Now, you might wonder if you use Preview.js, should you still be using Storybook? And the answer is yes. Storybook is pretty much still a great tool for documenting your components and making sure that you have documented every variant of it. In fact, Preview.js actually supports displaying your stories. If I go into menu item stories, you can see that I see the same Preview link for each of the stories. And I can see them like that. Which is perfect. I can also, you know, look at the restaurant header. All these different things. So, if you're just exploring a codebase, I use a Storybook and you use Preview.js and you have it set up, you probably don't even need to spin up Storybook. And this will probably be a lot faster to just use that instead. Just like that. In the future version of Preview.js that I'm hoping to release in June or July, there will actually be also a feature to save your props as a new story. Although I'm probably gonna make that part of the Preview.js Pro version which is paid. Just because at the end of the day, I would like to be able to make a little bit of money from that so I can spend all of my time working on Preview.js as opposed to having to squeeze that in my free time. But that's the gist. Preview.js works really well with Storybook. You can use both. They don't compete with each other. Preview.js is only possible thanks to a couple of recent web tooling innovations. Especially one called Vite. Which is pretty much an alternative to Webpack that is significantly simpler to set up and as well significantly faster. Your developer experience with Vite is that you update a file and within literally milliseconds, it will update. That's why Preview.js is able to do preview as you type. The only reason that's possible is because it uses Vite under the hood. If you want to take one thing out of this talk, aside from use Preview.js, of course, it's use Vite. Try it out. It's easier to set up than you would think. And it might save you literally many, many hours per week. If you want to set up Preview.js with your projects, there are a couple of steps to go through. To be honest, right now, it's not the smoothest experience, unfortunately. But unless you use, you know, create React app or something super simple, in which case it should hopefully just work out of the box. But the first thing is, of course, make sure that you use an IDE that's compatible. So, either Visual Studio Code or IntelliJ slash WebStorm. If you are not sure which one to use, use Visual Studio Code because the IntelliJ version is kind of buggy, to be honest. Working on that. And then the next thing is you have to configure it to display your components properly. Because by default, what Preview.js will do is display your components in a completely empty app. Which is not exactly perfect if, for example, you need some global CSS to be there. So, the way that you do that is by configuring a wrapper component. And let me show you what that looks like in my hungry app. It's here, Preview.js wrapper.tsx. And that's pretty much all of the config that we have. That's it. That's all the config. The important thing here is this import styles globals.css. Without this, it would look super ugly. So, let me just show you what I mean. Okay. So, I have this. And I'm gonna remove that just for fun. And it's gonna be... Yep. Really broken. Because, of course, in globals.css, in this case, I have all of Tailwind set up. And I also have a wrapper that sets up a screen container. I'm just adding a little bit of margin to make it prettier. But you might, for example, need to set some React contexts. Some, you know, initialize your redux state or whatever else you need. If you use aliases, import aliases, you might also need a couple of lines of config as well. So, as I mentioned earlier, Preview.js is quite new. It just came out in January. So, if you run into any bugs, please consider reporting them on GitHub. I really appreciate that. I'm expecting after this talk maybe a couple of hundred bug reports. Hopefully not that many. Go to Preview.js.com if you want to check it out. If you're on Twitter, you can follow me and share your feedback. I really hope that Preview.js can make your daily workflow a little bit better and a little bit faster. Thank you.


François Wouts

React Finland

React Finland 2021

François will introduce ViteShot, a new open-source tool that can generate screenshots of HTML/CSS components within seconds, so you can be confident that your UI looks exactly the way it's supposed to. <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>