DEV Community: Chroma

Introducing LearnStorybook.com

Dominic Nguyen — Tue, 10 Apr 2018 13:01:01 +0000

A tutorial that teaches you Storybook by building a working UI

TLDR: 👋 Dev.to we’re launching Learn Storybook — a fast, approachable, and free tutorial to get started with Storybook. Whether you're a new or experienced frontend developer, this tutorial gives you a head start learning the UI component tool used by professional teams. Includes real code commits synced to chapters to make it easy to keep up.

If you work on the frontend like me you may have heard of Storybook (originally called React Storybook). At first you probably dismissed it. Another day, another dev tool.

Yet an increasing number of developers and savvy designers use Storybook to build UIs. Teams at Airbnb, Dropbox, IBM, Lonely Planet, and Mozilla rely on it everyday. And Storybook has grown beyond React to support nearly every major view layer. By now, you might be wondering what the hype is all about?

A tool for the future of UI development

To make sense of Storybook let’s take a brief detour to the frontend landscape. UI development is undergoing a renaissance inspired by new view layers like React, Vue, and Angular.

Folks no longer think in pages but in components. Components still output the familiar HTML, CSS, and JavaScript triumvirate, but the means of generating that output has evolved.

Throw attributes at a component and watch it render different permutations.

With React, developers have new tools like props , context , and state to render UI. The core innovation shared by these “modern” view layers is the component construct which makes it easy to break down complex UIs into simple modules.

Component-oriented development requires new tooling to help developers concentrate on building UI components. Storybook is the most popular and fully featured UI component tool. It’s also the only tool that supports most view layers.

OK, but what does Storybook do?

Storybook helps you build durable UIs faster. It runs alongside your app in development mode and provides a “sandbox” to build UI components in isolation of business logic or context from your app. This allows you to focus on clearly defining the component API –the set of inputs a component takes.

Developers create “stories” by passing a unique set of inputs to a component to yield different variations (similar to specs in unit testing). These stories are indexed and documented in Storybook so you can visually check on them during development or revisit later during testing.

Learn Storybook — a hands-on tutorial

More frontend teams than ever rely on Storybook. But there aren’t many resources on how to use Storybook from first principles.

Tom Coleman and I created Learn Storybook, a free 9 chapter tutorial, to teach tried-and-true patterns for component development using Storybook.

You’ll walk through essential UI component techniques while building a UI from the ground up in Storybook (great for project-based learners).

Build Taskbox, a task management UI

What you’ll learn

You’ll learn best practices sourced from professional teams, core maintainers, and the fantastic Storybook community. In addition, get the wider context to understand why those best practices exist. Each chapter walks through different aspects of using Storybook and is synced to a real commit in a working demo app.

🏗 Setup the development environment
🔨 Build a simple component in isolation
🛠 Assemble a composite component out of simple components
💡 Wire in data with containers
💻 Construct a screen
🚦 Test a UI component library
🚀 Deploy Storybook

Who this is great for

Storybook should be approachable to everyone whether you’re senior, junior, developer, or designer. If you follow along, you’ll grasp the core concepts of isolated UI component development and build a full UI in Storybook without a problem. It’s great for:

👩‍💻 Experienced developers who have heard of Storybook and want an efficient tutorial that highlights key features and workflow
👩‍🎓 New developers who want to learn a tool used by professional teams at Github, Artsy, and Priceline.
👩‍🎨 Product designers interested in UI components and the nuts & bolts of building component libraries.

I hope Learn Storybook helps you, well, learn Storybook!

Contributors welcome

Learn Storybook is open source. Our goal is to introduce Storybook to the world. We’re looking for Vue and Angular contributors (the example code is currently React) and help translating the tutorial to other languages. Also report bugs!

Originally published at Chroma

Beyond Bootstrap –moving from UI toolkit to component library

Dominic Nguyen — Tue, 06 Jun 2017 15:01:01 +0000

Image: Haus-Rucker-Co

