I solved my most difficult problem and shared my solution with npm

I was having trouble making image rendering tidy and clean in a project I'm currently brushing up on. I solved it using a component as a wrapper that controls render based on whether or not all images were loaded inside the wrapper's children. I couldn't find any solutions online so I published it to npm.

Its name is react-on-images-loaded. Check out my demo and see how you like it. It's a more versatile version of my original solution. It's okay if you hate it and uninstall. You might run into problems as well. If either of those happen, kindly take the time to tell me what's happening or send me the hateful message here ! :)

It was shocking easy to make my own package

In the same way create-react-app makes setting up a React.js app a breeze, generator-react-component exists for anyone looking to publish their own npm package. Note that you have to make your own repo when using react-component. That's the only thing it won't do automatically.

Key commands for generator-react-component

generator-react-component gives you 2 all-encompassing terminal commands to transpile, publish, and upload changes to your sample website. But I'm not a fan, because any error in one of those operations halts them all. Here are the ones I use. 

  npm run build //transpiles example website and component to ES5
npm run publish:site //uploads example.js website to your github repo
npm version <`newversionnum`> //sets new version of package before you
//upload to npm
npm publish //publishes package to npm

npm gives you 24 hours to unpublish any awful releases

When you have precisely zero downloads and are messing up left and right, it's pretty much ok to unpublish releases. But unpublishing in general is done in poor taste, because it betrays the trust of your userbase and is considered rude.

Comments

Post a Comment

Popular posts from this blog

Contrasting var and ES6s new declarations: let and const

let and const are two new declaration types in JavaScript, which have the ability to completely replace var declaration. To use them effectively, and understand why they can be a direct replacement, it's important to understand how they work. var is function scoped. It is hoisted and initialized at the top var , regardless of where it is assigned, will become declared and initialized at the beginning of the function. This means that any variable you declare will be available everywhere inside the function. This process is referred to as hoisting. Hoisted variables with var are declared and initialized at the top of the function, but have no value All variables that are declared and initialized with var are initialized as undefined . They have no value until you reach the line of code that assigns it a value. const undefinedConsoleLog = _ => { console.log(sadlyUndefined) //undefined var sadlyUndefined = 'declared by var, und
Read more

Modularity vs. Abstraction. Which is More Important?

Coupling? Bad. Coupling is the enemy of modularity. Coupling creates the need to understand the inner workings (implementation details) of multiple functions/objects/entities in order to understand what the code is doing. Abstractions? Good. Abstractions are a natural concept in this world. I do not need to understand how a car works in order to drive mine. In programming, being able to use functions and components without understanding their inner workings is a sign of well-designed abstraction. A clear and tight interface that is easy to work with is a sign of good code. Good modularity with bad abstractions? Could be better. It's not fun to read, but at least you know where everything is. This tends to create large components and classes, but I see it as the lesser of two possible evils. Bad modularity with good abstractions? The worst spaghetti possibl
Read more

Unit testable components pt.3: Testing components

My approach to component testing There are multiple resources that show how to test components. When you read between the lines, they are actually describing their philosophy on how a component should be tested. My tests are basic and practical because my components are dumb My components have the following properties No api calls Small encapsulated components Minimal Redux actions As a consequence, my tests have the following principles Shallow mount component directly. Ignore Redux's connect higher order function (HOF) in test
Read more