Storybook is a Component Explorer — a tool for working on a single component in isolation — built for React and React Native. As of this article, it’s likely the most popular and fullest featured component explorer out there.
The team here at Chroma, along with others at Airbnb, Slack, and Coursera, rely on Storybook to build cutting edge user interfaces (UIs).
Why should you be interested? Apart from all the benefits of component explorers including developing one component at a…
If you’re new to React, you may have heard about “Higher Order Components” and “Container” components. If so, you may be wondering what all the fuss is about. Or you may have even used an API for a library that provides one, and been a little confused about the terminology.
As a maintainer of Apollo’s React integration — a popular open source library that makes heavy use of High Order Components — and the author of much of its documentation, I’ve spent a bit of time getting my head around the concept myself.
I hope this post can help shed…
Today marked an important milestone in the Storybook project: the release of version 3.0. It is the first release by the new community-lead organization formed around the project.
In this post I’ll cover what you need to know to get up to speed on Storybook 3.0. That includes a little history, what 3.0 signifies, and where the project is going.
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. …
Developing user interfaces has always been a bit of an art. The visual and subjective nature of the medium led to an ad-hoc and ill-defined development process. This lack of process makes it hard for developers to build truly excellent UIs quickly.
Building from the component up forms the core of a solution to the problem. Better yet, if your entire team is on board, you can achieve one of the most rigorous development processes, which is otherwise impossible for UIs: Test Driven Development (TDD).
One central theme has governed the evolution of web properties — the movement from website to web application. This transformation is far from complete. As an industry, it will entail big changes in how we build for the web moving forward. This article outlines the minimum table stakes needed for a modern web UI, and what we can do to rise to, meet, and to exceed a discerning user’s expectations.
Feb 2018: Note this project is not actively maintained . As a scaffolding tool, this is not necessarily an issue (you can generate a project with it and then forget about the tool). A spiritual successor is the
graphql-cli project. Please take a look!
GraphQL is a much-touted successor to REST pioneered by Facebook and adopted by leading organizations like GitHub, Pinterest, and Shopify. GraphQL is a great way to supercharge your app development, and as it’s just a specification, lets you use your choice of server and database technologies.
As a result, it isn’t always easy to get started…
Testing is integral to creating and maintaining high-quality software. Throughout the buildout process, you’ll often find developers and designers doing manual testing — “Does this look right?” However, due to the often subjective nature of interface design, it’s not really possible to write an automated test to capture that “correctness”. This means that companies are faced with a decision between time-consuming manual testing or the inevitable decline in UI quality that results from a lack of a proper testing regime.
The reason testing UIs is hard is that the salient details of the smallest modules of UI (components) are hard…
We’ve managed to get this far in the series without even constructing a server, and this approach has allowed us to build and test a user interface without worrying about the details of the backend. A simple schema has proved enough to get us up to the level of screens.
So far in this series we’ve concentrated on the smallest possible unit of UI, and built from the component up. Doing so has allowed us to develop each component in isolation, figure out its data needs, and play with it in a component explorer without needing to stand up a server or build out screens.
I build things at @hi_chroma (previously @meteorjs / @percolatestudio). Author of @discovermeteor. Exploring how to improve UX through tech, design and perf.