DEV Community: Promise Tochi

One package.json to rule them all

Promise Tochi — Mon, 18 Mar 2019 10:05:28 +0000

I am going to start this article with a disclaimer: the title is a clickbait, or maybe not - depends on how you look at it.

Haven gotten that out of the way, let's get to the meat of the matter: creating a useful default package.json.

What you need to know (WYNTK)

If you have gone through the official npm docs, you might know that you can create a default package.json configuration; thereby skipping the CLI questionnaire that follows whenever you run the npm init command.
In fact, you can skip the CLI questionnaire by: opening a terminal somewhere on your PC right now; running npm init -y; if you do not have a .npm-init.js file in your home directory, npm will create a package.json in the folder your terminal is pointing to, the created package.json file will contain this default content:

{
  "name": "",
  "version": ""
}

These are the only required properties for a npm package. However, the thoughtful guys at npm allow us, devs, to change the default configuration or CLI questionnaire. Here's how.

As you might have guessed, to create a default package.json configuration, you need to create a .npm-init.js file in the home directory of your PC.

Creating the `.npm-init.js` file

Open a terminal(preferably git-bash on windows)anywhere on your PC , and run cd ~ this will point the terminal to your home directory.
Next, run echo "const path = require('path')" >.npm-init.js. This will create a .npm-init.js file in the home directory.
In the same terminal window, type start ".npm-init.js" and hit enter. This will open the npm-init file in your default application for opening Javascript files.

Note that some of these commands might not work on versions of Windows prior to Windows 10

Configuring `.npm-init.js`

To configure npm's default package.json configuration, we need to expose an object to module.exports from the .npm-init.js file in your home directory. Presently, here's what our npm-init file contains:

const path = require('path')

Edit it, so that it looks like so:

const path = require('path')

module.exports = {
}

Add a default `author` property

The email and website details are optional in the author property.

const path = require('path')

module.exports = {
  'author': 'Promise Tochi <your email@domain.com> (https://your-website.com)',
}

Add a default `version` property

const path = require('path')

module.exports = {
  'author': 'Promise Tochi <your email@domain.com> (https://your-website.com)',
  'version': '0.0.1'
}

Add a default `description` property

const path = require('path')

module.exports = {
  'author': 'Promise Tochi <your email@domain.com> (https://your-website.com)',
  'version': '0.0.1',
  'description': 'My awesome new project'
}

Add a default `license` property

const path = require('path')

module.exports = {
  'author': 'Promise Tochi <your email@domain.com> (https://your-website.com)',
  'version': '0.0.1',
  'description': 'My awesome new project',
  'license': 'MIT'
}

Add a default `name` property

const path = require('path')

module.exports = {
  'name': 'my_new_project',
  'author': 'Promise Tochi <your email@domain.com> (https://your-website.com)',
  'version': '0.0.1',
  'description': 'My awesome new project',
  'license': 'MIT'
}

You might be thinking why we have to go through all these trouble and end up with a static default name; "why are you wasting my time man?!"

The good thing is we can improve on this by using the name of the folder where you are running npm init from. We can change the contents of the npm-init file to:

const path = require('path')

module.exports = {
  'name': path.basename(process.cwd()),
  'author': 'Promise Tochi <your email@domain.com> (https://your-website.com)',
  'version': '0.0.1',
  'description': 'My awesome new project',
  'license': 'MIT'
}

If you are wondering:

process.cwd() method returns the path to the current working directory of the Node.js process

path.basename() methods returns the last portion of a path

We can improve this a little because npm requires that package names be URL friendly, that is, they shouldn't contain spaces or any special charaters. So let's change our .npm-init.js to:

const path = require('path')
const projectName = slugify(path.basename(process.cwd()))

module.exports = {
  'name': projectName,
  'author': 'Promise Tochi <your email@domain.com> (https://your-website.com)',
  'version': '0.0.1',
  'description': 'My awesome new project',
  'license': 'MIT'
}

function slugify(text) {
  return text.toString().toLowerCase()
    .replace(/\s+/g, '-')           // Replace spaces with -
    .replace(/[^\w\-]+/g, '')       // Remove all non-word chars
    .replace(/\-\-+/g, '-')         // Replace multiple - with single -
    .replace(/^-+/, '')             // Trim - from start of text
    .replace(/-+$/, '')             // Trim - from end of text
}

Adding in some more properties

Next we'll add in default repository, bugs and homepage properties.

Here, I'm assuming that you use git and github for version control. If you are, you can guarantee that your project repository will be at https://github.com/{user or organization name}/{project name}. This leads us to:

const path = require('path')
const projectName = slugify(path.basename(process.cwd()))
const projectUrl = `https://github.com/{your github user name}/${projectName}`

module.exports = {
  'name': projectName,
  'author': 'Promise Tochi <your email@domain.com> (https://your-website.com)',
  'version': '0.0.1',
  'description': 'My awesome new project',
  'license': 'MIT',
  'repository': {
    'type': 'git',
    'url': projectUrl
  },
  'bugs': {
    'url': `${projectUrl}/issues`
  },
  'homepage': projectUrl,
}

function slugify(text) {
  return text.toString().toLowerCase()
    .replace(/\s+/g, '-')           // Replace spaces with -
    .replace(/[^\w\-]+/g, '')       // Remove all non-word chars
    .replace(/\-\-+/g, '-')         // Replace multiple - with single -
    .replace(/^-+/, '')             // Trim - from start of text
    .replace(/-+$/, '')             // Trim - from end of text
}

