Introduction to Storybook: Building component driven UIs faster

    So this presentation is about storybook but I wanna start at quite a high level about what component driven UIs are and what that means for our product development.

    So the subtitle of this presentation was Building Component Driven UIs Faster. But what is a component driven? . So components are standardized, interchangeable blocks, and I've got a lot of technical mumbo jumbo and a fancy illustration on the screen.

    But a great way of thinking about it is Lego blocks. Rather than you building bespoke plastic for every building project that you're gonna do, buying all that equipment in just to build a space rocket, why not reuse the Lego blocks you already have?

    You could make a rocket, a house, a car, anything you could imagine, because all lego is this interchangeable system for building anything you can imagine with.

    So here we have an example on the right of a UI that's been built with components. So you see the whole page is called home page. There's a nav bar there. There's a title, there's a search box, there's a submit button, and the cards that describe the hotel, they're cards built of card content.

    This brings a few benefits, which I mentioned before with the Lego block metaphor, and the first one is reusability. You can reuse the same piece many times over your whole project that piece is interchangeable. It doesn't need to know what the other pieces do to work together. It just fits with them and helps you build really cool things really, really quickly.

    So if we look at our Book Awesome Hotels website, we've got there to look at that star component . Sure it's, been designed to come in that card content, but we could reuse that star component for the hosts and it could be reused in other places just like the Lego block that we talked about earlier on.

    Testability. It's so much easier to test things in isolation than it is to test them together. So if you wanted to test this whole webpage, it's quite complicated in terms of interactions, but if you just wanted to check that the star counter shows four stars when something's rated four stars or one star when it's rated one star and that they can click it and change and rate their star value that's much easier to define at that component level rather than thinking about the whole page together.

    But the joy is once you've tested all the components, you've obviously tested the whole page without having to keep those complicated mental models involved a testing process.

    The third one is efficiency. Using a component based approach speeds everything up. Because you've got pre-made components that are ready to go, for use cases you couldn't even possibly imagine right now. So that button can be remixed next to that review. You can reuse that heading without totally having to rethink what a heading looks like in the new context.

      0:00 / 17:48