Choosing Next.js, TypeScript, and StoryBook for your Tech Stack

Here's a transcript of a video from our interview with Gary Meehan (front-end developer at Distilled SCH). In this video, Gary talks to Gabe from Prismic about how Distilled SCH manages their tech stack.

Read the transcript for the details, but the video is probably more enjoying. Make sure to check out the rest of our interviews and tutorials and to subscribe to our channel.

If you're interested in Next.js, TypeScript or StoryBook you should definitely take a look.

Gabe: Hello it's Gabe from Prismic.

Gary: Hi, I'm Gary from Distilled SCH.

Gabe: So, I was wondering, at your company, how do you manage your technology stack like Next.js, TypeScript, and Storybook?

We looked at some server-side rendering frameworks. We actually implemented a Beta, or Alpha version of our own. We then compared that against Next.js and others. We felt that Next.js offered everything that we wanted from a framework.

Gary: So as I mentioned earlier there, we were going to re-platform. We've done a lot of research on different options. One of the most crucial things for us is SEO. So with that being critical, we needed to have server-side rendering. We believe Google does do rendering of JavaScript for SEO. But with it being such a critical part of our business, we felt that we weren't taking any chances. That we were betting on something that we knew worked. So we looked at some server-side rendering frameworks. We actually implemented a Beta, or Alpha version of our own. We then compared that against Next.js and others. We felt that Next.js offered everything that we wanted from a framework. It had great community around us. Had some amazing examples in their repository. It showed you how to integrate with things like JS, TypeScript, Google analytics, Sentry error. There's probably fifty or a hundred examples in there, which is brilliant. So that's why it's kinda helped us make a decision on betting on Next.js. As well as other core technology.

Gabe: So what things as a company do you value that Next.js provides? Speed for example?

So straight off you can start using Next.js without having to implement the custom Node server for example. They extract that away.

Gary: Yeah. So straight off you can start using Next.js without having to implement the custom Node server for example. They extract that away from it, but then they also give you the flexibility where if you have complex caching requirements or authentication, you implement your own node server and then you have full control over this, which is what we've had to do. Whilst they, for SEO as I said, they have implemented a way that you can inject meta-tags into the head and it's very easy to use and it just gives you an amazing way of managing a page level SEO, which is another benefit.

Gabe: That's great. It's nice that you have kind of this Next.js, Node.js server. Where you have all the benefits of static, but you have a few other things on top because it's a server. You don't sacrifice anything really. So with that, how do you use Next.js with your other technologies?

There is getting used to TypeScript, fighting with TypeScript errors, but I wouldn't call it pain. It's just part of the learning process and it's definitely saved me.

Gary: So, as I mentioned there, we use TypeScript as well. This was an interesting one. I think one of our team members had experienced TypeScript, but the rest would have been new TypeScript. What we just felt from doing research, that and speaking to people at conferences, that it was a strong language but it offered, if you write your application in this and their components that it would scale well. It was a bit easier to onboard new developers. So far I think we've seen a lot of benefits. There is getting used to TypeScript, fighting with TypeScript errors, but I wouldn't call it pain. It's just part of the learning process and it's definitely saved me. I found myself saying, oh, time for your TypeScript. That was like a three hour bug to figure out, when I tried to do an incorrect check.

Gabe: Okay. So it seems to benefit you a lot. What about, sometimes people ask about the case where you have to just put in any type in TypeScript, like from an API response, how is that handled?

Gary: Yeah, I suppose we have a couple rules turned on, so you can't just write a function without actually declaring the type for the parameter, but you can just cheat and kinda add any. I'm not going to lie, we have a couple instances where we use any, but the majority of the time we're trying our best to add the types. In some cases there's been instances where we just have to kind of implement something and figure out, because we're all learning TypeScript, figure out how the types work and do a bit of research, and that's working well. So the next time we tackle that problem, we're able to type it from the start I suppose, which is probably the proper way of doing it.

Gabe: That's nice. On to the other topic, Storybook, how is that working out?

The benefit is if there's a bug-fix that comes in on the site, you make that bug-fix, but it then flows through to Storybook. So it's not this decoupled style guide or component library, it's actually your life components that are getting updated, which is brilliant.

Gary: Yeah, I think what we've tried to do from the start was Component driven development you could say. So we look at say a design or a page and we break it down into components. What we do is we take the UI components from that and we try to, we would then look at the requirements for that. We would start in Storybook.js, which gives you a nice UI. You would start coding your components, so you're referencing-- the benefit is you write your component in your production folder in your actual application, and Storybook.js lives along side of this, so you reference your actual components in Storybook. You render it to Storybook's UI, you then find the prop-types first, pass in mock data if you want, and then you style this component. You can change the view point in Storybook with a plugin, so then you have your responsive components coded. Then you publish it or you push to production from here, and it's just a matter of yourself or another team picking up this component and using it. The benefit is if there's a bug-fix that comes in on the site, you make that bug-fix, but it then flows through to Storybook. So it's not this decoupled style guide or component library, it's actually your life components that are getting updated, which is brilliant.

Gabe: Very cool. So thank you for sharing Gary and it was nice having you.

Gary: Thanks very much.