Forem: Josh Kuttler

How to Manage and Create Composable Email Templates with Components

Josh Kuttler — Thu, 07 May 2026 13:09:50 +0000

Every product team eventually hits the same wall with email: a welcome.html file ballooning into a 1,200-line monolith, copy-pasted styles across templates that never quite match, a marketing tweak that breaks billing emails, and an A/B test that takes a week to ship because the "templating engine" lives in a folder no one wants to touch.

Email is one of the last places in modern product engineering where we still tolerate this. We componentized our UI years ago. We componentized our backends. But our transactional and lifecycle emails are still strings of HTML glued together inside a service.

At Bit, we manage every email template - welcome, billing, organization invites, password resets, notifications - as independent, versioned, composable components. Each piece of an email (a title, a paragraph, a CTA button, a card, a footer) is its own component. Each template (welcome, payment-failed, scope-invite) composes those pieces.

This post walks through how we got there, and how you can do the same.

Why "composable" emails matter

Emails have all the same problems as UI:

Consistency. Every email needs to look like the same product. The same brand color on the CTA. The same paragraph spacing. The same footer copy and unsubscribe link.
Reuse. "Action button" exists in 30 templates. "Card with content" exists in 20. The footer exists in all of them.
Change management. When the brand color changes, or the footer text changes, or the unsubscribe URL changes, you don't want to grep 30 files.
Testing. You want to preview a template visually, in isolation, with mock data - the same way you preview a React component.
Ownership. Billing owns billing emails. People owns invite emails. Marketing owns lifecycle emails. They shouldn't all live in one folder owned by no one.

Emails are UI. The fact that they render in Gmail instead of a browser doesn't change the engineering problem. So we apply the same pattern: small, independent components, composed into larger ones, distributed across teams.

The architecture

Our email system is built from three layers, each living in its own namespace:

UI primitives - the small building blocks: email-title, email-paragraph, email-link, email-action, email-card. Each is a component that returns a string of inline-styled HTML.

Templates - composed emails: welcome-email, password-reset-request, billing/payment-failed, org/org-invite. Each imports the primitives it needs and renders a full HTML document.

Aspect - a single email aspect that exposes a slot-based API. Any service can register an email provider (Resend, SES, SendGrid) and any feature can request to send an email through it.

Here is the full layout in our emails scope:

teambit.emails/
├── aspects/
│   ├── email        ← the platform aspect (slot + sendEmail API)
│   └── resend       ← a provider implementation
├── ui/
│   ├── email-title
│   ├── email-paragraph
│   ├── email-link
│   ├── email-action
│   ├── email-card
│   └── get-started
└── templates/
    ├── base-email   ← the shared layout
    ├── welcome-email
    ├── email-confirmation
    ├── password-reset-request
    ├── password-reset-confirmed
    ├── email-notification
    ├── contact-sales
    ├── ...
    ├── billing/
    │   ├── payment-success
    │   ├── payment-failed
    │   └── ...
    ├── org/
    │   ├── org-invite
    │   └── ...
    └── scope/
        └── scope-invite

Every node in that tree is an independently versioned Bit component. email-action can release a v1.2 with a new prop. welcome-email can pick up that release on its own schedule. billing/payment-failed doesn't have to know either exists.

Step 1 - A UI primitive

Let's start at the bottom. Here is the entire implementation of EmailAction - the CTA button used across every template:

export type EmailActionProps = {
  priority?: 'primary' | 'secondary';
  value?: string;
  link?: string;
  marginBottom?: string;
};

export function EmailAction({
  priority = 'primary',
  value,
  link,
  marginBottom,
}: EmailActionProps) {
  const bg = priority === 'primary' ? '#6c5ce7' : '#ffffff';
  const color = priority === 'primary' ? '#ffffff' : '#1d1c1d';
  const border = priority === 'primary' ? 'none' : '1px solid #e0e0e0';

  return `
    <div style="margin-bottom: ${marginBottom || '0'}; text-align: left;">
      <a
        href="${link}"
        target="_blank"
        style="
          display: inline-block;
          padding: 12px 24px;
          background: ${bg};
          color: ${color};
          border: ${border};
          border-radius: 6px;
          font-weight: 600;
          text-decoration: none;
          font-family: 'Lato', 'Helvetica', 'Arial';
        "
      >${value}</a>
    </div>
  `;
}

