npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@boulevard/react-components

v1.0.0-beta.17

Published

React components.

Downloads

23

Readme

React Components

A component library written in React.

Contributing

First follow the instructions for contributing here.

Storybook

Storybook is a tool for building UI component libraries in isolation. Once you've bootstrapped the monorepo you will be able to launch Storybook by running the following command:

This command should be ran from the package root. You can also run this command from the repo root using lerna.

$ npm run storybook

Storybook should be used to explicitly show each state your component can be in. This provides three affordances:

  1. Manual Visual Testing

    A person can manually confirm that each state of your component looks right. In the future we can generate snap shots from our stories so that manual confirmation is only necessary if something changes.

    You shouldn't worry about making your component interactive. Component interactions will be tested with automated tests. Again we are only concerned with what our component looks like in different states.

  2. Transparency With Design

    Our design team can visually inspect a component and use that in designs or prototypes.

  3. Shared Development Environment

    An engineer can easily pickup where another engineer left off without having to create a fresh development environment for interacting with components.

    Note: This isn't your own personal playground for components. If you need a sandboxed environment for working on components you can name your private stories with the .private.stories file extension. For example, a file of the name foo.private.stories.tsx will not be checked into source control.

Writing Test

Tests are written using Jest and Enzyme. The CI pipeline is configure to fail unless a certain threshold of coverage is met. You can run the test with the following command:

This command should be ran from the package root. You can also run the tests from the repo root using lerna.

$ npm run test

Our testing strategies will evolve overtime as we evolve as engineers but I have identified two main testing criterial for interface components that I believe are a good start.

  1. Testing Component Interactions

    Interaction testing involves testing users actions as they would be performed by a user on a specific platform. You could think of these as a type of integration test because they are dependent on the platform. For example, testing that clicking a button triggers some output. These types of tests SHOULD utilize Platform APIs and assert that the component responds properly to the user action.

    Note that a full platform environment is not strictly necessary. For example, jsdom is sufficient for most interactions in a browser environment.

  2. Testing Component APIs

    If your component exposes a public API then these methods should be tested. For pure functions writing these tests are usually straight forward because your output is always the same given the same input (think functional programming). That is why I would recommend always making your functions pure if possible.

Tool Glossary

The following tools are used by this package:

  • Boulevard Lib - A standard JavaScript library for portable modules.
  • Emotion - A CSS in JS solution.
  • Enzyme - A testing utility for testing React components.
  • Lodash - A modern JavaScript utility library.
  • ESLint - A linting utility for JavaScript.
  • Jest - A JavaScript testing framework.
  • JSX - A declarative JavaScript templating syntax that implements Virtual DOM.
  • Material UI - Material Design components written in React.
  • React - A JavaScript component syntax.
  • Storybook - A development environment for UI components.
  • TypeScript - JavaScript that scales.