Trying out our default package.json configuration

Create a new folder on your PC and point your terminal at the folder. In the terminal, run npm init, you should get a CLI prompt similar to this:

To use the default configuration, type yes in the terminal and hit the Enter key.

Hopefully, that should save you a few minutes when creating a new npm package in the future, if not I hope you learnt something new. Thanks for reading all the way, happy coding.

This is my first article in 2019 and I hope to write a lot more.

Cover Photo by William Krause on Unsplash
William Krause

What you need to know about Javascript's Implicit Coercion

Promise Tochi — Wed, 25 Oct 2017 10:36:58 +0000

Javascript's implicit coercion simply refers to Javascript attempting to coerce an unexpected value type to the expected type. So you can pass a string where it expects a number, an object where it expects a string etc, and it will try to convert it to the right type. This is a Javascript feature that is best avoided.

3 * "3" //9
1 + "2" + 1 //121

true + true //2
10 - true //9


const foo = {
  valueOf: () => 2
}
3 + foo // 5
4 * foo // 8

const bar = {
  toString: () => " promise is a boy :)"
}
1 + bar // "1 promise is a boy :)"


4 * [] // 0
4 * [2] // 8
4 + [2] // "42"
4 + [1, 2] // "41,2"
4 * [1, 2] // NaN

"string" ? 4 : 1 // 4
undefined ? 4 : 1 // 1

Non-numeric values in numeric expressions

Strings

Whenever you pass a string as an operand in a numeric expression involving either of these operators: -, *, /, %, the number's conversion process is similar to calling the in-built Number function on the value. This is pretty straightforward, any string containing only numeric characters will be converted to it's number equivalent, but a string containing a non-numeric character returns NaN. Illustrated below,

3 * "3" // 3 * 3
3 * Number("3") // 3 * 3
Number("5") // 5

Number("1.") // 1
Number("1.34") // 1.34
Number("0") // 0
Number("012") // 12

Number("1,") // NaN
Number("1+1") // NaN
Number("1a") // NaN
Number("one") // NaN
Number("text") // NaN

The case for the + operator

The + operator unlike other mathematical operators, performs two functions:

Mathematical addition
String concatenation

When a string is an operand of the + operator, Javascript instead of converting the string to a Number, converts the number to a string.


// concatenation
1 + "2" // "12"
1 + "js" // "1js"

// addition
1 + 2 // 3
1 + 2 + 1 // 4

//addition, then concatenation
1 + 2 + "1" // "31"
(1 + 2) + "1" // "31"

//concatenation all through
1 + "2" + 1 // "121"
(1 + "2") + 1 // "121"

Objects

Most Javascript Object conversions usually result in [object Object], For example

"name" + {} // "name[object Object]

Every javascript Object inherits a toString method, that is called whenever an Object is to be converted to a string. The return value of the toString method is used for such operations as string concatenation and mathematical expressions.

const foo = {}
foo.toString() // [object Object]

const baz = {
  toString: () => "I'm object baz"
}

baz + "!" // "I'm object baz!"

When it's a mathematical expression, Javascript will attempt to convert the return value to a number, if it's not.

const foo = {
  toString: () => 4
}

2 * foo // 8
2 / foo // 0.5
2 + foo // 6
"four" + foo // "four4"

const baz = {
  toString: () => "four"
}

2 * baz // NaN
2 + baz // 2four

const bar = {
  toString: () => "2"
}

2 + bar // "22"
2 * bar // 4

Array objects

The inherited toString method of Arrays work abit differently, it works in a way similar to calling the join method of an array without any arguments.

[1,2,3].toString() // "1,2,3"
[1,2,3].join() // "1,2,3"
[].toString() // ""
[].join() // ""

"me" + [1,2,3] // "me1,2,3"
4 + [1,2,3] // "41,2,3"
4 * [1,2,3] // NaN

So when you pass an array where it expects a string, Javascript concatenates the return value of the toString method with the second operand. If it expects a number, it attempts to convert the return value to a number.

4 * [] // 0
4 / [2] // 2

//similar to
4 * Number([].toString())
4 * Number("")
4 * 0

//

4 / Number([2].toString())
4 / Number("2")
4 / 2

True, False and ""

Number(true) // 1
Number(false) // 0
Number("") // 0

4 + true // 5
3 * false // 0
3 * "" // 0
3 + "" // "3"

The `valueOf` method

It is also possible to define a valueOf method that will be used by Javascript whenever you pass an Object where it expects a string or numeric value.


const foo = {
  valueOf: () => 3
}

3 + foo // 6
3 * foo // 9

When both the toString and valueOf methods are defined on an Object, Javascript uses the valueOf method instead.

const bar = {
  toString: () => 2,
  valueOf: () => 5
}

"sa" + bar // "sa5"
3 * bar // 15
2 + bar // 7

The valueOf method is intended for Objects that are supposed to represent a numeric value.

const two = new Number(2)

two.valueOf() // 2

Falsy and Truthy

~~I really wanted to make that falsy and trusy~~

Every Javascript value can be coerced into either true or false. Coercion into boolean true means the value is truthy. Coercion into boolean false means the value is falsy.

There are a handful of values in Javascript that return falsy values, they are:

false
0
null
undefined
""
NaN
-0

Everything else is truthy,

if (-1) // truthy
if ("0") // truthy
if ({}) // truthy

The above snippets are okay, but it is better practice to be explicit when trying to determine truthiness of a value. Basically, don't rely on Javascript's implicit coercion, even if you feel you know them perfectly.
Instead of the code snippet below,

const counter = 2

if (counter)

Any of the below is better practice depending on your requirements

if (counter === 2)

//or

if (typeof counter === "number")

This is because for example, you define a function that is supposed to work with numbers


const add = (number) => {
  if (!number) new Error("Only accepts arguments of type: number")
  //your code
}

So if I call the add function with 0, I will always get an unintended error

add(0) // Error: Only accepts arguments of type: number

//better check

const add = (number) => {
  if (typeof number !== "number") new Error("Only accepts arguments of type: number")
  //your code
}

add(0) // no error

NaN

NaN is a special numeric value that is not equal to itself.

NaN === NaN // false

const notANumber = 3 * "a" // NaN

notANumber == notANumber // false
notANumber === notANumber // false

NaN is the only Javascript value that is not equal to itself. So you can check for NaN by comparing it to itself.

if (notANumber !== notANumber) // true

ECMAScript 6 introduced a method for checking NaN, Number.isNaN

Number.isNaN(NaN) // true
Number.isNaN("name") // false

Beware of the global isNaN function, it attempts to coerce it's argument before checking if it's NaN. For example,

isNaN("name") // true
isNaN("1") // false

The global isNaN function should be avoided, the way it works is similar to the function below

const coerceThenCheckNaN = (val) => {
  const coercedVal = Number(val)
  return coercedVal !== coercedVal ? true : false
}

coerceThenCheckNaN("1a") // true
coerceThenCheckNaN("1") // false
coerceThenCheckNaN("as") // true
coerceThenCheckNaN(NaN) // true
coerceThenCheckNaN(10) // false

That's most of implicit coercion. If I missed something, please chime in, in the comments below, and thanks for reading all the way.

PostCSS - Introduction and Setup

Promise Tochi — Mon, 23 Oct 2017 23:45:55 +0000

In this article, I will quickly walk you through what PostCSS is and how to set it up.

So I mentioned PostCSS to a developer and he did not know what it was. It’s such a great tool, that I wonder how it’s managed to remain quite hushed since it‘s release over a year ago.

PostCSS allows you to write CSS much more conveniently. Plain and simple. It allows you write more convenient syntax, future CSS, LESS, SASS, etc. Yes, SASS. All those cool things you can do in your .scss files, you can do with a PostCSS setup. PostCSS itself doesn’t do anything per se, all of it’s features comes from it’s numerous plugins. These plugins are written by different developers from around the world.

To get setup, you need to have Node and npm installed.

Run node -v to check if you have Nodejs installed. If you don’t, head over to nodejs.org to download it, npm comes bundled with Nodejs.

Next step, create an empty folder on your PC (you can name it postcss_intro. Open a terminal and make sure it’s pointing at the folder you just created. Next, run npm init and follow the prompt, just keep hitting the enter key till you get the prompt below,

Is this ok? (yes)

Type y and hit enter. This will create a package.json file for you within that folder.

Next up, run

npm i -D gulp gulp-postcss

This will install the gulp and gulp-postcss modules and save them as a dev dependency within the folder you created.

Next up create a folder named src within the postcss_intro folder, or whatever name you might have given it. Create another folder named build also at the top level directory of postcss_intro.

You should now have a directory that looks like this,

Next up, create a Javascript file named gulpfile.js. This is where all our settings for running Gulp and PostCSS will go. 😃

Copy the code snippet below and paste it in the gulpfile.js

const gulp = require("gulp")
const postcss = require("gulp-postcss")

gulp.task("css", function() {
  const processors = [
    //postcss plugins will go here
  ]
  return gulp
    .src("./src/*.css")
    .pipe(postcss(processors))
    .pipe(gulp.dest("./build"))
})

What this does is use the gulp module to load all css files in the src/ directory, feeds the loaded file to PostCSS and it’s plugins, before finally saving it in the build/ directory.

Next up, open the package.json file. It should look like this

{
  "name": "postcss_intro",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "gulp": "^3.9.1",
    "gulp-postcss": "^7.0.0"
  }
}

Add the snippet below, add it above "test": "echo \"Err…

"postcss": "gulp css",

Your package.json file should now look like this

{
  "name": "postcss_intro",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "postcss": "gulp css",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "gulp": "^3.9.1",
    "gulp-postcss": "^7.0.0"
  }
}

Next up, create a master.css file in the src folder, open and add some CSS to it, you can add this,

html {
  transform: translate(0%);
}

Go to your terminal, pointing at the postcss_intro folder and run

npm run postcss

You should get an output that looks like this,

[19:58:56] Starting 'css'...
[19:58:56] Finished 'css' after 29 ms

Check your build directory and you should find a shiny new master.css created by gulp.

We have successfully gotten gulp to take our CSS file, feed it to PostCSS and save it in the build/ directory.

To actually process our CSS file, we will install and add some PostCSS plugins to our gulp build process. From your terminal, run

npm i -D autoprefixer

When that’s done, open the gulpfile.js file again and edit it to look like this

const gulp = require("gulp")
const postcss = require("gulp-postcss")
const autoprefixer = require('autoprefixer') //new line