A few things worth noticing:

It returns a string. Email is HTML - there is no DOM, no React reconciler. We're building strings, but with the same component model.
All styles are inline. Email clients (especially Gmail and Outlook) strip <style> tags and ignore most CSS files. The component is the only place styles can live, so the component owns them.
The API is typed. priority, value, link, marginBottom are all explicit props. Consumers get autocomplete and type errors, exactly as if this were a React component.
It has no dependencies on other email components.

email-paragraph, email-title, email-link, email-card follow the same shape: typed props in, HTML string out.

Step 2 - A shared base layout

Every email needs the same outer shell: the <html> document, the brand logo at the top, the footer with the unsubscribe link. That is base-email:

import { Footer } from './footer';
import type { FooterProps } from './footer';

export type BaseEmailProps = {
  children?: string;
} & FooterProps;

export function BaseEmail({ children, unsubscribeLink }: BaseEmailProps) {
  return `<html lang="en">
    <head>
      <meta name="viewport" content="width=device-width">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    </head>
    <body>
      <div style="background: #f7f7f7; font-family: 'Lato', 'Helvetica', 'Arial'; font-size: 16px; line-height: 16px; color: #1d1c1d;">
        <div style="max-width: 600px; margin: 14px auto; padding: 10px;">
          <div style="width: 100%; margin-bottom: 32px; text-align: left;">
            <a href="https://bit.cloud" target="_blank" style="text-decoration: none;">
              <img src="https://storage.googleapis.com/static.bit.dev/brands/bit-logo-min.png" style="width: 60px; height: 60px;" />
            </a>
          </div>
          ${children !== undefined ? children : ''}
          ${Footer({ unsubscribeLink })}
        </div>
      </div>
    </body>
  </html>`;
}

BaseEmail takes children as a string - the rendered body of the specific template - and wraps it in the brand layout. The footer is another component injected by the base. Update the brand color or the footer copy here once, and every template inherits it on its next install.

Step 3 - Composing a template

Now the fun part. Here's WelcomeEmail - the actual email that goes to every new Bit Cloud user:

import { BaseEmail } from '@teambit/emails.templates.base-email';
import { EmailAction } from '@teambit/emails.ui.email-action';
import { EmailTitle } from '@teambit/emails.ui.email-title';
import { EmailParagraph } from '@teambit/emails.ui.email-paragraph';
import { GetStarted } from './get-started';

export type WelcomeEmailProps = {
  username: string;
};

export function WelcomeEmail({ username }: WelcomeEmailProps) {
  return BaseEmail({
    children: `
    <div style="background: #ffffff;">
      <img src="https://static.bit.dev/emails/welcome-to-bit-cloud.png" width="100%" height="auto">
      <div style="padding: 32px 20px 64px;">

        ${EmailParagraph({
          text: `Hey <span style="font-weight: bold;">${username},</span>`,
          marginBottom: '16px',
        })}

        ${EmailParagraph({
          text: 'Welcome to Bit Cloud, the AI-powered platform for building production-grade software.',
        })}

        ${EmailTitle({ title: 'Build from Scratch', bold: true })}
        ${EmailParagraph({
          text: 'Describe your app with a prompt. Hope AI builds it, validates it, and deploys it instantly.',
        })}

        ${EmailTitle({ title: 'Modernize Legacy Code', bold: true })}
        ${EmailParagraph({
          text: 'Generate modern packages from your legacy projects. Renew your stack one component at a time.',
        })}

        ${EmailAction({
          value: 'Prompt for Production',
          link: 'https://bit.cloud/hope',
          marginBottom: '32px',
        })}

        ${GetStarted()}

      </div>
    </div>
    `,
  });
}

That's the entire email. Notice what isn't there: no inline styles, no HTML boilerplate, no footer markup, no logo URL. All of that lives in BaseEmail and the primitives. This file is purely the content of the welcome email - the words, the structure, the order of the sections.

Compare that to a typical 800-line welcome.html and the difference is immediate. Three months from now, when the marketing team wants to add a section about a new feature, they will edit this file. No one will need to touch base-email, email-action, or email-title.

Step 4 - Sending it through a service

