DEV Community: Joey Mink

npm install private-package

Joey Mink — Tue, 31 Oct 2017 13:50:10 +0000

Not everyone can commit code publicly to GitHub and publish packages to npmjs.com. We all benefit from those who do, no doubt. But many of us apply those generous offerings to (and write fresh code for) internal, private projects.

However, that is no excuse to develop large, monolithic internal projects. I declare: modularization and implementation of independent packages is still necessary! Keep projects narrowly-focused. Write independent, useful, reusable packages!

uh, okay idealogical goofball. HTF am I supposed to conveniently make use of private packages when I can't just npm install my-super-secret-pkg?
^ Nay-sayer

Ah, but you can! Read on...

Sonatype has a product called Nexus. It's a well-known Maven (Java) repository you can run privately. But get this: it's not just a private Maven repository ðŸ˜® It's also a private PyPi repository, and ... wait for it ... a private npm repository ðŸŽ‰ðŸ‘ And it's free!

Details about configuring Nexus for npm repositories can be found here. Note that you can easily set it up to proxy npmjs.com and host your private packages at the same time â¤ï¸

This has been crucial in recent projects for me. An electron application we've been developing included lots of complex, independent algorithms that deserved their own projects to house documentation and tests. Rather than bloat the electron project with in-the-weeds details, I was able to put those weeds in their own npm packages and have already begun reusing them in other applications.

If your situation enables it, please keep posting your magic to npmjs.com. We all benefit! But if you can't, running a private repo is a must!

Mobx walks into a package.json

Joey Mink — Fri, 21 Apr 2017 13:48:39 +0000

After a few small React apps, we decided to attack a big one. One that would obtain a lot more data from our server-side API. That data would be shared by many components. Previous experience taught us that disseminating the data to all interested components is tedious. Our approach has typically been:

Fetch the data from the top-level component, setState with the results.
Pass fetch handlers from the top-level component to subcomponents.
Pass top-level component's fetch results to subcomponents via properties.

To oversimplify (with pseudoJS off the top of my head):

class Data {
  luckyNumber = 0;

  fetchLuckyNumber(callback){
    apiCall('/api/lucky_number', callback);
  }
}

<TopLevelComponent data={new Data()}/>

class TopLevelComponent extends React.Component {

  /* plumbing */
  fetchLuckyNumber(){
    data.fetchLuckyNumber((num) => (this.setState({ lucky_number: num }));
  }

  render() {
    return <SubComponent data={this.props.data}
             /* plumbing */
             fetchLuckyNumber={this.fetchLuckyNumber} />
  }
}

class SubComponent extends React.Component {
  render() {
    return <p>
             Lucky number: {this.props.data.luckyNumber}!
             <a onClick={this.props.fetchLuckyNumber}>Update Lucky Number</a>
           </p>
  }
}

The takeaways from that contrived example are few. First, all data fetching for the app is initiated by TopLevelComponent. Second, dissemination of fetched data happens when TopLevelComponent sets state (which triggers a render of subcomponents). Third, subcomponents have to receive handlers from the parent to trigger the fetch and dissemination. This works, but it's verbose -- and gets worse when you have lots of nested subcomponents.

There are libraries out there to help deal with this problem, and a co-worker of mine recommended Mobx. ZOMG I'm so glad he did. Here's why:

class Data {
  @observable luckyNumber = 0;

  fetchLuckyNumber(callback){
    /* luckyNumber assignment triggers Mobx's magic */
    apiCall('/api/lucky_number', (num)=>(this.luckyNumber = num);
  }
}

<TopLevelComponent data={new Data()}/>

class TopLevelComponent extends React.Component {
  render() {
    return <SubComponent data={this.props.data} />
  }
}

@observer
class SubComponent extends React.Component {
  render() {
    /* Referencing luckyNumber automatically makes this component reactive */
    return <p>
             Lucky number: {this.props.data.luckyNumber}!
             <a onClick={this.props.data.fetchLuckyNumber}>Update Lucky Number</a>
           </p>
  }
}

So above, SubComponent will re-render every time the value of data.luckyNumber changes. Mobx will ensure the render method of SubComponent is called, which makes the plumbing so much easier (or better said, non-existent?).

I ðŸ’•.

JS Dialect Rant

Joey Mink — Wed, 29 Mar 2017 18:49:08 +0000

I spent a lot of time at my last job writing JavaScript. We had a set version of node, we had our dependencies more-or-less steady, and we put our heads down and coded. I left feeling like I knew JavaScript! Wheee!

Then I got started with React at my next job. Cool sh*t, no doubt. But ES5 components led to ES6 class-based components. When I tried to consume that ES6 code I would get invalid keyword errors on things like class and import. Huh? transpile it with Babel! Oh, okay...

Then I got into mobx (<- totes dig it!), with all it's decorators and what not (oh Java, I do miss you a little). But when I tried to run that code, I'd get errors about @ being totally uncool. Babel to the rescue!

stage-0, stage-1, transform-decorators-legacy, ...

Woah. WTF language am I writing in now? Some quick duckduckgoes imply that I'm using proposed JavaScript syntax that hasn't even been approved yet. When I look at the code running in the browser, it's all translated into, what I think is, ES5 (which is also es2015?). Okay, enough trivia, there's work to do! It's transpiling successfully? Good, head down...

Anyhoo, I ðŸ’• the functional programming experience JavaScript continues to offer, and I love that the code is so portable in this browser/electron world. But seriously, you need a guru to fully understand:

the state of the JS language
the dialect you're writing in
the translations that babel is performing (and how to configure it)
interpreting the translation when debugging at runtime

Wowzers. I write JS, you may write JS, but I bet yours and mine look a helluvalot different. And I bet my code can't be pasted into your codebase without syntax errors. And to me, that's just kinda like ... woah.

Introducing me!

Joey Mink — Thu, 23 Feb 2017 01:42:53 +0000

Hi! I've been entering instructions into text editors for like 20 years -- cut my teeth on C++, currently geeking out in JavaScript, and filled the time between mostly with Java and Python.

Here are the conclusions I've come to so far with all this experience:

Keep an open mind; what you know now will become wrong later.
Less is more (except in speed).
Don't forget why you're writing what you're writing.

</wisdom>