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 (
        <div>
            {children && children(this.onLoad)}
            {render && render(this.onLoad)}
        </div>
    )
}

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.

Learned something new? Want to become a better engineer? ๐Ÿ’Œ

Join 9,400+ people just like you already improving their skills.

Here's how it works ๐Ÿ‘‡

Leave your email and I'll send you an Interactive Modern JavaScript Cheatsheet ๐Ÿ“– right away. After that you'll get a thoughtfully written email every week aboutย React, JavaScript,ย  andย lessons learned in my 20 years of writing code for companies ranging from tiny startups to Fortune5 behemoths.



Man, I love your way of writing these newsletters. Often very relatable and funny perspectives about the mundane struggles of a dev. Lightens up my day. ~ Kostas

PS: You should also follow me on twitter ๐Ÿ‘‰ here.
It's where I go to shoot the shit about programming.