So far everything is just functions that return HTML strings. The last piece is the runtime: something that takes a rendered template and actually puts it in someone's inbox.

We keep this as a small, standalone email service that expose a single sendEmail method that any feature in the app can call.

And anywhere in the app - billing, onboarding, notifications - you render a template and hand it to the service:

import { WelcomeEmail } from '@teambit/emails.templates.welcome-email';

const html = WelcomeEmail({ username: 'jane' });

await emailService.sendEmail({
  to: ['jane@example.com'],
  from: 'hello@bit.cloud',
  subject: 'Welcome to Bit Cloud',
  html,
});

Three things are worth pointing out about this seam:

Templates don't know which provider sends them. WelcomeEmail returns a string. It has no idea Resend exists.
Providers don't know which templates they send. EmailProvider only sees EmailData. To it, every email looks the same.
The service is the only thing that knows about both. Swap Resend for SES tomorrow by registering a different provider - no template has to change.

This is dependency inversion in plain English: the templates and the providers depend on a small interface in the middle, never on each other. It's the same pattern you'd use for a payments service, a storage service, or a search service. Email is no different.

If you're building this inside a Bit Harmony platform, this "service" is exactly what we call an aspect - same idea, just with a slot-based registration API so providers can plug themselves in automatically. If that's not your world, a plain class with a registerProvider method works just as well.

What this gets you in practice

A few concrete wins:

Brand changes are one snap. When we updated our primary brand color, we changed it in email-action and snapped a new version. Every template automatically picked it up on the next install. No grep, no missed templates, no inconsistent buttons.