The first factory predates the industrial revolution by hundreds of years. Venice’s Arsenal pioneered assembling naval ships out of standardized parts. Engineers of the time discovered that it was quicker and easier to assemble complex things from their constituent parts rather than build them from scratch. Today, we’re seeing this idea of prefabrication and assembly take hold in a different sphere of engineering: building user interfaces.

User interfaces are increasingly assembled from standardized parts. UI toolkits like Bootstrap were among the first to provide a generic collection of parts for web UIs. These toolkits enabled developers to easily find and apply patterns in their apps.

Companies too recognized the value of having their own UI toolkit. They created living styleguides to match the look and feel of their brands. However, building a styleguide requires significant resources so only larger teams tended to invest in them.

A key change in the industry has come with the advent of UI components â€Š–â€Šbuilding blocks of user interface akin to Legos. Components simplify building custom UI toolkits because they encapsulate design patterns in modular standardized units.

This paradigm shift allows teams of any size to create “ component libraries tailored to their exact needs and brand. Today, I’ll walk through how we got here and the process of creating your own component library.

User interface assembly

Frontend developers build the same user interfaces over and over. There aren’t many functional differences between them. You’ll usually find the standard combination of header, sidebar, lists, and forms.

Throughout history people have found that it’s more productive if people assemble new products from existing parts. User interface engineering is no exception. Composing new views out of existing UI parts is faster than building them from the ground up.

At first these patterns took the form of ad hoc code snippets. They lived in text files stashed somewhere on developers’ machines (pre-Github). Albeit not very shareable, these bits of UI code had enormous utility to the frontend developer.

Bootstrap and UI toolkits

Bootstrap came along and consolidated these pieces of UI code into a single well-documented collection. The key idea of UI toolkits was to provide an inventory of generic/universal design patterns (with accompanying code).

Bootstrap’s designÂ patterns

At the time, the workflow was revolutionary in its simplicity. You copy–pasted markup and got workable user interfaces. UI toolkits made it trivial to scaffold simple sites and line-of-business apps.

The concept of UI toolkits had an enormous impact on design and development. It proved that designers could ensure user interface consistency throughout the development process. It also highlighted how easy it could be to create UIs using a toolkit to developers.

Living styleguides

Living styleguides are organization-specific UI toolkits. Teams saw the inherent value in UI toolkits, but often had specific look and feel requirements. They couldn’t just adopt Bootstrap, Foundation, or Semantic.

The classic downside of something like Bootstrap is that you must adhere to its prescribed idioms and styles. Sites that rely on popular toolkits tend to look the same. You can probably see why this isn’t ideal for a company looking to stand out in the market.

Like Bootstrap, living styleguides provided a similar inventory of design patterns along with code, but these patterns reflected the particulars of company branding and design.

At the scale of Yelp, Walmart or the US government, reusing existing design patterns yielded massive efficiency gains. Living styleguides made it easy for big companies to create a consistent look and feel across their web properties.

However, creating a living styleguide is a significant undertakingâ€Š–â€Šoften requiring coordination from the top down. There are countless UI permutations to design, build, and maintain accompanied by the daunting task of getting buy-in from everyone on the team. Realistically, the luxury of living styleguides was reserved only for large teams.

Component libraries

Component libraries are a pragmatic way for teams –large and small– to get the ease of Bootstrap, the customizability of living styleguides, and the flexibility of modern view layer technology.

The widespread adoption of view layers like React, Angular, and Vue compel teams to decompose UIs into simple components. These components serve as the building blocks of apps; the collection of components is the basis of a component library.

A self-contained DatePicker component

Components: self-contained functionality

As a construct, components are more powerful and easier to use abstractions than raw code. They are self-contained pieces of functionality that have well-defined inputs and outputs.

Self-containment encourages developers to scope functionality, markup, and styling(this area is rapidly evolving) at the component-level. No need to rely on toolkit-level JavaScript or stylesheets, with UI components all of this can be encapsulated in the component.