gulp.task("css", function() {
  const processors = [
    autoprefixer //new line
  ]
  return gulp
    .src("./src/*.css")
    .pipe(postcss(processors))
    .pipe(gulp.dest("./build"))
})

We have added autoprefixer as a plugin, that will work on the CSS , when it’s fed to PostCSS.

Next run, npm run postcss again, you should get the same output as before, only now, when you check the generated master.css file in build, you would see property rules with prefixes, automatically added.

html {
  -webkit-transform: translate(0%);
          transform: translate(0%);
}

That’s it. That’s the setup.

Let’s add another plugin, the responsive-type plugin. You can install it by running

npm i -D postcss-responsive-type

Just as we did for autoprefixer, we need to add the responsive-type plugin to our gulpfile.js. Once more, open the gulpfile.js and edit it to look like this,

const gulp = require("gulp")
const postcss = require("gulp-postcss")
const autoprefixer = require("autoprefixer")
const responsiveType = require("postcss-responsive-type") //new line

gulp.task("css", function() {
  const processors = [autoprefixer, responsiveType] //new line
  return gulp
    .src("./src/*.css")
    .pipe(postcss(processors))
    .pipe(gulp.dest("./build"))
})

Responsive type allows you to write fluid size values that I wrote about in my completely responsive CSS sizes article. So instead of manually writing

html {
  font-size: 14px + 10 * ((100vw - 769px) / 2048px);
}

You can write,

html {
  font-size: responsive;
  min-font-size: 14px;
  max-font-size: 24px;
  lower-font-range: 769px;
  upper-font-range: 2048px;
}

which is much more readable. So go to your master.css in the src/ directory, and edit it to look like this,

html {
  transform: translate(0%);
  font-size: responsive;
  min-font-size: 14px;
  max-font-size: 24px;
  lower-font-range: 769px;
  upper-font-range: 2048px;
}

Run npm run postcss again and you should have a build/master.css file that looks like this,

html {
  -webkit-transform: translate(0%);
          transform: translate(0%);
  font-size: calc(14px + 10 * ((100vw - 769px) / 1279));
}
@media screen and (min-width: 2048px) {
  html {
    font-size: 24px;
  }
}
@media screen and (max-width: 769px) {
  html {
    font-size: 14px;
  }
}

Isn’t that just awesome.

Running npm run postcss everytime we make a change is boring, we are too lazy for that sort of thing. So we will set a gulp task runner, to watch and automatically transform and build our CSS files, anytime we save them.

Fire up your gulpfile.js file for the last time and add this snippet at the bottom,

gulp.task("watch", function() {
  gulp.watch("./src/*", ["css"])
})

Your gulpfile should now look like this,

const gulp = require("gulp")
const postcss = require("gulp-postcss")
const autoprefixer = require("autoprefixer")
const responsiveType = require("postcss-responsive-type")

gulp.task("css", function() {
  const processors = [autoprefixer, responsiveType]
  return gulp
    .src("./src/*.css")
    .pipe(postcss(processors))
    .pipe(gulp.dest("./build"))
})

gulp.task("watch", function() {
  gulp.watch("./src/*", ["css"])
})

Next add the snippet of code below to your package.json file, below the "postcss": "gulp css" line

"postcss-watch": "gulp watch",

You should now have a package.json file that looks like this,

{
  "name": "postcss_intro",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "postcss": "gulp css",
    "postcss-watch": "gulp watch",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "autoprefixer": "^7.1.5",
    "gulp": "^3.9.1",
    "gulp-postcss": "^7.0.0",
    "postcss-responsive-type": "^1.0.0"
  }
}

With this, you can now run

npm run postcss-watch

in your terminal once, and gulp would be watching your src/master.css file and automatically transforming it, whenever you make a change and save it. Make sure your terminal is showing something like this,

Now, make a change to the src/master.css file. Say, change the min-font-size to 16px, your terminal will output something like

Open your build/master.css and you should see the your changes reflecting. Anytime you want to stop the process, go to the terminal where the gulp task is running and hit CTRL+C, type yes and hit enter.

PostCSS has several more plugins, much more powerful, with very useful functionalities. You can view them at https://postcss.parts.

My specific build process, which hasn’t changed much in over a year that I’ve been using PostCSS includes plugins such as,

*postcss-inline-media
*css-mqpacker
*postcss-simple-vars
*postcss-media-variables
*postcss-responsive-type
*autoprefixer
*rucksack

My favourite is the combination of postcss-media-variables and postcss-inline-media, makes CSS like this possible

.sidebar {
  width: @ml 30%;
}

That rule now will only be applied to larger screens, as I have defined this somewhere else,

$ml: (min-width: 769px);

If you haven’t used PostCSS previously, I hope you explore its numerous plugins and give it a trial. There are numerous plugins that bring SASS functionality to PostCSS, https://www.postcss.parts/tag/sass . Companies like Twitter, Alibaba, use PostCSS, you should give it a shot if you haven’t.

This article was originally published by me on medium on the 17th of October.

Better ReactJS patterns: this.setState pitfalls

Promise Tochi — Mon, 23 Oct 2017 21:26:44 +0000

There's a potential problem with passing object literals to setState like below,

this.setState({someKey: someValue})

The code snippet below illustrates the potential problem. We called setState three times in quick succession, and added a callback to log the updated state to the console after each call.


