Swizec Teller - a geek with a hatswizec.com

Senior Mindset Book

Get promoted, earn a bigger salary, work for top companies

Senior Engineer Mindset cover
Learn more

    What I learned making my first open source React component

    Dude, open source is hard. People really do this every day!? 🀨

    I open sourced my react-lazyload-fadein component this weekend. 75 stars already. I guess people like it πŸ’ͺ

    It builds on top of react-lazyload to give you a nice fade-in effect when your component is ready. Lazyload means users load less stuff and your page appears faster because you're not rendering complex expensive components until they're visible. Fade-in means they don't pop onto the page and startle your user.

    When you lazyload components without FadeIn

    Building the component was pretty quick. Learn the new API for React transitions, realize images have an onLoad event, package it up in a component. Easy πŸ‘Œ

    Then open sourcing it… that took 4 hours. Because open source is hard.

    You can see half of the process on YouTube. The other half got banned because of the music.

    Here are a few lessons I learned:

    Use nwb to get started

    When you start a new React app, you use create-react-app. It sets everything up for you. Babel, webpack, a dev server, some HTML, production builds, all the things.

    But you don't need most of that when you're building a component. You wouldn't want to minify before publishing to npmjs, for example. You definitely don't need to add a bunch of HTML and CSS.

    I mean, probably. You might need styling.

    Point is, you are trying to publish an isolated component. You still need some build step for shipping and some way of running the component when testing. But you don't need CRA.

    Use nwb instead.

    nwb new react-component react-bla

    This sets you up. A src folder for your code, a demo folder for your demo app (plus dev server and hot loading, yay\o/), a test folder that you should use and I didn't, some build stuff for shipping…

    Basically, it gives you everything you need so you can focus on your component and don't have to worry about the details.

    Make a demo page with docs

    You need a demo page so you can show off your component in action. People are visual creatures, and they don't like to read descriptions.

    Show them what you built.

    react-lazyload-fadein, for example, has a demo page that shows off different ways you can use it. The page is long enough for you to see the fade-in effect.

    The demo page doubles as docs. People can scroll to the integration they like and see how to build it right away.

    That part took a while because nwb's demo pages are quite basic. No Gatsby machinery to slurp in your README file and make a page.

    There's an idea πŸ€”

    Decent docs take time

    People will find out about your component in different ways. Some will see it on GitHub, others will come to your demo page, many will see it on npmjs.com.

    Your documentation has to live in at least two places:

    1. Your README.md file
    2. Your demo page

    Both GitHub and npmjs.com give special rights to your README. It shows up as your component's homepage.

    So it better be good. Add a gif or two. All the code samples someone needs to get started. Explain why they'd wanna use it.

    This duplication is annoying and creates work for you. But it's worth it, I think. Especially if someone could figure out how to slurp in the README file and make that demo page for you πŸ€”

    Support different patterns

    The React community is a bit silly and loves to invent new patterns to bicker about. Function as children, render props, import this way or that way.

    Your component should support everything that's practical. That makes you a good citizen in other people's codebases.

    Someone likes to do import FadeIn from 'react-lazyload-fadein'? They can.

    They prefer import { FadeIn } from 'react-lazyload-fadein'? They can do that, too.

    Wanna use function as children, my favorite? Yep, it works.

    <FadeIn>{(onload) => <MyThing onLoad={onload} />}</FadeIn>

    Using render props in your codebase? That works too.

    <FadeIn render={(onload) => <MyThing onLoad={onload} />} />

    You shouldn't have to compromise your code style to use my component. My job isn't to encourage this or that pattern. My job is to give you a tool that you can use to make your life easier.

    And you know how hard it is to support both patterns?

    render() {
        const { children, render } = this.props;
        return (
                {children && children(this.onLoad)}
                {render && render(this.onLoad)}

    Yeah, sooooo hard. Just do it.

    Do it more often

    People don't want to learn to fish. People want fish.

    Building things and writing about them is great. Great for your skills, great for your career, great for just about everything. Gives you more luck.

    Even just tweeting or posting on FB about what you're working on is better than keeping mum and chugging away. Ask anyone.

    You know what's even better?

    Giving people tools.

    You're not just telling them what to do, you're ensuring they have less to do. Everyone loves having less to do.

    I should do it more often, too. :)

    This is a Livecoding Recap – an almost-weekly post about interesting things discovered while livecoding. Usually shorter than 500 words. Often with pictures. Livecoding happens almost every Sunday at 2pm PDT on multiple channels. You should subscribe to My Youtube channel to catch me live.

    Published on February 21st, 2018 in Front End, Livecoding, OpenSource, Technical

    Did you enjoy this article?

    Continue reading about What I learned making my first open source React component

    Semantically similar articles hand-picked by GPT-4

    Senior Mindset Book

    Get promoted, earn a bigger salary, work for top companies

    Learn more

    Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.

    Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.

    Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help πŸ‘‰ swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.

    Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers πŸ‘‰ ServerlessHandbook.dev

    Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization

    Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections

    Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog

    Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com

    By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❀️

    Created by Swizec with ❀️