Small teams can build component libraries

The focus on components –the user interface equivalent to Legos– makes it easy for small teams and individuals to start building their own inventory of custom design patterns piecemeal. Since you progressively accumulate UI components, the startup cost of a component library turns out to be less than building a living styleguide (which often requires much forethought and planning).

In addition, flexibility is inherent to component libraries. Each component can be added, updated, or replaced without affecting the integrity of the library. This means that you’re not constrained to one UI toolkit at a time, you can mix, match, and customize components from around the web as needed.

How do I get started?

Whether you have an existing app with components or are building one anew, starting to accrue the benefits of a component library is easy. Since you’re able to add components individually and the tools to build libraries tend to be development-only by default, the cost to try a component library is close to nil. Let’s see how to get started in 4-steps.

1. Get a place to “store your components.

Components are often buried inside apps. This isn’t ideal because people have to scour through directories and screens to see components in action. What you want is a central place to catalog and visualize your components. You can find these library-like features in a component explorer.

Component explorers

React: Storybook, Cosmos, Carte Blanche, Styleguidist
Angular: UI Storybook, Playground
Vue: Vue play
Ember: Freestyle
Clojure: Devcards
Meteor: Chromatic

2. Index existing components

Once you get a component explorer, it’s time to index your app’s existing components so they can be found.

Start by importing the component explorer tool at the top of your component file (the exact syntax varies between component explorersâ€Š–â€ŠI’m simplifying for readability).

import { specsOf } from â€˜@component-explorer/explorer’;

Next, write your first “test states for that component as specs. For instance a Toggle component might have default and active state.

specsOf(â€˜Toggle’) 
  .add(â€˜default’, () => <Toggle active={false} />) 
  .add(â€˜active’, () => <Toggle active={true} />)

Then checkout the component in action via the component explorer. Repeat this process to index other components and grow your library.

A toggle component in Storybook

3. Browse thousands of open source components

There are plenty of readymade UI components available from organizations like Salesforce, AirbnbEng, and Google. Familiar UI toolkits like Bootstrap and Foundation have also been converted to UI components. For complex components like graphs, I suggest browsing what is already available before building something from scratch.

4. Add open source components to your library.

Once you’ve found something you like, it’s time to put it in the component explorer (as we did in step 2). This gives you an isolated playground to tweak the readymade component before integrating it into your app.

Let’s simulate the process of adding an example LineGraph component to the library.

Installing via NPM: npm install linegraph

Create a new file to import the component, the component explorer, and record the test states as specs.

import { specsOf } from â€˜@component-explorer/explorer’;
import LineGraph from 'linegraph';

Add a few test states to adjust the look and feel in isolation with your component explorer. Here’s how the component would look with a default and active state:

specsOf('LineGraph')  
  .add('Default', () => 
    <LineGraph data={latencies.map(latency => ({    
      latency,
      count: 5000 + Math.random() * 15000,  
  }))} />)

.add('Active', () => 
    <LineGraph active={true} data={latencies.map(latency => ({    
      latency,
      count: 5000 + Math.random() * 15000,  
  }))} />)

Once you’ve adjusted the specs to match your needs, it’s simple to add the component wherever you need it in your app and use similar specs to achieve the intended appearance.

Beyond Bootstrap

Bootstrap pioneered the use of readymade user interfaces. People could pull interface elements off the shelf to rapidly build UIs. However, it required adherence to prescribed idioms and styles.

Living styleguides allowed organizations to offer the same rapid development experience as Bootstrap with a custom look and feel. The challenge was that these styleguides required significant effort.

A component library is a practical middle ground that enables rapid development and customization without needing much in the form of organizational momentum. Here at Chroma, we are big proponents of component libraries because they tend to guide teams into reuse and UI consistency without being authoritarian about it.

https://medium.com/media/c066cf834200d80e25b62a6de730a4a6/href