state = {
  counter: 0
}

incrementCounter = () => {
  this.setState(
    {
      counter: this.state.counter + 1
    },
    () => console.log()
  )
}

componentDidMount = () => {
  incrementCounter()
  incrementCounter()
  incrementCounter()
}

//output

{counter: 1}
{counter: 1}
{counter: 1}

You might have expected the output to be:

{counter: 1}
{counter: 2}
{counter: 3}

There are two reasons for the unintended output:

Asynchronous updates
Batched updates

Reacts asynchronous update can best be described with the code snippet below:

state = {
  counter: 0
}

incrementCounter = () => {

  this.setState(
    {
      counter: this.state.counter + 1
    }
  )

  console.log(this.state.counter) //this will always return the state before the new state above is reflected in state
}

incrementCounter() // 0
incrementCounter() // 1

Instead of logging 1, the initial call to incrementCounter logs 0, second call logs 1 instead of 2, and it continues like that.

Batched updates is described in the official docs with the code sample below,

Object.assign(
  previousState,
  {quantity: state.quantity + 1},
  {quantity: state.quantity + 1},
  ...
)

So our initial code snippet is actually transformed into something like this,

Object.assign(
  previousState,
  {counter: state.counter + 1},
  {counter: state.counter + 1},
  {counter: state.counter + 1})

So how do you avoid these potential issues, by passing a function to setState rather than an Object.

incrementCounter = () => {
  this.setState((presentState) => (
    Object.assign({}, presentState, {
      counter: presentState.counter + 1
    })
  ))
}

componentDidMount = () => {
  incrementCounter()
  incrementCounter()
  incrementCounter()
}

//output

{counter: 3}
{counter: 3}
{counter: 3}

This way, the setState method will always pass an up-to-date state to the function. Notice that we use Object.assign to create a new object from the presentState.

Note that you shouldn't do this,

this.setState((presentState) => {
  presentState.counter+= 1
  return presentState
})

Though the above will cause an update to state and re-render, the snippet below won't, due to React's shallow comparison.

state = {
  someProp: {
    counter: 0
  }
}
this.setState((presentState) => {
  presentState.someProp.current += 1
  return presentState
})

It's still safe to pass setState an object literal when the new state doesn't depend on the old state, but passing it functions instead is a better pattern. If you are familiar with Redux, it's similar to Redux's reducers.

You might have noticed my use of arrow functions with incrementCounter method. It's the proposed es7 property initializer syntax, you can use it now with the babel transform-class-properties plugin.

Cheers.

All you need to know about Javascript's Expressions, Statements and Expression Statements

Promise Tochi — Sat, 21 Oct 2017 11:50:27 +0000

By the end of this article, you should be able to describe in detail how the code in the image below works and why it works.

There are two major syntactic categories in Javascript:

Statements
Expressions

It is important to make this distinction because expressions can act like statements, which is why we also have Expression statements. Though, on other the hand, statements cannot act like expressions.

EXPRESSIONS

Expressions produceÂ value

Expressions are Javascript code snippets that result in a single value. Expressions can be as long as you want them to be, but they would always result in a single value.

2 + 2 * 3 / 2

(Math.random() * (100 - 20)) + 20

functionCall()

window.history ? useHistory() : noHistoryFallback()

1+1, 2+2, 3+3

declaredVariable

true && functionCall()

true && declaredVariable

All of the above are expressions, and can appear anywhere Javascript expects a value. So that the argument to console.log below, resolves to a single value, that is logged to the console.

console.log(true && 2 * 9) // 18

Expressions don’t necessarily changeÂ state

For example,

const assignedVariable = 2; //this is a statement, assignedVariable is state

assignedVariable + 4 // expression

assignedVariable * 10 // expression

assignedVariable - 10 // expression

console.log(assignedVariable) // 2

Despite all the expressions in the snippet above, assignedVariable’s value is still 2. So why the necessarily in the heading for this section, it’s because function calls are expressions but a function can contain statements that change state. So foo() in itself is an expression, that either returns undefined or some other value, but if foo was written as

const foo = foo () => {
  assignedVariable = 14
}

then, even though its call is an expression, its call has also resulted in a state change. So a better way to rewrite the foo function and statement would be:

const foo = foo () => {
  return 14 //explicit return for readability
}
assignedVariable = foo()

or even better

const foo = foo (n) => {
  return n//explicit return for readability
}
assignedVariable = foo(14)

This way your code is more readable, composable, and there is a clear distinction and separation between expression and statements. This a fundamental of functional and declarative Javascript.

STATEMENTS

Statements are the headache of functional programming ðŸ˜„. Basically, statements perform actions, they do things.

In javascript, statements can never be used where a value is expected. So they cannot be used as function arguments, right-hand side of assignments, operators operand, return values…

foo(if () {return 2}) //js engine mind = blown

These are all javascript statements:

if
if-else
while
do-while
for
switch
for-in
with (deprecated)
debugger
variable declaration

If you type the snippet below in your browser’s console and hit enter

if (true) {9+9}

you will see that it returns 18 but despite that you cannot use it as an expression or where Javascript expects a value. It is weird because you’d expect statements not to return anything, since the return value is pretty much useless if you cannot use it. That’s Javascript for you, weird.

Function declarations, Function expressions and Named Function expressions

A function declaration is a statement

function foo (func) {
  return func.name
}