Teams own their templates. Billing owns templates/billing/*. Organization owns templates/org/*. They don't ask permission to ship a copy change. They snap their own component.

Templates are previewable. Each template is a Bit component, which means it has compositions. Drop it on the dev server (bit start) and you get a live preview with mock props - the same workflow as previewing a React component. We can iterate on the welcome email without sending a single real message.

Type-safety end to end. WelcomeEmail({ username }) is a typed function call. If the template starts requiring a new prop, the call site fails to compile. No more "I forgot to pass the user's first name and the email said Hi undefined," stories.

Versioned and diffable. Every change is a snap. Every snap has a diff. We can see who changed base-email last week and why. We can roll back a single template without touching anything else.

Reuse across products. The same email-action, email-card, and email-paragraph we use in transactional emails are also used in marketing emails, in admin notifications, in our agent-driven hope-finished-generating email. One vocabulary, many products.

How to start, in your own workspace

You have two ways to get this running.

The fast way — ask Hope to build it for you

Hope AI is the AI builder on Bit Cloud. Open a new chat and try a prompt like:

Create a composable email system in a new emails scope. Use the frontend.html/envs/html-cjs-env environment for every component. I want primitive components for title, paragraph, link, and a CTA action button — each returning inline-styled HTML strings. Add a base-email template that wraps content in our brand layout with a footer. Then create three templates: welcome-email, password-reset, and payment-failed.

Hope will plan the scope, generate every component with the right environment, wire the dependencies, and let you preview each template visually before you snap. From there you can ask follow-ups — "add a billing/subscription-cancelled template", "swap the brand color across all primitives", "add an SES provider" — and Hope will handle the changes the same way.

Here's what Hope produced from a single prompt:

The manual way — step by step

If you'd rather build it yourself first to feel the pattern, here's the full path with the commands you'll actually run.

1. Set up the workspace and enable the HTML env

Email components aren't React components — they render to plain HTML strings, server-side, and never touch the DOM. We use frontend.html/envs/html-cjs-env, which compiles to CommonJS so the templates can be required straight from any Node service that needs to send mail.

# Initialize a workspace if you don't have one
bit init my-emails-workspace
cd my-emails-workspace

# Install the HTML env so its generator templates become available
bit install @frontend/html.envs.html-cjs-env

Then add the env to the generator section of your workspace.jsonc:

"teambit.generator/generator": {
  "envs": [
    "frontend.html/envs/html-cjs-env"
  ]
}

Run bit templates to confirm — you should see the html template listed.

Configure your scope, every Bit component lives in a scope — that's what shows up in the package name (@your-org/emails.ui.email-title) and what teams use to find your work. Set it once in workspace.jsonc and every new component you create will belong to it automatically:

"teambit.workspace/workspace": {
  ...
  // every new component will be created under this scope by default
  "defaultScope": "your-org.emails"
},

If you don't have a scope yet, create one at bit.cloud/create-scope.

2. Create your primitives

Start with three: a title, a paragraph, a CTA button. Don't try to model every possible piece up front — add new primitives only when a template actually needs one.

bit create html ui/email-title --env frontend.html/envs/html-cjs-env
bit create html ui/email-paragraph --env frontend.html/envs/html-cjs-env
bit create html ui/email-action --env frontend.html/envs/html-cjs-env

Each one is a tiny function: typed props in, inline-styled HTML string out. Push every style into the primitive itself — Gmail and Outlook strip <style> tags, so the component is the only place styles can live.

3. Build a base layout

One component that renders the document, the brand header, and the footer. It takes children as a string.

bit create html templates/base-email --env frontend.html/envs/html-cjs-env

4. Write your first template

Compose the primitives inside the base. Resist the urge to put inline styles here — this file is purely the content of the email.

bit create html templates/welcome-email --env frontend.html/envs/html-cjs-env

5. Preview, snap, and reuse

# Preview every template visually with mock props
bit start

# When you're happy, validate, snap, and export
bit validate
bit snap --message "initial composable email system"
bit export

Once the first template is in place, the second one is a 10-minute job. By template five, you'll wonder how you ever did it differently.

You don't need a "framework" for this. You don't need MJML, Maizzle, or React Email. The pattern is the point: small components, composed into larger ones, versioned independently, owned by the teams that care about them.

Conclusion

Email is the last unrefactored corner of most product codebases. It doesn't have to be. The same composability that transformed how we ship UI works just as well for what we ship to inboxes. The result is faster iteration, fewer regressions, clearer ownership, and emails that actually look like they came from the same product.

Treat your emails like components. Your future self - and your marketing team - will thank you.

Written by Josh Kuttler, Software Engineer at Bit — building the composable web.

Let's connect — I'd love to hear how you're handling emails (or anything composable) in your stack:

🐦 X: @JoshKuttler
💼 LinkedIn: josh-kuttler

If this post helped, a ❤️ or a follow on dev.to means a lot — and lets me know what to write about next.

How to Publish React Native Components for Reuse

Josh Kuttler — Sun, 07 Jun 2020 11:59:47 +0000

Publishing and reusing React Native components across applications with Bit.

React Native components, just like ReactJS, are built for reuse.

Reusing React native components across applications speeds up your development, makes it easier to maintain your codebase, and makes sure that your users will enjoy a consistent experience at every touchpoint.

However, publishing many components for reuse can also be a challenge that requires a lot of work, documentation, and teamwork. This work can be streamlined, simplified, and scaled using new tools built for this purpose.

Bit is an open-source tool that helps you develop, publish and manage components across many applications. It is completed by the bit.dev platform, where all your components are organized, documented, and become available to reuse. It streamlines the process of publishing and documenting JS components.

Example: Exploring React components published on Bit

In this post, I’ll show how to use Bit to independently version, publish, and document React Native components from, essentially, any React Native app.

My published components will then be available on a public collection on Bit.dev, where others can read their docs, try them in a live playground, and install them using NPM, Yarn, or Bit. This collection can be gradually expanded to create a fully functional reusable system of components.

The “My Store” app and its published components

Building a React Native Store App: “My Store”

Demo project on GitHub:
JoshK2/mystore
A simple products list store build with React Native components and then shared them to a collection on bit.dev.

npx react-native init mystore

Any store needs some way to present its products. To make that happen, I’ll create 3 components:

Product: Shows the image, title, description and price.
Button: Adds the product to the shopping cart.
Products list: Receive a list of products and displays them vertically.

src
└── components
├── button.js
├── product.js
└── products-list.js

For example, the “Button” component:

I’ve used prop-types for all my components. That will serve two purposes:

As with any other use of prop-types, my components will be safer to use.
Bit will use my prop-types definitions to create documentation for each component. That would also be the case with TypeScipt and JSDocs (alternatively, you can add an .md file to your component).

Publishing the “My Store” Components to Bit

Install Bit globally.

npm install bit-bin --global

Initialize a new “Bit Workspace” (in the project’s root directory).

bit init

Track all components under the components directory (similar to git add ). While doing this, Bit will automatically define each unit as a “component” with all its relevant files, dependencies etc. This is very useful when you seek to develop and publish many components in the same repository.

bit add src/components/*

Configure my tracked components to use the React Native compiler available in Bit’s “ENVs” collection.

Wit hBit, we configure a compiler to decouple the soon-to-be-published components from the app’s build setup. This way, we make sure they’ll work in other future environments.

That’s done by importing the compiler as I would with any other published component and adding the -c flag to set it as a compiler (this will be added to Bit’s configurations in package.json )

bit import bit.envs/compilers/react-native -c

Bit lets you version each component independently, which is great for reuse at a slightly larger scale. Tag all components to record all changes and lock versions. The -a flag marks all tracked components. We could also specify the new version number but, here, I’ve left that to Bit.

bit tag -a

Now if you run bit status, you’ll see that each component got its own version. Remember that Bit tracks every component’s dependencies as well as changes to its code, so from now on when you make a change, Bit will help you tag and bump the version of all components impacted by the change.

Publish all tracked components.

For this, I’ll first head over to Bit.dev, open a free account, and create a new component collection. I’ll name this collection “mystore-app-components”. Once done, I’ll continue to publish them to my new collection.

bit export joshk.mystore-app-components

My components are now published on Bit! 🎉
mystore-app-components by joshk · Bit
A demo store components build with React Native - 3 Javascript components. Examples: product , products-list , button

https://bit.dev/joshk/mystore-app-components

All my components are now reusable, and I can share them between the different applications that I or my team are building.

You can browse through the component pages, see each component rendered in Bit’splayground (using an example code I’ve written).

You can choose to either install components like any other package using NPM/Yarn or to “clone” components into your project using bit import .

Imported or “cloned” components (bit import) can be modified in any codebase using them and pushed back with a bumped version. That makes collaboration possible even across repositories.

Happy coding and sharing!

A new version of React Native compiler for Bit

Josh Kuttler — Thu, 23 Jan 2020 17:00:46 +0000

I just published a new version of React Native compiler for Bit
and I would appreciate some feedback.

You can write in the comments section, links to React Native components you exported.

To Install and use the compiler:
https://bit.dev/bit/envs/compilers/react-native

Stars to the repository will be welcome 😉💫

teambit / envs

Component development environments for the Bit community

Envs - Development environments for components

A curated list of Extensions maintained by Bit's maintainers to use as dev tools for components. These extensions implement best practices for distributing components and setting them up to be reused across projects.

Quick links

Browse Envs • Implementing Envs

Compiler/Tester collection • Docs

Usage

Which compiler to use?

Flavor	Env	Import Command
React JS	react	`bit import bit.envs/compilers/react -c`
React TS	react-typescript	`bit import bit.envs/compilers/react-typescript -c`
React Native JS	react-native	`bit import bit.envs/compilers/react-native -c`
React Native TS	react-native-typescript	`bit import bit.envs/compilers/react-native-typescript -c`
Vue	vue	`bit import bit.envs/bundlers/vue -c`
Angular	angular	`bit import bit.envs/compilers/angular -c`
Typescript Vanilla	typescript	`bit import bit.envs/compilers/typescript -c`
Javascript Vanilla	babel	`bit import bit.envs/compilers/babel -c`
Stencil	stencil	`bit import bit.envs/compilers/stencil -c`

Which tester to use?

Flavor	Env	Import Command
Mocha	mocha	`bit import bit.envs/testers/mocha -t`

What is Bit?

Bit makes it easy to share and manage components between projects and…

View on GitHub

How to comma-separate your number in JavaScript

Josh Kuttler — Thu, 19 Dec 2019 10:56:15 +0000

I created a simple function that does the trick with a regex expression.

The function receives either a string or a number and returns the formatted number with correct commas:

formatNumber(number) {
    number = number.toString()
    return number.replace(/(\d)(?=(\d\d\d)+(?!\d))/g, "$1,")
}

I wrote this function in TypeScript and added tests.

I've exported it to bit.dev with a live demo and docs.

Also, it can be easily consumed with NPM/Yarn/Bit.
https://bit.dev/joshk/jotils/format-number

If you have a better way to write this function, please write a comment.

Build a Tic Tac Toe App with TypeScript, React and Mocha

Josh Kuttler — Tue, 10 Sep 2019 21:16:08 +0000

Learn how to compose a tic-tac-toe app with React and TypeScript components.

A simple Tic-Tac-Toe game built with modularity in mind and shared on Bit. After sharing, my game’s components can be tweaked and tested on Bit’s live PlayGround. Go to my components collection on Bit to test or consume the entire game or just some of its components, using NPM, Yarn or Bit.

JoshK2 / tic-tac-toe-game-using-bit

Simple Tic Tac Toe game built with react-typescript components

Modular Tic Tac Toe Game built with TypeScript and tested with Mocha

A simple Tic Tac Toe game build with TypeScript components and test with Mocha tester then shared them to bit for testing in the live PlayGround and see the result of tests runnig in bit.
Allow users to consume the entire game or just a part of the game components using NPM and Yarn or using bit to consume and modify the component directly inside the project.

The game has multiple options to modify the game rules, like the dynamic dimension of the table, and the number of matching value to win the game.

Try the game in live PlayGround in the project collection

Tutorial

See the full tutorial- build your own modular application with React TypeScript components.

Build a Tic Tac Toe App with TypeScript, React and Mocha.

Import and use the entire game component in

…

View on GitHub

When building a game like Tic-Tac-Toe “with modularity in mind”, it's hard to think of a reason for the UI components to be reused ever again, so I kept my focus primarily on the game’s utility functions.

I chose TypeScript as my coding language of choice — compiled by Bit’s TypeScript compiler and used Mocha for testing.

To install components from my project, first configure bit.dev as a scoped registry (copy and paste to your terminal) — this is done only once! later uses of bit do not require you to configure again.

npm config set '@bit:registry' [https://node.bit.dev](https://node.bit.dev)

and then install the component using Yarn or NPM:

npm i [@bit/joshk](http://twitter.com/bit/joshk).tic-tac-toe-game.game
yarn add [@bit/joshk](http://twitter.com/bit/joshk).tic-tac-toe-game.game

Game Component

The ‘game’ component is my app’s main component — composed using one component from ‘Board’ and two components from ‘Prime React’.

I used the button and the input-text for the configuration screen — test and see the code here.

Install PrimeReact components in your project:

yarn add @bit/primefaces.primereact.inputtext
yarn add @bit/primefaces.primereact.button

After setting the parameters, you can click ‘Play’ and… Play!

Board Component

The board component creates a dynamic table by props, manage player turn and check for the winner. Test and see the code here.

Square Component

The square component is a simple cell that receives value with optional color and sends an event to the board component when the value changes. Test and see the code here.

Empty cell function

‘Empty cell function’ Is a helper function to winner-calc function that checks if there are any empty cells in the game’s table.

Bit lets you see the docs for the component and the results of the tests:

The code of the function:

Winner Calculation

Winner calculation is a function that checks for the winner in horizontal, vertical and diagonal cases.

Bit let you see the docs for the component and the results of the tests:

The code for the function:

The project is available in my bit collection and in my GitHub repository:

JoshK2 / tic-tac-toe-game-using-bit

Simple Tic Tac Toe game built with react-typescript components

Modular Tic Tac Toe Game built with TypeScript and tested with Mocha

The game has multiple options to modify the game rules, like the dynamic dimension of the table, and the number of matching value to win the game.

Try the game in live PlayGround in the project collection

Tutorial

See the full tutorial- build your own modular application with React TypeScript components.

Build a Tic Tac Toe App with TypeScript, React and Mocha.

Import and use the entire game component in

…

View on GitHub

Feel free to comment below and follow me on Twitter 😃

How to Build a Super-Modular Todo App with React and Bit Components

Josh Kuttler — Thu, 05 Sep 2019 16:37:54 +0000

How to compose a highly modular React application with reusable components from 5 different libraries.

The final todo app composition with Bit

Modular programming has been around since the 60s, and the term itself was set at 1968 by Larry Constantine and extended ever since.

Today, in the technological world of component-based libraries like React and with tools like Bit, application modularity can be taken to a whole new level.

We will compose a simple React Todo application using reusable components from 5 popular libraries like Material-UI, Grommet and Semantic-UI. Thanks to Bit, we can quickly isolate and compose these components into an app.

When done, not only we will compose a highly-modular app from reusable components, but we will have a collection of components we can reuse to build more apps. The entire app is shared as a reusable component, which can be extended and composed with other components to build larger apps.

This is very exciting, as it’s a live implementation of full-blown modular application composition with a Lego-like experience.

This is the result of the todo list app:

And here’s the app’s GitHub repo:

JoshK2 / basic-todo-app-using-bit

A highly-modular React todo application composed of reusable components from 5 different collections. Full-blown software modularity.

Highly-modular React Todo application built of reusable Bit components

A basic React todo aplication composed of bit componnets shared from 5 different popular React UI libraries inlcuding Grommet, Semantic-UI React, Primereact and Lodash.

All the reusable components used to build this app are availabe in this collection The final todo application is also available as a reusbale bit component, which can be extended and composed with other components to build larger applications.

Motivation

Demonstrating software modularity in the age of components with React and Bit.

Tutorial

See the full tutorial- build your own modular application with reusable components.

Build a Super Modular Todo App with React and Bit Components.

Wich components I used?

3 Components

For creating the app I decided to divide the App’s code into 3 components:

TodoItem component, text with remove option.
AddItem component, input text area with add button and remove all button.
TodoApp component, this is the main code of the app that includes the TodoItem and the AddItem, so there will be a List with simple code to manage all the components options like remove, remove all and add.

Components 1+2 are modularly composed of components isolated and shared from different libraries- using Bit which helps us isolate, share and manage reusable components to build modular applications.

TodoItem

This component receives a simple text and id for removing the right todo item from the main list as props, and uses a remove icon from the semantic-ui-react component collection.

To install the component, firsy configure bit.dev as a scoped registry (one time action) and then install the component using Yarn:

npm config set '@bit:registry' [https://node.bit.dev](https://node.bit.dev)

yarn add @bit/semantic-org.semantic-ui-react.icon

This is the code of the component, after adding some helping-code to show the remove icon and send remove as an event to the main component when remove is clicked.

Here’s the final TodoItem component with live editing and playground in Bit.

AddItem

This component shows an input text area with auto resize and two buttons, one to add an item to the list, and the second to remove all items from the list. The remove all button work with props to show or hide this button.

So for this, I use input text area and button from primereact, a button from grommet, and icon from grommet-icons.

Install it:

yarn add @bit/primefaces.primereact.inputtextarea
yarn add @bit/primefaces.primereact.button
yarn add @bit/primefaces.primereact.internal.stylelinks
yarn add @bit/grommet.grommet.button
yarn add @bit/grommet.grommet-icons.add

This is the code of the component after adding some helping code to use the Add button and the Remove All button.

AddItem component with live editing and playground in Bit.

TodoApp

This component is the main component that uses the TodoItem and the AddItem components. The component has a list of item and allow to send an initial list as a prop, and receives all the event from the other components to manage the list. Like the add item, the remove item and the remove all item.

So I use List component from semantic-ui-react, and a unique id function from lodash to avoid key error in map function.

Install it:

yarn add @bit/semantic-org.semantic-ui-react.list
yarn add @bit/semantic-org.semantic-ui-react.internal.style-links
yarn add @bit/lodash.lodash.unique-id

This is the main code of the app, it receives and manages all the events that come from AddItem and TodoItem components.

Then all that’s left is to export the components with Bit- and the final TodoApp is now a modular and reusable component, check out the live demo!

All the reusable components we built are available in this collection, including the final todo app

Check the GitHub repo to see all the project’s code:

JoshK2 / basic-todo-app-using-bit

A highly-modular React todo application composed of reusable components from 5 different collections. Full-blown software modularity.

Highly-modular React Todo application built of reusable Bit components

A basic React todo aplication composed of bit componnets shared from 5 different popular React UI libraries inlcuding Grommet, Semantic-UI React, Primereact and Lodash.

Motivation

Demonstrating software modularity in the age of components with React and Bit.

Tutorial

See the full tutorial- build your own modular application with reusable components.

Build a Super Modular Todo App with React and Bit Components.

Wich components I used?

Semantic UI React

semantic-ui-react list component
semantic-ui-react icon component
semantic-ui-react css link component

PrimeReact

primereact inputtextarea component
primereact button component
primereact css link component

Grommet

grommet button component

grommet-icons

grommet-icons add…

View on GitHub

Conclusion

In this post, we’ve seen a very real example of modular software composition with reusable React components and Bit.

When we base our software design on modularity of smaller focused components, we build a better application which is easier to develop, maintain, test and extend. Today, building modular apps becomes more practical- and more fun- than ever before in history.

The same can be done not only with React and not only with frontEnd components. In my next posts, I’ll play with a modular composition for a verity of different technologies and architectures. Thanks for reading and feel free to ask anything! Cheers 🚀

How I Created My Own React Spinners Library

Josh Kuttler — Tue, 03 Sep 2019 16:00:02 +0000

I’ve created an application that uses Airtable as a database. I’ve used a spinner to take the place of a dull blank page which would otherwise be presented to the user in the time that it takes for the requested data to arrive and for the page to get rendered accordingly.

I could have used an existing react spinners library, but instead, I decided to use this chance to learn how to build my own spinners and my own React component library. So, in this post, I’ll show you my library, and an example of how to use a spinner.

React Spinners Library

So, without further ado, here’s my react spinners library (GitHub, Bit). It’s based on loading.io CSS loaders. I’ve added the option to send color and size as props of the component so that it’s easier to customize the spinners. I’ve exported the spinners (twelve in total) to bit.dev so you may easily view and tweak them in Bit’s live playground, and install them as packages with NPM or Yarn (or get their source code using Bit import).

JoshK2 / react-spinners-css

Amazing collection of React spinners components with pure css

React Spinners CSS Loaders (Vue, Angular, Blazor)

Amazing collection of React spinners components with pure css.
The React spinners are based on loading.io and from all over the web.
If you want to add your own spinner, please follow the contributing guidelines.

💅 No extra CSS imports
✂️ Zero dependencies
📦 Spinners can be installing separately

Live Demo

Browse components and explore their props with Bit.
Install specific react spinner component with npm, yarn or bit without having to install the whole project.
Install components and live demo

🚀 List of Spinners

Each component accepts a color prop, and few accepts also size prop.
The default color prop is #7f58af.
Component that accepts size prop have a default size in pixel.

Spinner	color: string	size: number	className: string	style: object
`<Circle/>`	`#7f58af`	`64`	`""`	`{}`
`<Default/>`	`#7f58af`	`80`	`""`	`{}`
`<Ellipsis/>`	`#7f58af`	`80`

…

View on GitHub

For example, this is the circle loader and the component can receive color and size props:

and the code import a very simple CSS code, exactly the same from loading.io CSS loader:

How to use Loader animation in your React.js application?

So, you have a component that sends a request and stores the received data in an array inside your state object. The obvious thing to do is check if the array is empty and if so, display the spinner.

For this example, I used a Facebook spinner with a very simple page that waiting 5 seconds until to show a list of cars.

It’s very simple to use and allows you to show a nice animation loader until the data is loaded.

Also, you can use a custom color in any spinner, just send a color inside the color property, like this:

<Facebook color="red" />
<Facebook color="#cecece" />

Or be crazy and use a random color with my random color generator component.

<Facebook color={getRandomColor()} />

You can see the result with random color in this live demo facebook react spinner.

If you want to see more react spinners examples, check out my react spinners components collection in bit.dev.

For any issue or missing features, please open an issue on GitHub and I’ll do my best.

And of course, if you like it, star it!

JoshK2 / react-spinners-css

Amazing collection of React spinners components with pure css

React Spinners CSS Loaders (Vue, Angular, Blazor)

💅 No extra CSS imports
✂️ Zero dependencies
📦 Spinners can be installing separately

Live Demo

Browse components and explore their props with Bit.
Install specific react spinner component with npm, yarn or bit without having to install the whole project.
Install components and live demo

🚀 List of Spinners

Each component accepts a color prop, and few accepts also size prop.
The default color prop is #7f58af.
Component that accepts size prop have a default size in pixel.

Spinner	color: string	size: number	className: string	style: object
`<Circle/>`	`#7f58af`	`64`	`""`	`{}`
`<Default/>`	`#7f58af`	`80`	`""`	`{}`
`<Ellipsis/>`	`#7f58af`	`80`

…

View on GitHub

And follow me on Twitter to get features updates.