Learn more about UI components:

This post was originally published on blog.hichroma.com

Prefabricated components –the case for building UI components in isolation

Tom Coleman — Tue, 16 May 2017 17:17:51 +0000

Y:Cube by Rogers Stirk Harbour +Â Partners

One of my favourite TV shows is “Grand Designs”. It’s a British homebuilding show where host Kevin McCloud observes people building a wide variety of homes. If you’ve been following the show, as I have, there is a trend that’s hard to ignore.

Housing projects, especially less expensive and quicker ones, are increasingly using prefabricated (“prefab”) materials. The idea of prefab is to construct components of a house in a factory before shipping them to the job site where they are joined together. It replaces the traditional method of constructing a home from raw materials on the building site (hammering together wood, setting concrete, etc.).

Costs can be further cut if you use off-the-shelf prefab materials like wall panels in certain “commodity sizes. Anyone who has built an Ikea kitchen is probably familiar with the idea.

Why is prefab such a transformative concept? It’s not hard to understand that building one piece at a time in controlled conditions like a factory, makes construction quick and easy.

What does all this have to do with building software user interfaces (UIs)? Prefab parallels the process of developing UIs from components. We just need a “factory to construct our components “off-site”. That factory is the Component Explorer.

Building apartment housing in isolation (Capsys)

Component Explorers

A component explorer is a tool which allows you to work with a single component from your app in isolation. So rather than building a component “on-site of the app screen where it is first used, you use a tool that isolates the one component.

Component explorers help you build components in isolation

In order to do this, you must document the states of the component that you are interested in. This means rather than manipulating your development app into the right configuration to see your component, you explicitly write down the state you care about.

The component explorer is the factory for components.

Building on-site vs prefabricating: a case study

The idea of prefabrication is to frame, insulate, wire, plaster and paint a wall in a factory rather than on-site in unpredictable conditions. You don’t need a lot of construction experience to see why this approach makes sense. In fact, if you are like me (and most software engineers, I reckon) you are probably now thinking it’s crazy to do it any other way.

If you don’t have the same reaction to the idea of prefabricating a UI component, perhaps we need to look a little closer at the two methodologies.

Let’s consider a case study: building a complex histogram for an analytics product, used in various contexts to display various latency distributions.

Our example histogram component

On-site

If I’m building the histogram “onsite”, then I’ll start with one of the screens where it’s used.

1 I’ll start by thinking about the most obvious use-case for the component then fill my database with some typical-looking data. I’ll build the component directly on screen where it’s supposed to live.

for (i = 20; i <= 120; i+= 10) {
  db.latencyCounts.insert({
    queryId: 'abc-123',
    latency: i,
    count: 5000 * Math.random() * 15000,
  });
}

A query to generate some test data; what that data looks likeÂ in-situ

2 Now, I might think about a different style of data, perhaps an new user with a limited set of measurements. I’ll delete some data from my database and tweak the component to make sure it still looks OK.

for (i = 20; i <= 120; i+= 10) {
  if (i !== 110) {
    db.latencyCounts.update({
      queryId: 'abc-123',
      latency: i,
    },
    {
      $set: {
        count: Math.random() * 1000,
      }
    });
  }
}

Low data resolution

I’d better check the data I created in step 1 to ensure my changes didn’t adversely affect my original implementation, though.

3 What about when there’s no data at all? Let’s try that (making sure we check any implementation changes against steps 1 and 2’s data).

db.latencyCounts.remove({ queryId: 'abc-123' });

No data

4 Let’s get this thing out to QA, we’ll deploy to a staging server. Oh! We noticed it doesn’t render well in the loading state. How can we see that locally? Maybe we need to hack our server to “hang so we can work on the loading state. Better check our changes against steps 1–3 too.

Loading

5 Design has come back with a bunch of fiddly visual tweaks based on their testing (are we sure they tested all the states we worked on? Here’s hoping!). Let’s make those changes then ensure they don’t break the states from steps 1–4