A function expression is an expression, what you call an anonymous function

console.log(foo(function () {} )) // ""

A named function expression is an expression, like an anonymous function, but it has a name

console.log(foo(function myName () {} )) // "myName"

The distinction between function as an expression and function as a declaration boils down to understanding this:
whenever you declare a function where Javascript is expecting a value, it will attempt to treat it as a value, if it can’t use it as a value, an error will be thrown.
Whereas declaring a function at the global level of a script, module, or top level of a block statement (that is, where it is not expecting a value), will result in a function declaration.

Examples:

if () {
  function foo () {} // top level of block, declaration
}

function foo () {} //global level, declaration

function foo () {
  function bar() {} //top level of block, declaration
}

function foo () {
  return function bar () {} // named function expression
}

foo(function () {}) // anonymous function expression

function foo () {
  return function bar () {
    function baz () {} // top level of block, declaration
  }
}

function () {} // SyntaxError: function statement requires a name

if (true){
  function () {} //SyntaxError: function statement requires a name
}

Converting Expressions to Statements: Expression Statements

Is anything ever simple and straightforward with Javascript ðŸ˜ƒ

2+2; //expression statement
foo(); //expression statement

You can convert expressions to expression statement, just by adding a semi-colon to the end of the line or allowing automatic semi-colon insertion to do the work. 2+2 itself is an expression but the complete line is a statement.

2+2 // on its own is an opposition

foo(2+2) //so you can use it anywhere a value is expected

true ? 2+2 : 1 + 1

function foo () {return 2+2}


2+2; //expression statement
foo(2+2;) //syntaxError

Semi-colon vs Comma operator

With semi-colon, you can keep multiple statements on the same line

const a; function foo () {}; const b = 2

The comma operator allows you to chain multiple expression, returning only the last expression

console.log( (1+2,3,4) ) //4

console.log( (2, 9/3, function () {}) ) // function (){}

console.log( (3, true ? 2+2 : 1+1) ) // 4

Sidenote: one way to tell the Javascript engine to expect a value is via parentheses, (), without the parentheses, each expression will be treated as an argument to console.log.

function foo () {return 1, 2, 3, 4}
foo() //4

All the expressions will be evaluated from left to right, and the last one will be returned.

IIFEs (Immediately Invoked Function Expressions)

An anonymous function can be an expression, if we use it where Javascript is expecting a value, that means we if we can tell Javascript to expect a value with parentheses, we can pass an anonymous function as that value.

function () {}

So while the snippet above is invalid, the snippet below is valid

(function () {}) // this returns function () {}

If putting a anonymous function inside a parentheses immediately returns the same anonymous function, that means we can call it straight away, like this:

(function () {
  //do something
})()

So, these are possible

(function () {
  console.log("immediately invoke anonymous function call")
})() // "immediately invoke anonymous function call"

(function () {
  return 3
})() // 3

console.log((function () {
  return 3
})()) // 3

//you can also pass an argument to it
(function (a) {
  return a
})("I'm an argument") // I'm an argument

Object literals vs Block Statements

Sidenote: this is valid Javascript

r: 2+2 // valid

foo()

const foo = () => {}

The above are sequence of statements in the global scope that will be parsed as valid Javascript and executed. The r is what you’ll call a label, and they are mostly useful in breaking loops. Example:

loop: {
  for (const i = 0; i < 2; i++) {
    for (const n = 0; n <2; n++) {
      break loop //breaks outer loop and stops entire loop
    }
  }
}

You can prepend a label to any expression or expression statement, note that you not are creating a variable lab by doing this:

lab: function a () {}
console.log(lab) //ReferenceError: lab is not defined

Curly braces, {}, allow you to group expression statements and statements. So you can write,

{var a = "b"; func(); 2+2} // 4

If you paste the above in your browsers console, it will return 4 and when you do console.log(a), you will get string b. You can call that a block statement, which is different from the object literal you might be used to.

console.log({a: 'b'}) // {a: 'b'}

console.log({var a = "b", func(), 2+2}) // SyntaxError

const obj = {var a = "b", func(), 2+2} // SyntaxError

You cannot use a block statement as a value or expression, because console.log is a function, it cannot accept a statement as an argument. It can accept an object literal though.Â
I hope you understood all I explained above, cause the next snippet below might throw you off.

{} + 1 //1

{2} + 2 // 2

{2+2} + 3 // 3

{2+2} -3 // -3

You might expect it to throw either a syntax error or to return 1, 4, 7 respectively. Remember statements aren’t supposed to return anything because they can’t be used as values. So Javascript rather throwing an error, attempts to convert the operands of the + operator to a number or string, if it can’t then it throws. So whatever is returned by the block statement, is implicitly coerced to 0 used as the operand.

Whew, if you read all the way, you are the real MVP. That probably is all you need to know about Expressions, Statements, and Expression Statements.

What you need to know about Javascript's Automatic Semi-colon Insertion

Promise Tochi — Thu, 19 Oct 2017 23:52:28 +0000

Omitting semi-colons is a convenience that Javascript affords you. Javascript allows you to omit semi-colons in places where they’d normally appear, that is, at the end of statements or by convention before a new line character.

const foo = "food"; const randomNumber = Math.random()

Which can be rewritten as

const foo = "food"
const randomNumber = Math.random()

