JS (and) Crafting #4 – Sketch, ESLint, Classes, Howler.js

Wolfram Kriesing - March 20, 2017 - tagged with: #newsletter #lint #eslint #React Native #refactoring #code quality #github #audio #playground #classes

This is JS (and) Crafting #4 - March 20th, 2017. Every Monday you will receive a hand-selected collection of links about JavaScript and how to craft better software. Let's get started ...

JavaScript

Sketch — A Playground for React Native This is a pretty cool tool. Especially if you have never touched react-native, this is a perfect tool for just trying it out. You can write code or drag 'n drop code and right away see the result on your device.

ESLint v3.18.0 released If you care about your code eslint is a tool you surely want to use. This version "adds support for AST selectors" which allows for simplifying the implementation of custom rules.

How to Use Classes and Sleep at Night is an interesting look at JS classes by Dan Abramov. The introduction of "real" classes in ES6 started lots of discussion. Dan suggest his view, which rings with many people in the JS community.

Howler.js is a library I found through Thorsten's tweet, which "makes working with audio in JavaScript easy and reliable across all platforms".

Crafting

Michael Feathers talked about delta flora, a tool he once wrote to get more insight into your source code and it's history. CodeScene looks a very promising tool which does exactly that. It might make sense to keep an eye on it.

STON - Smalltalk Object Notation reads to me as if this is a notation for typed JSON. JSON is one of the most common exchange formats, but it also lacks a lot of explicitness due to it's exclusively simple typing. Maybe STON could be an option for a more strict(er) typed exchange format.

Github has saved replies, I didn't know. If you are intensively using github issues and pull requests, there is a nice feature you might find helpful: "saved replies". It's like canned responses in gmail. It can help with "saving you a ton of time typing".

Avoid pull requests because they are "a bad smell of team dynamics" and I strongly agree with the author that "pairing is much better than reviewing". And I agree also that "pull requests are great, especially when your team is not colocated". But they are not all bad, especially in open source PRs are great, where people don't sit beside one another.