With last minute designÂ tweaks

6 After deploying to production, a user reports the graph looks bad for their unique, unusual data set! Better (anonymously) import that data into our local db and fix it. Oh, and we should run through states from steps 1–5 again.

This process happens over extended time periods so it may not be easy (or fun) to remember the commands to reproduce step 1 by the time we get to step 6. Let’s be honest, there’s probably a good chance we won’t actually check it!

We write tests to encode known use cases and avoid regressionsâ€Š–â€Šbut writing tests for UIs is hard.

Regressions happen when use cases are forgotten or ignored.

Prefab

When prefabricating a component, instead of indirectly maneuvering our component into the state we want to work on, we carefully detail the exact states we are interested in. The component explorer is a tool that allows us to experience the component in each of these states in isolation.

Typically, this means that each step is simpler; rather than messing with the database or carefully tailoring our development account to contain the right information, we just document the state we want to experiment with.

import { storiesOf } from '@kadira/storybook';
import Histogram from './Histogram';

const latencies = [];
for (var i = 20; i <= 120; i += 20) {
  latencies.push(i);
}

storiesOf('Histogram')
  .add('Typical', () => <Histogram data={latencies.map(latency => ({
    latency,
    count: 5000 + Math.random() * 15000,
  }))} />)
  .add('Low data', () => <Histogram data={latencies.map(latency => ({
    latency,
    count: latency === 110 ? 5000 + Math.random() * 15000 : Math.random() * 1000,
  }))} />)
  .add('No data', () => <Histogram data={latencies.map(latency => ({latency, count: 0}))} />)
  .add('Loading', () => <Histogram loading={true} />);

Listing the states up front helps us to think clearly about the states that the histogram supports. Each time you work on a new state, you encode a permanent version of it. Every time we need to check back a state we previously worked on, it’s simply a matter of clicking back in the component explorer.

Like a set of tests, this is an accruing set of artifacts in our project that will enable us to maintain quality over time and avoid regressions. We can also show each state to our designer for refinement –and we get it for free! In most cases it is easier to build out a state than to maneuver the app into the right configuration.

Barriers to prefabricating

Just like folks in the construction industry who may object to prefabrication (“that’s not how we do things”), developers sometimes resist building components in isolation. There are a variety of common worries; here’s a short list (let me know if you have others!), and some reasons why they’re less problematic than you may think.

Too much work

Building states feels like writing tests. It’s something that many developers think they “should do but when under time pressure, put off.

As I mentioned, like tests, component states are an accruing benefit. However, in our and many others’ experience, developing in isolation is usually less –often far less– work than developing in context. There’s just less fussing around.

Don’t assume the job is done after step 1 of our case study above! Although it might feel like you can build the component quickly, it’s rarely the case that you don’t have to keep revisiting it, and to do that properly, you need to check all the states that you’ve considered in the past.

Hard to isolate components

Some coding patterns, or just time constraints, lead to components that are hard to render on their own. They require some kind of application context (“environment”) which makes them difficult to separate out in a component explorer.

Developing in isolation will naturally steer you away from writing components like this. Aside from being easier to reuse, and simpler to test, such environment-independent components are generally good practice to develop.

Conclusion

I’m confident that once you start working on components in isolation, you’ll soon be prefabricating the essentials of your appâ€Š–â€Šperhaps even entire screens!

If you’re just dipping your toes, the best place to experiment with isolation is on your next complicated component build. The histogram above is a good example because it has many different inputs that all need to be checked for correctness. So next time you start working on a doozie, give a component explorer a try!

There are many other benefits of isolating components using component explorers like communication within the team and visual testing. Here at Chroma we are huge proponents of developing in this fashion (we call it “Component-Driven Development”), and if you want to hear more about the benefits, signup to our mailing list.

https://medium.com/media/e6ea71d37dd27a6a941e5c78ec8d8bf4/href

This post was originally published on blog.hichroma.com