This is made possible thanks to the Automatic Semi-colon Insertion rules included in the official ECMAScript specification.

It’s a convenience though that if not properly understood can introduce a lot of Javascript gotcha scenarios. So, in this article I’ll talk about how the automatic semi-colon insertion works.

It might not be apparent that the two code snippets below produce totally different results,

/**/
const val = "foo";
['semi']
console.log(val) //foo

const foo = {
  semi: 'not semi'
}
const val = foo
['semi']
console.log(val) //not semi

If you are wondering why that is so, here’s what the ECMAScript 6 specification says about how automatic semi-colon insertion should work:

When, as a Script or Module is parsed from left to right, a token (called the offending token) is encountered that is not allowed by any production of the grammar, then a semicolon is automatically inserted before the offending token if one or more of the following conditions is true:

The offending token is separated from the previous token by at least one LineTerminator
The offending token is }
The previous token is ) and the inserted semicolon would then be parsed as the terminating semicolon of a do-while statement

I have tried to explain the rules above with the code sample below

/* Rule 1.1 */
const foo = 'food'
const bar = 'bar' /* Yo, I found token const on a new line, parsing it with the previous line as a single statement doesn't make sense, insert semi-colon before line 3 */

/* Rule 1.2 */
const baz = () => {
    const boo = true
  return boo } /* Found token }, insert semi-colon before it, parse previous statement */

/* Rule 1.3 */
do {
    const GT = foo + 'bar'
} while (baz()) /* Insert semi-colon after closing parentheses, gold could be on the next line for all I care */

Another way to sum up the first rule is,

“Hey, JS engine, if there’s no error parsing the code, continue and ignore the new line character. If there’s a parse error, do all these checks and insert semi-colon where necessary.”

The important thing to note here is, browsers will not insert semi-colons at the end of a line, if parsing a new line together with the previous line as one single statement, still results in valid Javascript. Back to the example at the beginning of this article:

const foo = {
  semi: 'not semi'
}
const bar = foo
['semi']

Even though [â€˜semi’] is on a new line, parsing it together with the previous line still results in valid Javascript.
So it is parsed as const bar = foo[â€˜semi’], which results in â€˜not semi’
While omitting semi-colons, developers must take special care when starting new lines with these characters:

