When implementing a functional component for the first time in TypeScript, this pesky error caught me off-guard. Hope this saves your time.

If you're trying to create a stateless component in TSX you might come up with something like this:

But you will be surprised by this little fellow:

ERROR in ./src/components/home/index.tsx
error TS2324: Property 'children' is missing in type 'IntrinsicAttributes & { children: any; }'.

Wait, what? Well, never mind the problem. We stand in the shoulders of giants, and the giants delivered a solution:

Voilà. Adding the "React.StatelessComponent<{}>" type suffices to make the compiler understand the passed object, because the resulting parameter type becomes:

{} & { children?: ReactNode; }

(Remember, you have to add “@types/react” to your devDependencies in order to have access to React's type definitions.)

As a corollary, if you want to have other props passed down to your component it suffices to define them in the object between brackets, e.g.:

const Button: React.StatelessComponent<{primary?: boolean}> = ({children, primary}) => (...)

And that's it.

Some might argue that TypeScript is verbose. I really think this verbosity (which is optional, and you can buy into on your own time) really pays off. If you're starting a large project, stick around for it and let me know if it worked out.

PS: If you're wondering what are those insane class names I'm using, boy, you need to take a look at Tachyons, by Adam Morse. Never write CSS again. Do you need a better pitch? (I don't.)

How to write a React stateless component in TypeScript with children was originally published in First, do it on Medium, where people are continuing the conversation by highlighting and responding to this story.

The first command to run on your new Mac:

sudo scutil --set HostName <new name>

Finally! I can say goodbye to:

guilherme@Guilhermes-MacBook-Pro ~>

and hello to:

guilherme@trinsic ~>

PS: You should also check out the awesome iTerm2 terminal emulator along with the excellent fish shell.

Change your Mac OS X hostname for a better looking terminal prompt was originally published in First, do it on Medium, where people are continuing the conversation by highlighting and responding to this story.

Around 2494 years ago, a battle happened on a narrow coastal pass called Thermopylae. In this battle, 300 spartans and a thousand more soldiers led by King Leonidas held the pass for three days against an overwhelmingly larger Persian army. They were eventually betrayed and lost.

This weakened and delayed the Persians, but the Greeks were forced to retreat to the Bay of Salamis nonetheless. A while later, Themistocles, an Athenian general, led the navy to a decisive victory at the Battle of Salamis which broke the Persians and eventually turned the tide of war.

These battles are believed to have changed the course of history. By stopping the Persian invasion, they allowed the Greek culture to prosper and develop. Many historians believe that a different result might have significantly changed the western civilization as we know it.

Leading by example

Both battles have something in common: the Greek leaders were absolutely committed to the result of their armies. Both offered their lives and spared no expense.

Unlike Xerxes, the Persian king who commanded from afar, these generals were fighting alongside their soldiers, not above them. They did not ask for anything more than they themselves were willing to give.

And this, in a nutshell, is the meaning of leading by example: if you are not interested in fighting the fight along your soldiers, you might as well quit — because they will stop respecting you… sooner or later.

Lead by example or don’t lead at all was originally published in First, do it on Medium, where people are continuing the conversation by highlighting and responding to this story.

Let’s consider this array of students and these utility functions for the examples:

Filter

filter gives us a new array which only includes the values that pass a truth test. Let’s get all the approved students names.

Pluck

pluck extracts a property from each object on a list. Now we can make our previous code simpler:

Group By

It would be useful to get the averages from each class.
Turns out groupBy is just the right tool for the job. It returns a map, grouping results in arrays. Let’s have a look:

Notice that the keys of the map are the result of the function application. In this case, we are simply grouping by a property. Underscore offers a simpler way of doing this:

Flatten

But, hey! We didn’t actually get the averages. Well, flatten makes this easy by un-nesting arrays:

Every

Let’s find out if all students in a class are approved. You guessed it, every is the tool for the job.

Chain and value

Until now, we have been applying simple, individual transformations to our data. Sometimes, we need to combine multiple functions successively to achieve what we want.

Luckily, Underscore has got us covered. You can use chain to wrap an array, then call other Underscore functions on it. Then, you use value to unwrap the result. Let’s see an example with chaining:

As you can imagine, this gives us the minimum grade of all approved students. See? We created a complex operation simply by chaining together Underscore functions. That’s the power of chain.

There’s more

There are many more interesting functions over at Underscore’s documentation. If you are in doubt on how something works, you can always open Developer Tools directly in the Underscore site and try it out! Try copy and pasting the code from these examples there for a start.

Getting more functional with Ramda

In his excellent talk at HTML5DevConf in 2013, Brian Lonsdorf (@drboolean) points out that Underscore could better promote functional programming if the parameters were reversed, so as to allow currying and composing.

If you want to dig deeper, I really recommend watching the talk and getting to know Ramda, which is like Underscore but actually functional. It really lends itself to better programming practices in some impressive ways.

Thanks for reading, and feel free to send me questions. Glad to help!

Chain your solutions with Underscore was originally published in First, do it on Medium, where people are continuing the conversation by highlighting and responding to this story.

From The Lean Startup to Good to Great, from Tribal Leadership to Zero To One, we are constantly discovering new, useful ideas that guide our day-to-day decisions.

Yet few works have captured the essence of a startup as concisely as the Spotify Engineering Culture videos. In the two part series, Henrik Kniberg delivers incredibly impactful startup insights based on the culture at Spotify.

In this post I will highlight my favorite quotes from the videos regarding autonomy and alignment— why they're essential to startups and how to achieve them.

Rules are a good start, but break them when needed

(00:26)

All models are wrong, but some are useful.
 — George Box

When a team is in complete chaos, a process like Scrum may be useful to start organising and measuring it’s work. Clear rules have an advantage: it’s pretty obvious if you’re following them or not. This makes it easy for an immature team to advance to a more organised stage.

However, Scrum isn’t perfect, as multiple articles like to point out from time to time.

Autonomy means being able to choose what works. A motivated team may soon find itself hampered, instead of helped, by lots of rules. As it matures, a team naturally discovers and selects which rules actually work on their unique context. It’s important to let go of blind discipline and adapt to the actual needs.

Rules will eventually slow you down, so you must adapt and keep only the essentials.

Autonomy makes us fast

(02:02)

The fall of managers may have been a surprise four years ago, but now it’s pretty common-sense. If you need a layer of people to manage people, you are not being efficient — and you are definitely not fast enough. As Paul Graham puts it:

Companies will inevitably slow down as they grow larger, no matter how hard they try to keep their startup mojo.

This happens because, as they grow, companies try to add structure to compensate for harder communication. However, more structure necessarily means less autonomy. When people must constantly report and coordinate, they cannot move as quickly.

Small teams, on the other hand, move fast. Carl Waldekranz, CEO and co-founder of Tictail, believes that “small teams are automatically in sync at all times”. He suggests that teams should operate as startups: 3 to 5 people and fully autonomous.

There’s a reason why startups look like they work much faster than big corporations: they actually do. Maintaining autonomy is paramount to keeping that speed. But there is only one way to scale autonomy…

Alignment enables autonomy

(03:05)

Unmotivated people need very close guidance. They fail to see the big picture and must be told what their next step is, every step along the way. This often happens when leaders choose to micro-manage instead of sharing their vision.

However, when an objective is clear to a team of motivated people, everyone knows what’s their role in getting there. When people are aligned they do not need to coordinate as heavily. They can make decisions by themselves — and they trust each other to make the right decisions.

The leader’s job is to communicate what problem needs to be solved.

Motivated people who are granted autonomy and trust don’t need to be told what to do. They must only be aligned on what’s the destination.

Spotify Engineering Culture — Lessons on Autonomy and Alignment was originally published in First, do it on Medium, where people are continuing the conversation by highlighting and responding to this story.

For all the obtuse native functions JavaScript offers (“wat”.blink()?), there isn’t a simple, native way to parse cookies and get the value of a single key.

The inter-webs, however, always provide. In my roamings, I have found what is now my favorite getCookie one-liner:

('; ' + document.cookie)
.split('; ' + key + '=')
.pop()
.split(';')
.shift()

Okay, that’s not exactly an one-liner, but only so that we can understand this beauty step by step.

Let’s assume we have the following cookie: “first=1; doit=2; cookies=3”

Line 1

(‘; ‘ + document.cookie)

Cookies are separated by semicolons. As we might be searching for the first key, it's useful to prefix the entire thing with a semicolon.

Our cookie now looks like this: “; first=1; doit=2; cookies=3”

Line 2

.split(‘; ‘ + key + ‘=’)

From MDN:

The split() method splits a String object into an array of strings by separating the string into substrings. When found, separator is removed from the string and the substrings are returned in an array.

Here, we split the string in two parts, creating an array.
The first part contains everything before our key. We can ignore that.
The second part contains everything after our key. Including the value.

Using the key "doit", this is what we would get: [“; first=1”, “2; cookies=3”]

Line 3

.pop()

From MDN:

The pop method removes the last element from an array and returns that value to the caller

As I promised, we can ignore the first value in that array. Therefore, pop gives us the interesting part: “2; cookies=3”

Line 4

.split(‘;’)

It’s pretty easy from now on, huh? We’re getting an array whose first index will contain our desired value. The result: [“2”, “ cookies=3”]

Line 5

.shift()

From MDN:

The shift() method removes the first element from an array and returns that element. This method changes the length of the array.

For the grand finale, we extract the first value of the array.

Voilà: “2”

That’s it.

Cya!

('; '+document.cookie).split('; '+key+'=').pop().split(';').shift()

Quick Tip: one liner cookie read was originally published in First, do it on Medium, where people are continuing the conversation by highlighting and responding to this story.

What does "first do it" mean? Where does it come from? Why do you feel it is important? Can’t you act like a grown up and go by your own name?

(I wish! If you knew how many Guilherme Rodrigues there are, you’d understand.)

Turns out there is a pretty good reason: I love this sentence because it helps me focus on the right things, everyday.

The origin

So, am I just trying to rip off billions of dollars of some giant sports company marketing budget? Well, no. I’m ripping off someone else!

I came across this expression on an excellent talk about Automating Front-end Workflow from the front-end overlord Addy Osmani.

Specifically, this slide struck a cord with me:

Iterative improvement

My whole life, being iterative was one of the hardest things for me. I would spend inordinate amounts of time trying to get something perfect, getting frustrated over it, and finally quitting. Rinse and repeat.

Turns out there’s a pretty neat solution to that: knowing that you won’t get it right the first time around anyway. I was already coming to terms with this philosophy, but this slide condensed it in a (three) perfect sentence(s).

Get started right now

The sentence is genius because the fear of starting is what actually keeps us from doing so many great things. We often get paralysed, over-analysing every possibility, getting prepared.

You know what? It’s mostly useless. As soon as you get started, you’ll realize how little you could know about it by preparing in the first place.

There's no replacement for getting started right now!

In sight, in mind

I liked it so much I decided to have it in front of me every day. I wanted a constant reminder to myself that said: Hey, don’t worry about perfection. First do it.

Well, what better place to put something you want to see every time than in your username?

And, thus, I became… firstdoit.

Except in god-damned Twitter. Jesus, Brian. Why won't you let go of that handle?

Why "First Do It"? Because you should get started right now. was originally published in First, do it on Medium, where people are continuing the conversation by highlighting and responding to this story.

There are some inflection points when learning JavaScript — moments when you learn something that doesn’t merely add to your productivity, but increase it exponentially.

Learning Underscore was, for me, one of those moments. It was my first contact with functional programming concepts and this, by itself, is a Big Deal®.

Underscore is a collection of utility functions that free you from a world of pain with nested for’s and if’s by allowing you to organise your algorithms neatly into data and transformations you need to apply to the data.

If you never touched Underscore or functional programming, fear not! Let me guide you in your first steps in this long and rewarding road. I promise you won't be disappointed.

Your new best friends — each, map and reduce

The most important and commonly used of those functions are:

• each,
• map, and
• reduce.

Actually, they are so powerful that most other operations can be expressed in terms of these. Let’s get to know them first, because they are the building blocks to thinking in functional terms.

Each, the boring brother

each is the equivalent of a simple for. It receives an array, iterates over its values and applies a given function on them.

In plain JS, you would write:

Now, some things are unpleasent here. First, you need to deal with the iterating on your own, minding i and value, which are only the means to an end. Second, your transformation is entrenched in the loop. It should be reusable! Let’s fix that first:

Ok, that got a little better. But with each, things get even simpler:

Looking good! But there’s a caveat…

Side effects are evil

In our first, simple example we altered the same array we were given. That may seem harmless, but one of the virtues of functional programming you will learn to love is the immutability of values.

This ugly name simply means that values should not be changed, but rather used to generate other values. You learned this in math: a function maps one value to another. It never alters the original.

f(x) -> x * 2
a = 2
f(a) // results 4; a is still 2, of course.

Back to our example

So, a better implementation of our simple example, removing side effects, would be:

An aside — why purity matters

A function that doesn’t has side effects is called a pure function. They are important for a number of reasons, but most importantly: because they don’t change any state, they are very predictable. This makes it easier to reason about your code.

It also means that pure functions are very testable! Given the same arguments, they will always return the same output. For greater detail, read on about functional programming.

Map those values

So, now we know we shouldn’t mutate those objects, it’s probably a good time for you to get to know map. It receives an array, iterates over its contents applying a transformation and returns a new array with the transformed values.

Let’s make that last, clunky example better!

Wow. Can you feel it already?

Reduce it all

Sometimes, you are not interested in the individuals, but in an aggregate value. This is precisely what reduce is for. It reduces all values in a collection down to a single value.

It receives an array, a function and an initial value. The iteratee function is a little more complex — it receives first the partial result so far, and then the current value. That’s better understood with an example.

For each player in the array, reduce will call totalPoints. The first time around, it will use the initial value as the first parameter. The consecutive calls will use the result from the preceding call.

So, there you have it. You can use reduce whenever you want to collect information on all the values from a collection and create something else out of it.

Conclusion

This has been a very brief introduction to some of the basic tools in the Underscore toolset. However, there is much more to be learned, and those functions alone have far more interesting applications.

I hope you enjoyed it and hang around for the next part, where we will discuss chaining, using objects instead of arrays and some more advanced functions.

You can always get started right away with the great documentation, and also get to know lodash, Underscore’s leanest, meanest younger brother.

UPDATE Some people have pointed that I should mention that modern browsers offer native implementations of forEach, map and reduce as methods of Array. Just be careful using them if you plan on supporting older browsers, as you’ll need to polyfill them!

Originally published at firstdoit.com on September 22, 2014.

Reduce your problems with functional programming — getting started with Underscore or Lodash was originally published in First, do it on Medium, where people are continuing the conversation by highlighting and responding to this story.

npm is the awesome package manager bundled with the Node.js environment. It is a very simple tool to get started with: you usually just "npm install stuff" and it ends up in "./node_modules/stuff".

You can also globally install some packages by using the global -g flag. mocha is an excellent test runner that is usually installed like that:

$ npm install -g mocha
$ mocha -V 
2.2.5

But this leads us to a big problem: what if two different projects depend on different versions of a test runner? How do you manage that? Well, you don’t!

Decide what’s actually a dependency

You only want to install globally tools which your projects don’t depend on. These are often handy CLI’s like mkdirp or node-inspector.

Other packages (like test-runners) should be considered dependencies, so you would install them using the flags "save" or "save-dev". This way, they get saved to your package.json dependencies section (Read up on the differences between dependencies and devDependencies).

When you install a package like mocha locally, you’ll notice something interesting:

$ npm install --save-dev mocha
$ ls -lah node_modules/.bin
mocha -> ../mocha/bin/mocha

Apparently, npm created a folder called "node_modules/.bin/" which contains a mocha symlink to "node_modules/mocha/bin/mocha".

So, maybe we could use that directly?

$ ./node_modules/.bin/mocha -V
2.2.5

Great! Now we know we can install tools locally and avoid version conflicts between projects!

But do we need to add that long, boring "./node_modules/.bin/" prefix to every command we need? No way! ;)

Use npm scripts to run your tools

If you don’t know what npm scripts are, you should definitely take a look at the npm scripts documentation.

Simply put, it’s a way to document commands which are relevant to your project. You use it by defining a scripts section in the package.json file.

"scripts": { "hello": "echo Hello, scripts!" }

Then, you can run it by using the "npm run" command:

$ npm run hello
Hello, scripts!

Not all script names are born equal, however, and some don’t need the run to work. The most commonly used are start and test.

"scripts": { 
  "start": "echo Hello, start!",
  "test": "echo Hello, test!"
}

And we can see it working:

$ npm start
Hello, start!

Defining start and test scripts is a common convention in Node.js. For example, Heroku and AWS BeanStalk will run npm start in order to run your node project by default. Travis CI will automatically run npm test when you upload your project.

npm scripts understand .bin

Presumably, then, we can now create a script to run our local mocha installation, right?

"scripts": {
  "test": "./node_modules/.bin/mocha -V"
}

Voilà — it works.

But npm has another trick up its sleeve. When evaluating scripts, npm adds node_modules/.bin/ to the PATH environment variable. That means you can forego the folder prefix entirely!

Our final script would look like this:

"scripts": {
  "test": "mocha -V"
}

Let’s test it:

$ npm test
2.2.5

Perfect!

So, remember:

• Prefer installing test runners and other project-specific tools as dependencies.
• Use "npm install --save-dev stuff" to save stuff to your package.json.
• Use npm scripts to run these tools as if they were installed globally!

Originally published at firstdoit.com on May 26, 2015.

No need for globals — using npm dependencies in npm scripts. was originally published in First, do it on Medium, where people are continuing the conversation by highlighting and responding to this story.

Where are my templates? What’s that crazy HTML doing in my JavaScript? JSX looks weird! Hurry! Kill it with fire!

That was because I didn’t get it.

But I swear: React is definitely on the right track… Please, hear me out.

Good old MVC

The Root of All Evil in an interactive application is managing state. The “traditional” approach is the MVC architecture, or some variation thereof.

MVC proposes that your Model is the single source of truth — all state lives there. Views are derived from the Model, and must be kept in sync. When the Model changes, so does the View.

Finally, user interactions are captured by the Controller, which updates the Model. So far, so good.

Render the view when the model changes

This looks quite simple. First, we need to describe our View — how it transforms the model state into DOM. Then, whenever the user acts we update the Model and re-render the entire thing… right? Not so fast. Unfortunately, this is not very straight forward for 2 reasons:

1. The DOM actually has some state, like the content of a text input. If you re-render disregarding your DOM completely, this content will be lost.
2. DOM operations (like removing and inserting nodes) are really slow. Constantly rendering everything will lead to terrible performance.

So how do we keep the Model and View in sync avoiding these problems?

Data binding

For the past 4 years, the most common framework feature introduced to solve this problem was data binding.

Data binding is the ability to keep your model and view in sync automatically. Usually, in JavaScript, that means your Objects and your DOM.

It achieves that by letting you declare the dependencies between the pieces of data in your app. Changes in the state are propagated throughout your application and all depending pieces are automagically updated.

Let’s see how that works in practice with some famous frameworks.

Knockout

Knockout argues for the MVVM (Model-View-ViewModel) approach and helps you implement the “View” parts:

And, voilà. Changing the value of either input will provoke a change in the span. You never wrote code to wire it up. How cool is that, huh?

But wait, what about the Model being the single source of truth? Where should this ViewModel get its state from? How does it know that the Model changed? Interesting questions.

Angular 1

Angular 1 describes data binding in terms of keeping the Model and View in sync. From the docs:

But… should the View communicate with the Model directly? Are they that tightly coupled?

Anyway, let’s look at the obligatory hello world example:

From this example, it looks like the Controller has state and is behaving like a Model — or perhaps a ViewModel? Assuming the Model is elsewhere, how is it kept in sync with the Controller?

My head is starting to hurt a little.

The problems with data binding

Data binding works wonderfully for small examples. However, as your app grows you’ll probably face some of these problems.

Declaring dependencies can quickly introduce loops

The most common problem is having to cope with the side effects of changes in your state. This image from the introduction of Flux explains quite clearly how dependency hell starts to creep in:

In this scenario, can you predict what changes will happen when one change happens to a single Model? It is very hard to reason about code that can be executed in a completely arbitrary order when any dependency changes.

Template and display logic are artificially separated

What’s the role of a View? To present the data to the user. What’s the role of a ViewModel? To present the data to the user. What’s the difference? None!

Templates separate technologies, not concerns ~ Pete Hunt

In the end, a View component should be able to manipulate its data and present it in the desired format. However, all template languages are inherently crippled: they can never achieve the same expressiveness and power as code.

Quite simply, {{# each}}, ng-repeat and databind=”foreach” are all poor replacements for something that is native and trivial in JavaScript: a for loop. And they can’t go any step further, so no filter or map for you.

Data binding is a hack around re-rendering

The Holy Grail of simplicity is not in discussion. What everyone always wanted was to re-render our entire app when state changes. This way, we could stop having to deal with Root of All Evil problem: state changing over time — we could simply describe what our app looks like given any particular state.

So, the problem is clear. Man, I wish some giant company could spare a team of genius developers to really nail the solution to this problem…

Enter Facebook’s React

Turns out they did. React implements a virtual DOM which kind of delivers us the Holy Grail.

What is virtual DOM anyway?

I’m glad you asked! Let’s look at a trivial React example.

That’s all of the required API for a React component. You must have a render method. Complex, huh?

OK, but what about that <div>? That’s not JavaScript! It sure isn’t.

Your new friend, JSX

This code is actually written in JSX, a super-set of Javascript which includes that brackets syntax for defining components. The code above, when compiled into JavaScript, will actually become:

Did you notice the calls to createElement? These objects compose the virtual DOM implementation.

Quite simply: React first assembles the entire structure of your app in-memory, using those objects. Then, it converts that structure into actual DOM nodes and inserts them in your browser’s DOM.

OK, but what’s the point of writing our HTML with those strange createElement functions?

Virtual DOM is FAST

As we already discussed, manipulating the DOM is ridiculously expensive, so it must be done as few times as possible.

React’s virtual DOM, however, makes it really fast to compare two trees and find exactly what changed between them. That way, React is able to compute the minimum set of changes necessary to update the DOM.

Practically speaking, React can diff two DOM trees and discover the minimum set of operations it needs to perform. This means two things:

1. If an input with text is re-rendered and React expects it to have that content, it won’t touch the input. No more state loss!
2. Diffing the virtual DOM is not expensive at all, so we can diff it as much as we like. When it’s ready to actually alter the DOM, it will only perform the least possible number of operations. No more slow layout thrashing!

Remember the two problems with re-rendering our entire app when state changes?

Gone.

React maps state to DOM

Virtual DOM rendering and diffing is the only magical part about React. Its excellent performance, however, is what fundamentally enables us to have a much simpler architecture overall. How simple?

React components are idempotent functions. They describe your UI at any point in time, just like a server-rendered app.

— Pete Hunt, React: Rethinking best practices

Idempotent-function-simple.

That’s all a React component should be, really. It maps the current app state to DOM. And you have the full power of JavaScript to describe your UI — loops, functions, scope, composition, modules — not a crippled template language.

Start using React today

React can be a little daunting at first. It proposes a really large paradigm shift, which is always uncomfortable. However, the advantages become clear when you start using it.

The React documentation is excellent. You should give it a try and follow the tutorial. I’m sure you’ll love it if you give it a chance.

Happy coding!

Originally published at firstdoit.com on May 15, 2015.

How I learned to stop worrying and love React was originally published in First, do it on Medium, where people are continuing the conversation by highlighting and responding to this story.