Design Systems with Storybook, v2

Using Loaders to Fetch Data

Steve Kinney

Steve Kinney

Design Systems with Storybook, v2

Check out a free preview of the full Design Systems with Storybook, v2 course

The "Using Loaders to Fetch Data" Lesson is part of the full, Design Systems with Storybook, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Steve demonstrates how loaders offer a way to asynchronously load data or perform actions before a story is rendered. This can be useful when fetching mock data from an API, performing setup tasks, or dynamically manipulating props or globals based on external factors before the story is displayed.


Transcript from the "Using Loaders to Fetch Data" Lesson

>> What's the second wall that we might run into? What if you have a component and some of have a good reason, maybe or maybe not, that calls an API, right? Or needed some data, or expected to have some data from an API. I joked that you shouldn't do this and we do it on purpose.

I think I mentioned during the break for our website CMS, we use Contentful, right? Which is all our blog posts, all of the copy on our website because I got tired of tickets saying can you change the wording of this heading? Nobody on the product marketing team wants to ask me to do that and nobody on the engineering team wants to do it, right?

And so right now everyone go into Contentful, but, sometimes if someone's working on a new page or something along those lines, you can actually see the components with a given blog posts with a given card with whatever you're changing. So we actually do have it hit the API in certain situations for the process of our friends in marketing to being able to see stuff in the storybook, I think designers as well, to see it with real content.

They'll have it in their Figma design, but then sometimes you wanna see it with some real things, so we'll have that in storybook as well. So I lied, we do do it on purpose. Ross did it, he's the best. That is the concept of a loader, right? A loader runs before the story.

I was like, I was going to try to try to explain what a loader is, but I can't explain it without the words. It loads [LAUGH] data. Also, API, sure, sure, sure, that's great. A place where I considered using it is the application I work on is the dashboard for distributed system tooling, right?

Sometimes I just want to read fixture data off the file system, right? I have a whole bunch of cached API requests that are just JSON files, and so I could theoretically be able to run through, okay, now show it with this kind of event, this kind of weird situation, and that fixture, and stuff along those lines.

That is an issue, that is area where it is on the roadmap, for like next month or so we have not done it yet, I'll tell you, it's a good idea next time we'll talk to you all. But that's the plan. And so this would work the exact same way as well.

So here we'll say loaders, and that is an array as well. Sure it could just be an array that I pass through, that seems fine, I guess. Let's actually do this instead. We're gonna make it a function. And, let's say const tasks = await fetch. This is just a, I mean, the URL tells you what it is, right?

It's a fake API that happens to have tasks that are exactly the same as what is in here. It's almost like I did it intentionally, return tasks, right? And so I do think I need to parse the response to JSON now. Then, Response.json, And then we'll pass that through.

And then, in our context, It is, context.loaded.tasks. This API gives me 200, I could slice it, not going to. So now you can see that it hit the API, as well and that's super great. The thing that you can do is there's both an add-on, But this is also outside of really what we're supposed to talk about today, so I'll just kinda make a mention to it, something called Mock Service Worker.

This is great for local development too. It basically, you installed it in development, and it uses a service worker to intercept all of your API calls and just respond to them locally, right? So if you, and this is great when we, for a given component in a design system, maybe not that important, but if you're testing entire pages, entire things that have a lot going on, right?

It can theoretically, and we use this in development, right, storybook aside, which is like, I don't use it that much cuz I work in an open source project, which you can just run on your files. I have a CLI, I can actually run my product locally. In past lives, it's a little bit more important, but you can actually just have it intercept all of the API requests and give you back mock data and stuff along those lines.

And it's great for developing it on an airplane and stuff along those lines because you hate to see that stuff not work. And you can kind of turn it off and turn it on. So you can, if it is calling a real API and you don't want that for some reason, because nobody wants to see their test fail because the backend went down.

Everyone's nodding because it happens. Why are my tests failing? Because of you. And so this is a way to kind of do that in both in development. It's also great for like loading up a bunch of like, again, I need to load up a whole bunch of different, fictitious states based on every bug report that we've ever gotten, stuff along those lines.

But, kind of to summarize and there are some plugins that one can look at, they're not that cool. Storybook and figment and figment storybook, do you want to get lucky guess what they do? Nothing more than show you one inside the other. They seem really cool, I think I used them once and then like, I can just open up two windows it's fine rather than try to connect them all, all the time.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now