[
(
+
/
-
{

const one = '1'
const two = 1
+one // this is a common technique for converting type 'string' to 'number'
console.log(two) // 11

It is common to see code similar to the example below in JS projects, and it might not become immediately apparent why it parses as correct Javascript grammar, but it is thanks to the Automatic Semi-colon Insertion rules we just discussed.

object
.childObject
.method()

The specification also state that,

When, as the Script or Module is parsed from left to right, a token is encountered that is allowed by some production of the grammar, but the production is a restricted production and the token would be the first token for a terminal or nonterminal immediately following the annotation “[no LineTerminator here]” within the restricted production (and therefore such a token is called a restricted token), and the restricted token is separated from the previous token by at least one LineTerminator, then a semicolon is automatically inserted before the restricted token.

This simply says no line breaks after certain tokens (keywords) like return, break, postfix expressions (- -, ++), throw, etc.

return //semi-colon is automatically inserted here
4 // no

break //semi-colon is automatically inserted here
a //no

continue //semi-colon is automatically inserted here
a = 4

const arr = arr () //semi-colon is automatically inserted here
=> {} // no

...

I hope you can now write Javascript without semi-colons with more confidence :)

Completely responsive CSS values, more than just media queries

Promise Tochi — Thu, 19 Oct 2017 13:00:55 +0000

The goal of this article is to achieve a font-size value that fluidly transitions from 14px at a browser window width of 769px, to 24px for a 2048px browser window width.

First off, let’s get the definition of a responsive DOM element out of the way. Responsive elements should respond to changes in viewport size, i.e when I reduce or increase the size of my browser window, a responsive DOM element should respond in some predefined way.

With CSS3 media queries, we are able to respond to screen resizes within CSS. Most of the time, these are breakpoints at 480px, 768px, and 769px. These are suitable for most web applications, but what if we could go further than just 3,4,5 break points? What if we could respond to every 1px browser resize all the way from over 2048px to 1px. That means we can create CSS declarations that respond to me reducing my browser window from 2048px to 2047px, responding to every 1px change all the way down to 0px.

Thanks to the CSS3 calc function, and viewport units (vh, vw), we can achieve this functionality.

The calc function lets you perform calculation when specifying CSS property values

Viewport units are represented as percentages of the visible area of a web page. That is the entire browser window, minus the address bar, scroll bar, tabs, etc.

Luckily both calc and viewport units have browser support all the way back to IE9.

html {
  font-size: 1vh;
}

In the code snippet above, if the browser width minus scrollbar is 1800px, font-size will be 18px, that’s 1% of 1800. That’s okay, but on a 800px screen, font-size will be 8px 😮. That’s not what we want.

Thanks to some clever calculations possible with the calc function we can overcome this problem.

If you have written Javascript or some proper programming language, there’s a good chance you’d have come across the mathematical expression below, if you have not, I’ve tried to explain it below.

(Math.random() * (769 - 2048) + 769)

This is a Javascript snippet and what it does is generate a random number within the range of 769 and 2048. Math.random() generates a random number between 0 to 0.9999999999999999. We get that number and multiply it by the difference between 2048 and 769, which is 1279. This ensures random number*(1279+769), always return a value between 769 and 2048. You can try it out yourself, 0*(1279)+769 is 769 and 0.99*(1279)+769 gives you 2035.21.

So we have the basis for further calculations.

In our case, we want a font-size within the range 14px to 24px, so our range is 10px and 14px is our base. What we want is to generate a random number between 0 and 0.999999999999, multiply it by 10 and add it to 14. So that, 0*10+14 is 14, and 0.9999*10+14 is 23.9999, but we don’t have access to Javascript’s Math.random within our CSS. How do we generate the random number we need then?

Let’s take a look at what we have. With the VW viewport unit, we can dynamically access the window’s width with 100vw. So 100vw on a 1366px screen is 1366px, on a 1560px screen, it’s also 1560px, without us hard-coding the specific pixel value.

With our target minimum screen width (769px), maximum screen width (2048px) and dynamically calculated screen width (100vw), we are armed with what we need to generate a random number from 0 to 0.99999999999. By simply doing (100vw — 769px)/2048px, we can generate any value from 0 upwards, depending on the value of 100vw. So if a users viewport width is 1800px, (100vw — 769px)/2048px is calculated as (1800px — 769px)/2048px by the browser, which results in 0.50341796875. Yay, we have our random number. We can now multiply 0.50341796875 by 10 (remember our range?), which results in 5.0341796875. The final step is to add 5.0341796875 to 14px 5.0341796875, which results in a 19.0341796875px font-size for a user with a 1800px viewport width.

The final formula can be written as,

html {
  font-size: minimumPixel + range * ((viewportWidth - minScreenWidth) / maxScreenWidth)
}

/* Example */

html {
  font-size: calc(14px + 10 * ((100vw - 769px) / 2048));
}

So instead of serving all viewport widths between 769px and 2048px the same font width, usually 18px, we can dynamically serve users a more suitable range from 14px to 24px.

This can be combined with media queries to achieve as much responsiveness as possible

/* Example */

/* Mobile and Tablet */
@media (max-width: 768px) { 
  html {
    font-size: calc(16px + 2 * ((100vw - 360px) / 768));
  }
}

/* Laptop and Desktops screens */
@media (min-width: 769px) {
  html {
    font-size: calc(14px + 10 * ((100vw - 769px) / 2048));
  }
}

/* Excessively large screens */
html {
  font-size: 36px;
}

This can be applied to be more than just font-size, it can be used to create paddings, margins, widths that stretch and squeeze as the viewport width increases and decreases.

I hope you enjoyed the article, hopefully you'll use this technique a lot more in your projects.

Quick intro to CSS’s Box-model

Promise Tochi — Wed, 18 Oct 2017 21:06:22 +0000

This is a quick intro to what you need to know about the box-model, what to avoid and what’s best to use.

The CSS box model is quite simple. Every HTML element is represented as a rectangular box taking up different portions of the users screen. As in the space taken up by the div element below for example

<div>A div that will take up some rectangular space on the screen</div>

The div tag above is a BLOCK element taking up the height of its content (text, in this case) and the full width of its parent element. In this case, its parent element is the body which takes up the full width of its parent element, the html element. The html element is the root element in any HTML document, so it automatically takes up 100% of the screen width, so every BLOCK element that is its descendant takes up 100% of the screen width as well, unless it’s width is explicitly set with CSS.

Back to the box model, four things make up the box of any HTML element,

Width and height
Padding
Border
Margin

In CSS, there are two ways to calculate the box-model for an element, they are,

content-box
border-box

The content-box is the model that browsers use by default, and it is the less desirable one.
Â
The way the content-box model works, is, you specify the width and height for an element, any further additions to the box of any element will be added to its width and height. For example,

div {
  box-sizing: content-box;
  width: 200px;
  padding: 50px;
}

We have specified the width of the div element to take up 200px but with the content box model, div will take up a width of 300px instead. That is, any further additions via padding or border will be added to the element’s width to make up the actual space it would take up on the users screen.

The border-box model on the other hand, takes the specified width and height as the total space an element will take up on the users screen, regardless of how much padding or border is added to the element.

div {
  box-sizing: border-box;
  width: 200px;
  padding: 50px;
}

In the code example above, div will take up a width of 200px on the users screen and it’s content or children will have only 100px to work with. So if I wrote

<div>
<span></span>
<div>

div {
  box-sizing: border-box;
  width: 200px;
  padding: 50px;
}

div span {
  width: 100%;
}

The width of span would be 100px

The margin in the box in both models doesn’t get subtracted from the specified width. So far example, if you wrote,

div {
  box-sizing: border-box;
  width: 200px;
  margin: 50px;
}
div {
  box-sizing: content-box;
  width: 200px;
  margin: 50px;
}

Both do the same thing, there is no difference in what is translated to the screen.

The content-box model can get confusing and requires you to always keep paddings and border values applied to elements in my mind. With the border-box model you are guaranteed that whatever width you specify would remain the same regardless of the padding and border, which is easier to remember.

Rather than specifying the box-sizing property for every element, you would usually find this snippet in most CSS projects

*, *::before, *::after {
  box-sizing: border-box;
}

This effectively causes every element on the page to use the border-box box model and also applies it to the before and after pseudo-elements.

That’s a wrap on box-model. For more info, checkout MDN’s awesome documentation https://developer.mozilla.org/en-US/docs/Web/CSS/box-sizing