DEV Community: Maximo Martinez Soria

Not everything is an object in JavaScript

Maximo Martinez Soria — Fri, 24 Jul 2020 20:56:41 +0000

"Everything in JavaScript is an object" is a well known sentence that almost everyone have heard at least once. However, this is not correct at all.

In order to understand the differences between JavaScript datatypes, let's split them into two categories: Primitive datatypes and Objects.

Primitive datatypes

Primitive datatypes are those things that aren't objects. They are just what they are.

For example: a string, it's a string and that's it.

There are seven primitive datatypes in the language so far:

String: usually texts, but it can be everything you insert into double or single quotes.
Number: quite self-descriptive. It can only save 64 bits.
BigInt: same as Number, but it can save more than 64 bits.
Boolean: only two possible values: true or false.
Symbol: it's an anonymous and unique value.
undefined: it's used by JavaScript to say that something doesn't have a value.
null: it's an invalid or nonexistent value. You can use it to initialize a variable which is going to has an object later.

Null, is a special one, because if you check its type with the typeof operator, it's going to return object.

All of these have two things in common:

They are immutable: they cannot change. If you change them, you are just creating a new one.
They don't have any methods or properties.

If primitive datatypes don't have methods or properties, then, why can we use string.toUppercase()? or any of the other methods that primitives have.

This is possible because some of the primitives have their equivalent in the objects world. That means that we use string type when we declare a string, but we use String object when we use some of the methods or properties on it.

Another question that you may have is how or when is the string converted to an object.

This is related with how the engine works.

The engine, "wraps" the primitive datatype into its equivalent object.

Finally, why don't keep it simple and just use objects everywhere? Smart question. We'll talk about it later. Let's discuss objects first.

Objects

Everything else, such as functions or arrays, are objects.

We've already talked about differences between objects and primitives. But there is one more. This one is quite more advanced, but it's also important in order to have a good understanding of how JavaScript actually works.

Memory

Let's go back to that question about why we use primitives instead of having everything as an object.

The answer is: because of how memory is handled.

JavaScript uses two kinds of memories: Memory Heap and Memory Stack.

Memory Stack, is where primitives are saved. This memory is smaller, but it's faster than Memory Heap. On the other hand, Memory Heap is bigger, but slower.

So what JavaScript does is that it saves primitives and a reference to objects into the Memory Stack and saves the complete object into the Memory Heap.

That's why we cannot copy objects that easy in JavaScript.

const obj = {
    string: 'primitive',
    array: 'object',
}

const objCopy = obj
objCopy.number = 'primitive'

console.log(obj) // {string: "primitive", array: "object", number: "primitive"}
console.log(objCopy) // {string: "primitive", array: "object", number: "primitive"}

Give it a shot in the console and you'll see it.

Since we are just copying a reference, both variables point to the same object.

To avoid this behavior, you can use the spread operator.

const obj = {
    string: 'primitive',
    array: 'object',
}

const objCopy = { ...obj }
objCopy.number = 'primitive'

console.log(obj) // {string: "primitive", array: "object"}
console.log(objCopy) // {string: "primitive", array: "object", number: "primitive"}

Why you should create your own Webpack configuration for React and how to do it

Maximo Martinez Soria — Thu, 16 Jul 2020 20:08:33 +0000

We all know create-react-app and how easily we can get a React project configuration done. However, when you need some more project-specific stuff, you would definitely like to know how to change or add things.

On the other hand, it's always a good idea to understand what's happening under the hood.

This is the second part of Let's create a Webpack configuration from scratch and I'll be using the files created on that post. So go and check it out before continue reading or just clone the repo if you have a good understanding of how Webpack works.

Here you have the repository of this post: react-webpack-configuration

Feel free to use it if you feel lost at some point.

Set Up

First of all, if we are going to code a React app, we'll need React.

$ npm i react react-dom

Also, let's create an entry point and a first component. Just to have something to test with.

// src/index.js
import './sass/index.scss' // remember to import your styles in this file
import React from 'react'
import { render } from 'react-dom'
import App from './components/App'

render(<App />, document.querySelector('#app'))

Let's create a hello world.

// src/components/App.js
import React from 'react'

const App = () => <p>Hello World!</p>

export default App

Now we are ready to go.

Babel for React

We already have some babel configuration in our .babelrc file. But it's not enough for React.

We'll need one more package.

$ npm i -D @babel/preset-react

Then, just add it to the presets array.

// .babelrc
{
    "plugins": [
        "@babel/plugin-transform-runtime"
    ],
    "presets": [
        "@babel/preset-env",
        "@babel/preset-react"
    ]
}

Development

As you know for the previous post, we're using two different files to take apart development and production configurations.

We've done quite a good job last time. But we need to improve something for React.

Hot Module Replacement

Hot Module Replacement, allows us to refresh just one part of the browser every time we save a file. This makes the developer experience delightful.

Let's do it.

// webpack.dev.config.js
...
const webpack = require('webpack')

module.exports = {
  ...
  devServer: {
    contentBase: path.resolve(__dirname, 'dist'),
    open: true,
    hot: true
  },
  ...
  plugins: [
    new webpack.HotModuleReplacementPlugin(),
    ...
  ],
}

webpack.HotModuleReplacementPlugin does quite all the job. Remember to import webpack and set hot to true in devServer object.

Finally, we'll need to make a little refactor in the entry point.

// src/index.js
import './styles/index.scss'
import React from 'react'
import { render } from 'react-dom'
import App from './components/App'

function renderApp() {
    render(<App />, document.querySelector('#app'))
}

renderApp()
if (module.hot) {
    module.hot.accept('./components/App', () => renderApp())
}

Encapsulate react render function into a custom function and then tell webpack to re-run that function every time we save the file.

Production

This is probably the worthiest part of making a custom configuration.

You can really improve performance and user experience with the following technique. However, there are a lot of things you could add here.

Dynamic Link Library

Dynamic link library is a set of libraries that hardly ever change. So we're going to pre-bundle them in order to avoid bundle them every time we run our build command. Also, the fact of having these libraries in a different file, will prevent the browser to download them over and over again.

First, we need to create a new webpack file. Yes, another one. This one is so simple and it's usually called webpack.dll.config.js.

// webpack.dll.config.js
const path = require('path')
const webpack = require('webpack')

module.exports = {
    entry: {
        modules: ['react', 'react-dom'],
    },
    output: {
        path: path.resolve(__dirname, 'dist'),
        filename: 'js/[name].dll.js',
        library: '[name]',
    },
    mode: 'production',
    plugins: [
        new webpack.DllPlugin({
            name: '[name]',
            path: path.join(__dirname, '[name]-manifest.json'),
        }),
    ],
}

You might be able to understand almost everything. But there are a couple of weird things...

Why is the entry point receiving and array of strings? Well, those strings are the names of the libraries. And those libraries are the ones that we are compiling.

In this case we're only using react and react-dom because it's a very simple example. But go ahead and install react-router, redux or any other library that you want and add them to the modules array.

Output and mode are quite simple. We've been using them for a while and they don't have nothing new in this case.

Finally, we are using a new plugin. It is part of the Webpack core and it help us creating a manifest. This manifest, is going to tell Webpack not to re-compile this libraries that we've already compiled.

That next step, is the build command and in order to make that happen, we need to add a plugin.

// webpack.config.js
...
const webpack = require('webpack')

module.exports = {
    ...
  plugins: [
    ...
        new CleanWebpackPlugin({
      cleanOnceBeforeBuildPatterns: ['**/main.*']
    }),
    new webpack.DllReferencePlugin({
      manifest: require('./modules-manifest.json')
    }),
        new AddAssetHtmlPlugin({
      filepath: path.resolve(__dirname, "dist/js/*.dll.js"),
      outputPath: "js",
      publicPath: "http://localhost:3001/js/"
    })
  ]
}

This one is again part of the Webpack core and it reads the output of DllPlugin and prevents Webpack from compiling our libraries again.

On the other hand, I've changed the pattern of CleanWebpackPlugin to avoid deleting our modules.dll.js file.

Finally, we're using a new plugin which links our modules.dll.js to our html file automatically.

$ npm i -D add-asset-html-webpack-plugin

React code and Webpack Docs

We've finished. But if you want to continue improving your user and development experience, I leave you a couple of things to look at.

You can make a lot of difference in user experience if you take care of your React code. These are a couple of React techniques related with performance:

PWAs could be complicated at the beginning but they're really useful and allow you to have awesome features like offline support, notifications, offline analytics, shortcut icon from smartphones and computers, etc.

Also, don't forget to check out Webpack's documentation. It's plenty of interesting options to improve either your experience or the users one.

Let's create a Webpack configuration from scratch

Maximo Martinez Soria — Fri, 19 Jun 2020 16:41:50 +0000

Even though It's not that difficult, webpack could be so intimidating.

We just need to understand a couple of things.

At the end of the post you will be able to fully understand how to write a webpack.config.js file.

This is the full repo: https://github.com/maximomartinezsoria/webpack-boilerplate

Feel free to check it out if you feel lost at any point.

Let's get started.

Setup

First of all, we'll need to create a new folder and initialize git and npm.

We'll also create a src folder with a javascript file where our code is going to live.

# create a new folder and move into it
$ mkdir webpack-boilerplate
$ cd webpack-boilerplate

# Initialize git and npm
$ git init
$ npm init

# create src folder, move into and create a file
$ mkdir src
$ cd src
$ touch index.js

Then, we'll install webpack and webpack-cli. The first one, is the core library and the other will help us interact with webpack.

# i: install
# -D: development dependencies
$ npm i -D webpack webpack-cli

Finally, let's create a configuration file at the same level of package.json.

$ touch webpack.config.js

You should finish with somthing like this:

- webpack-boilerplate
  - node_modules
    - ....
  - src
    - index.js
  - package.json
  - package.lock.json
  - webpack.config.js

Getting into Webpack

Let's work a little bit in webpack.config.js file.

// webpack.config.js
const path = require('path')

module.exports = {
    entry: path.resolve(__dirname, 'src/index.js'),
    output: {
        path: path.resolve(__dirname, 'dist'),
        filename: 'js/[name].js',
    },
}

This is a node file, so we are using commonjs instead of es6 import / export syntax.

Entry, is where Webpack is going to look for the code.

From now on, if you want a code to pass through Webpack, you'll need to import it in that file.

CSS, preprocessors, and other sort of files could be imported as well. Just need the proper loader.

Output, is where Webpack is going to drop the resultant files.

Notice that we are using a placeholder. This one will be replaced with the name of the file by Webpack.

Giving it a shot

We need to create some commands in order to start using webpack.

// package.json

{
  ...
    "scripts": {
        "dev": "webpack"
    }
  ...
}

As simple as that.

$ npm run dev

The command will throw you a warning message saying that you should specify the mode option.

Go ahead and add a flag to the command specifying either development or production.

We are going to create specific configurations for both modes later, so it's not important right now.

Loaders and Plugins

Loaders allow us to load and pre-process different kinds of files, and plugins extends their possibilities.

I know that this doesn't make much sense right now, but you'll understand soon. Let's go to the code.

Handle HTML

As you now know, the entry point and main file of the app is index.js.

As you also know, browsers need html files. At least one.

The first thing that we are going to do, is to export a html file.

// webpack.config.js
const path = require('path')
const HtmlWebpackPlugin = require('html-webpack-plugin')

module.exports = {
    entry: path.resolve(__dirname, 'src/index.js'),
    output: {
        path: path.resolve(__dirname, 'dist'),
        filename: 'js/[name].js',
    },
    plugins: [
        new HtmlWebpackPlugin({
            template: path.resolve(__dirname, 'public/index.html'),
        }),
    ],
}

Remember to install the plugin.

$ npm i -D html-webpack-plugin

Babel for modern JavaScript

Not all people use modern browsers. That's why we need Babel to transpile our modern JavaScript into ES5.

First, we need to install some dependencies:

$ npm i -D babel-loader @babel/core @babel/preset-env

As I told you, loaders allow us to load different kinds of files.

This time we have babel-loader, which loads JavaScript files into @babel-core, which transpiles our modern JavaScript into ES5 using the rules defined in @babel/preset-env.

After that little explanation, let's go to the code.

In order to use a loader, we need to use the key module and set an array of rules inside it.

Each rule has some configurations. In this case we are using the followings:

test: tells Webpack which kind of files is this rule for.
use: which loader will be applied in this rule.
exclude: we are excluding the node_modules folder to improve performance.

// webpack.config.js
module.exports = {
    ...
  module: {
    rules: [
      {
        test: /\.js$/,
        use: 'babel-loader',
        exclude: /node_modules/,
      },
    ]
  },
  plugins: [
    ...
  ],
}

Ok. We are asking Webpack to use babel. Now we need to tell babel what to do.

All babel configurations need to be set in a specific file called .babelrc in the root folder.

In addition to presets, we can use plugins to increase presets functionality.

In this case, lets install @babel-plugin-transform-runtime, which allows us to use async/await.

We are also installing @babel/runtime. It's needed by the plugin and it's highly recommended to install it as a production dependency.

$ npm i -D @babel/plugin-transform-runtime
$ npm i @babel/runtime

// .babelrc
{
    "plugins": [
        "@babel/plugin-transform-runtime"
    ],
    "presets": [
        "@babel/preset-env"
    ]
}

Styles

Every website or app needs styles.

As you already know, loaders allow us to import different kinds of files into webpack.

Does that mean that we can import css into JavaScript? Yes, it does.

It sounds weird and a little bit crazy, but importing css in JS is how we include our styles into the bundle.

$ npm i -D style-loader css-loader

Importing css into JavaScript is actually weird. That's why we need a couple of things.

css-loader is the one who handle the importing, and style-loader injects css in the html file that we've already generated with HtmlWebpackPlugin.

If you want to use a preprocessor, you need one more loader to handle that file and the specific preprocessor library itself.

SASS / SCSS

$ npm i -D sass-loader node-sass

STYLUS

$ npm i -D stylus-loader stylus

LESS

$ npm i -D less-loader less

The code is quite similar than the last time. We are just adding more rules.

// webpack.config.js
...
module: {
    rules: [
        {
          test: /\.css$/,
          use: [
            'style-loader',
            'css-loader',
          ],
        },
        {
          test: /\.scss$/,
          use: [
            'style-loader',
            'css-loader',
            'sass-loader'
          ],
        },
        {
        test: /\.less$/,
        use: [
          'style-loader',
          'css-loader',
          'less-loader'
        ],
      },
      {
        test: /\.styl$/,
        use: [
          'style-loader',
          'css-loader',
          'stylus-loader'
        ],
      },
        ...
    ]
}
...

Let's recap.

First, we've used a specific loader for a preprocessor, which turns the code into css. Then, css-loader handles that code and finally style-loader injects css into html.

Remember to import these files into your main JS file.

// index.js
import './index.css'
import './index.scss'
import './index.less'
import './index.styl'

Images, videos and fonts

In order to use images, videos or fonts in our css, we need to use a specific loader.

In this case, we are using an object in the use key. This allows us to use additional configurations like the output path.

$ npm i -D file-loader

// webpack.config.js
...
module: {
    rules: [
        ...
        {
            // '?' means that 'e' is optional. So we can use jpg or jpeg
      test: /\.jpe?g|png|gif|woff|eot|ttf|svg|mp4|webm$/,
      use: {
        loader: 'file-loader',
        options: {
          outputPath: 'assets/'
        }
      },
    },
        ...
    ]
}
...

Development vs Production

We've already learned a lot about Webpack. We are able to use lots of files as well as modern Javascript and CSS preprocessors.

But the real power of Webpack is to make a better developer experience in development mode and a better user experience in production mode. That's why we are going to make two different configurations from now on.

Development

Let's create a new configuration file for development purposes.

The standard name is usually webpack.dev.config.js, but you can use anyone.

We need all the things that we've done before. So I'm going to rename the file that I was using, as oposed to create a new one.

Since we are working in development mode, let's get Webpack to know that, using the mode key.

//webpack.config.js
module.exports = {
  entry: path.resolve(__dirname, 'src/index.js'),
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'js/[name].js',
  },
  mode: 'development',
    ...
}

It's also time to change our package.json script.

// package.json
...
"scripts": {
  "dev": "webpack-dev-server --config ./webpack.dev.config.js"
},
...

The config option defines the path to the config file.

Let's talk about webpack-dev-server.

Development server

The first and one of the most important things that a developer needs is a local server.

That's what we use webpack-dev-server for.

$ npm i -D webpack-dev-server

We also need to write the configuration for the server.

  //webpack.config.js
module.exports = {
  ...
  mode: 'development',
  devServer: {
    contentBase: path.resolve(__dirname, 'dist'),
    open: true,
  },
    ...
}

contentBase defines the directory where is going to look for the files and open in true, means that when we run the command Webpack is going to open a browser automatically.

From now on, Webpack is going to create a new bundle every time you save a file.

Production

Our development configuration is done.

But for a better user experience we can change some things for production.

As we are going to change lots of things, let's create another file and make a new script. I'll call it webpack.config.js.

// package.json
...
"scripts": {
  "dev": "webpack-dev-server --config ./webpack.dev.config.js",
  "build": "webpack"
},
...

As long as you use the default name (webpack.config.js), config option is not required.

We can reuse some options that we've already written, so my new file it's just a duplication from webpack.dev.config.js.

Some important changes that we need before getting started are:

mode: set to production.
devServer: remove the entire object. We don't need a local server in production.
output: is a good practice to use hash in production files in order to avoid cache problems.

...
entry: path.resolve(__dirname, 'src/index.js'),
output: {
  path: path.resolve(__dirname, 'dist'),
  filename: 'js/[name].[hash].js',
},
mode: 'production',
..

Now we are ready to start.

Extracting styles

The first difference between development and production is how styles are handled.

In development, we inject the css in order to accelerate things. But in production we need a css file. That's why, we are using a new loader that will extract the css into a new file.

$ npm i -D mini-css-extract-plugin

So, is it a plugin or a loader? Actually, both. You'll see.

We need to pass it as a plugin to define both the output filename and the chunkFilename.

The hash placeholder, allows us to avoid cache problems.

We need to pass it as a loader also. And, as you can see, we are not using style-loader any more.

// webpack.config.js
const MiniCSSExtractPlugin = require('mini-css-extract-plugin')
...

module.exports = {
  module: {
    rules: [
      {
        test: /\.css$/,
        use: [
          {
            loader: MiniCSSExtractPlugin.loader
          },
          'css-loader',
        ],
      },
      {
        test: /\.scss$/,
        use: [
          {
            loader: MiniCSSExtractPlugin.loader
          },
          'css-loader',
          'sass-loader'
        ],
      },
      {
        test: /\.less$/,
        use: [
          {
            loader: MiniCSSExtractPlugin.loader
          },
          'css-loader',
          'less-loader'
        ],
      },
      {
        test: /\.styl$/,
        use: [
          {
            loader: MiniCSSExtractPlugin.loader
          },
          'css-loader',
          'stylus-loader'
        ],
      },
      ...
    ]
  },
  plugins: [
    ...
    new MiniCSSExtractPlugin({
      filename: 'css/[name].[hash].css',
      chunkFilename: 'css/[id].[hash].css'
    })
  ],
}

So, let's recall.

We are using css-loader or the specific loaders for preprocessors to allow importing those files into JavaScript. Then, we use MiniCSSExtractPlugin to extract css and create a file with it. Finally, that new file will be linked to the html automatically.

Cleaning

We are almost done. Let's add two more fixes.

The first one is related with hashes. As you know, we are using hashes everywhere to avoid cache problems. But now we have a problem with hashes. It's a bug or a feature?

The problem is that we are creating new files every time we run Webpack, but we are just using the last one. So, if you run a couple of times the command and see the css or js folder, you are going to find lots of garbage files.

It would be great to erase all of those files before each run of Webpack. Let's do it.

$ npm i -D clean-webpack-plugin

// webpack.config.js
const { CleanWebpackPlugin } = require('clean-webpack-plugin')

...
    plugins: [
        ...
        new CleanWebpackPlugin({
          cleanOnceBeforeBuildPatterns: ['**/*']
      })
    ]
...

That does exactly what we want. It cleans the whole dist folder before each bundle creation.

Note that you can modify the pattern (**/*) to match just the things you want. This might be useful when you are using dll for example.

Minify CSS

The second fix is that css is not being minified.

Minification process removes all unnecessary spaces in the file so it becomes smaller.

$ npm i -D optimize-css-assets-webpack-plugin

// webpack.config.js
const OptimizeCSSAssetsPlugin = require('optimize-css-assets-webpack-plugin')

...
    output: {
    ...
  },
    optimization: {
    minimizer: [ new OptimizeCSSAssetsPlugin() ]
  },
...

optimization is a new key that we didn't use before. I recommend you to take a look at the docs to know more about this key.

The perfect configuration

since this is a very general configuration, we're done.

But this isn't the perfect Webpack configuration. Actually, that doesn't exists.

Each project has its own configuration so you can do whatever you need.

I'm preparing another example of Webpack configuration for React. Stay tuned.

HTTP Explained

Maximo Martinez Soria — Thu, 30 Apr 2020 13:15:15 +0000

HTTP stands for Hyper Text Transfer Protocol and is the one that specifies the rules on the communication between two computers through internet.

Verbs

The verbs are actions that define what each request is about to do.

GET: fetch data.
HEAD: get headers. It's like a GET request but without content.
POST: create information.
PUT / PATCH: update information.
DELETE: delete information.

Verbs, allow us to have different responses for only one endpoint.

We could create lots of endpoints for a resource or we can just use the main word and use the verbs.

For example:

GET /books
POST /books
DELETE /books

Is better than:

GET /get-all-books
POST /create-a-book
DELETE /delete-book

Status

Every request is going to return a status code. Let's see which codes exist and why.

1xx: pending. Nothing happened yet.
2xx: success.
3xx: usually a redirect.
4xx: client-side errors.
5xx: server-side errors.

Common Status Codes

200: everything is ok. Usually used in GET request.
201: everything is ok. Usually used in POST / PUT request.
204: usually used to say that a DELETE request was completed successfully. The resource was deleted.
400: bad request. Something is wrong in the request.
401: unauthorised. You need to specify credentials first.
403: forbidden. You don't have permissions over that resource even though you are authenticated.
404: not found. Resource doesn't exist.
500: internal server error. The request couldn't be processed.

Mastering Git

Maximo Martinez Soria — Wed, 29 Apr 2020 15:14:41 +0000

Git is an atomic version control system that allows us to keep a very specific tracking of our code or whatever plain text documents you want.

Awesome, but why should I use git?

When you have some code and you need to change it, how do you save the last version?

You might use something like this:

myCode.js
myCode_v2.js
myCode_v3.js

Terrible!

That horrible way of organization has a ton of problems:

Saves all the code again, when you only need the new changes.
You can't go back easily.
You can't track changes between versions.
You can't work with others.

Git solve all these problems and many more. Let's take it a look.

Getting started
- Installation
- Configuration
First steps
- Tracking code
Branches
Take a look at the changes
Go back to a previous version
Git WorkFlow
- New features
- Fix
Save the repository in an online server
- Asymmetric encryption
- Pulling and pushing code
Gitignore
Readme
Tags
Rebase
Stash
Removing files
Git cherry-pick
Amending commits
Clone
Git reflog
Search
Complete log
Aliases
Git is really big

Getting started

Installation

The installation is kind of different across operating systems. So we will take care of each one separately.

Mac OS

It's quite simple in mac. You only need to go to the git page, download the .pkg installler, open it and follow the instructions.

Windows

Again, go to the git page, download the .exe installer, open it, and follow the instructions.

It should be configured by default, but doble check the settings in the installer. You need to install git bash and open ssl in order to get git to work.

Linux

If you are using linux, you might know more than me.

First, it is a good practice to update and upgrade your package manager. Then, you can install git and you shouldn't have any problem.

# Example with apt-get, which is the package manager for ubuntu, debian and others distributions based on those.
$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get install git

Configuration

Git works almost out of the box. The only thing that you need to do, is to tell it what's your name and email.

From now on, we will use the terminal for everything.

If you are a windows user, you might want to use git bash.

$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com

First steps

First of all, you need to initialize a git repository inside the folder that you want to track.

$ git init

That command creates two different areas: staging and repository.

Staging

It is a RAM space and a bridge between our non-tracked code and our repository.

Repository

Here is where our tracked code lives.

Tracking code

When you have a new change in your code, and you want to track it, you need to add it to the staging area.

$ git add webpack.config.js

Finally, you need to commit it to the repository with a descriptive message of what you have changed.

$ git commit -m "Webpack configuration"

Branches

Each branch is a different timeline of the code.

Imagine you are working on frontend features and your partner on backend features. So you might have two branches: frontend and backend.

By default, all your changes are going to a branch called master.

# Create branch
$ git checkout -b my-new-branch

# Delete branch locally
# -d will delete the branch only if it has already been pushed and merged with the remote branch.
# Use -D instead if you want to force the branch to be deleted, even if it hasn't been pushed and merged yet.
$ git checkout -d my-new-branch

# Delete branch remotely
$ git push origin --delete my-new-branch

Take a look at the changes

You can see the whole history of a file with the command show

$ git show webpack.config.js

If you need to compare two specific commits you can do it with the command diff

$ git diff id-commit-x id-commit-y

In order to see the id of each commit, take a look at the log.

$ git log

Go back to a previous version

Git gives us a couple of possibilities to go back in time.

# Go back but keep the added changes (This will erase all the changes made after the selected commit)
git reset id-commit --soft

# Go back and erase added changes (This will erase all the changes made after the selected commit)
git reset id-commit --hard

# Go back without erasing anything
git checkout id-commit

# Go back a specific file
git checkout id-commit webpack.config.js

Git WorkFlow

Usually you are going to have two main branches: master and develop.

Master is where production code lives and develop where staging code does.

Remember that staging as environment isn’t the same as the git area called with the same name. As environment, it’s the middle place between production and local. Where we can test all the features as a user before doing the final deploy.

On the other hand, the project could have hundreds of branches. Let’s see how we can deal with them in an organized way.

New features

In order to keep things tidy and simple, you might want to create a new branch for each new feature that you need to code.

# Create a new branch called Feature/Auth
$ git checkout -b Feature/Auth

Once you’ve finished coding. You might want to see those changes in staging or production. Therefore you need to merge it with either master, develop or whatever the deploy branch is called in your project.

# Move to master
$ git checkout master

# Merge branch
$ git merge Feature/Auth

Fix

We usually call hotfix to the branch where we work on killing those bugs that need immediate attention.

$ git checkout -b hotfix

Again, once you are ready, merge changes with master or develop.

# Move to master
$ git checkout master

# Merge branch
$ git merge hotfix

Save the repository in an online server

Let’s use GitHub for this example, but keep in mind that it's sort of similar in the other platforms.

I’m pretty sure that you can create an account on your own so let’s skip that step.

Once you have an account, you need to create a repository clicking the green button and filling the required fields.

Don’t worry about .gitignore and Readme files right now. We will get there soon.

Asymmetric encryption

The best and most secure way to connect our computers with GitHub is with asymmetric encryption.

In summary, you need two keys. A public one and a private one. Github will have your public key and your computer will have the private one.

Every piece of information that travels across the internet will be encrypted with those keys. The only way to decode it, is having them both.

Don’t worry about the difficult words right now. Just follow my steps in order to configure the whole environment.

First of all, we will create a set of keys running a command in the terminal. Keys, will be called id_rsa(Private) and id_rsa.pub(Public) and will live in a new folder called .ssh in the home of your computer. Also, the command will ask you a passphrase.

Second of all, we will turn on the ssh keys agent, which is a process that do all the magic behind the scenes.

Then, we will add our private key to that agent.

Finally, we will add the public key on GitHub.

Let’s do it.

Things are kind of different in Mac. So let’s start with windows and linux:

# Generate ssh keys
$ ssh-keygen -t rsa -b 4096 -C "your@email.com"

# Turn on ssh keys agent in your machine
$ eval $(ssh-agent -s)

# Add keys to the agent
$ ssh-add ~/.ssh/id_rsa

Now for mac users:

# Generate ssh keys
$ ssh-keygen -t rsa -b 4096 -C "your@email.com"

# Turn on ssh keys agent in your machine
$ eval "$(ssh-agent -s)"

# Create a config file inside the new .ssh folder
$ touch ~/.ssh/config

# Add this content to the file.
Host *
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/id_rsa

# Add keys to the agent
$ ssh-add -K ~/.ssh/id_rsa

Now, let’s add the public key on GitHub. First, copy the content of the public key. You can see it with cat.

$ cat ~/.ssh/id_rsa.pub

There is a specific menu for ssh into Github settings: https://github.com/settings/keys.

Add a SSH key, put a title and paste your public key.

Title usually is the model of the computer.

Pulling and pushing code

Going back to the terminal and in order to be able to push your committed changes, you have to set up an origin.

The origin, tells git where to find the remote repository.

$ git remote add origin https://github.com/maximomartinezsoria/app.git

Remember to use your own repository’s link

Finally, let’s push our code.

The first time that you push a repository, you will need to tell git which origin to use.

$ git push -u origin master

From now on, you can keep it simple and just push without specifying anything.

$ git push

If the repository already had some code before your first push, git would throw an error. You will need to allow git to merge the local history with the upcoming history.

$ git pull origin master —allow-unrelated-histories

If you’re working with a team, they might push their code to the same repository.

Next time that you need to push, git will tell you that there is code that you don’t have in your local repository. So you will need to pull it down.

# Download changes and merge them with local code automatically
$ git pull

Gitignore

Sometimes, we need git to avoid tracking some files. For instance, we don’t want to track compiled files or node_modules folder.

.gitignore, is a file that tells git what not to track.

Let’s create an example:

Create a .gitignore file in the root of your project and paste this content:

# env files and node_modules folder should not be tracked by git
.env
/node_modules

Now, add everything with git add -A and you'll notice that the files specified in .gitignore are not included.

Readme

Readme files are the ones that you can see at the end of each GitHub repository. They usually contain highlights of the documentation or how to set up the project.

Here you can see an example: https://github.com/maximomartinezsoria/minimalist-spa-router/blob/master/Readme.md

Rebase

Previously in this article, we used merge to join two branches. If you take a look at the log, you will see both branches, the commits on them and the point where they were merged.

With rebase, we are able to merge two branches and erase the history.
What rebase actually does is to show the commits that were made in a branch as if they were made in another.

It's quite simple to get that result. Just make two rebases, one from the branch that you don't want anymore and another from the branch that is going to keep all the changes.

$ git checkout experiment
$ git reabase master

$ git checkout master
$ git rebase experiment

Keep in mind that we use Git in order to have a complete history of all our project's changes. Using this kind of things might be considered as a bad practice, because you are changing that history and making it not completely real.

Stash

Imagine this situation:

You are working in a feature. You coded a lot. Eventually, you need to take a look at something in another branch, but you are not ready to commit your changes. So, what can you do?

Stash allows us to save current not commited changes in a temporary place.

# Save not commited changes in a temporary place
$ git stash

Now, you can go to another branch and do whatever you want.

When you want to bring those changes back, you just pop them.

# Bring stashed changes back
$ git stash pop

You can also see the list of all your stashed code and erase it if you don't need that code anymore.

# List stashs
$ git stash list

# Erase stashs
$ git stash drop

Another cool thing about stash, is that you can take your current changes and go to another branch without a commit.

# Create a new branch called 'new-feature' with the current changes.
$ git stash branch new-feature

Removing files

Git clean, delete those new files that are not tracked yet.

# See what files will be deleted but don't erase anything
$ git clean --dry-run

# Delete the files listed by the previous command
$ git clean -f

Git rm, allows us to delete tracked files.

# Delete file from staging area but keep it in your computer
$ git rm --cached

# Delete file from staging area and from your computer
$ git rm --force

Git cherry-pick

Imagine that you are working in that awesome new feature. As a good practice, you are coding in a new branch. Eventually, you need to deploy one commit of that branch. But you haven’t finished your new feature yet. So you need to merge your feature branch with master but want only one commit.

It's kind of a weird situation, but it could happen. Git, solves this problem with something called cherry-pick

# Look for the id of a commit. Remember that you should run this command into the branch where the commit has been done.
$ git log

# Go to master branch
$ git checkout master

# Merge only one commit of a branch to master
# That strange string is the id of a commit 🙂
$ git cherry-pick 4fd534

There you go. Now you should see that commit in the master's log.

Just like with rebase, be carefull with this command and remember that you are changing the history.

Amending commits

Amend a commit, means that you commit a change to the very last commit that you did.

Let's say that you wrote lots of console.logs but forgot to erase them before the commit.

Ok, it's not a problem. Go back to the code, erase them and commit again:

# add changes
$ git add -A

# amend last commit
$ git commit --amend

Take a look at the log and you'll see only one commit.

Clone

Git has been made for teams.

If you want to get into a project that has already been started, you will need to clone it.

# Example with SSH
$ git clone git@github.com:user/repository.git

# Example with HTTPS
$ git clone https://github.com/user/repository.git

Note: you will find the link in GitHub, GitLab, Bitbucket or the service where the project is hosted.

Git reflog

There is a command that remembers everything. Even though you have used rebase, cherry pick or another of those commands that changes the history shown in git log; git rebase knows that you've done all of that crazy things.

$ git reflog

Search

Git allows us to search throughout our project with 2 commands.

For searching in the files: git grep.

For searching in commits: git log -S.

# Look for all p tags
$ git grep "<p>"

# Look for the commit where we change colors
$ git log -S "change colors"

Some interesting flags for grep command:

-n: returns the specific line where the word is.
-c: counts how many times was the word written.

Complete log

We've already talked about git log, but it is much more powerful than expected.

Let's see some flags:

--oneline: shows each result in one line. Useful to see more information in less space.
--all: shows the logs of all the references: branches, tags.
--graph: draws lines to illustrate the relationship of the different branches.
--decorate: a little bit of colors for the graph.

Now, let's put it all together.

$ git log --all --graph --decorate --oneline

Aliases

Git allows us to create an alias for a command.

If you know about linux aliases, it's the same idea.

$ git config --global alias.name "command"

# Example
$ git config --global alias.tree "log --all --graph --decorate --oneline"

# Trying it
$ git tree

Git is really big

You have now a really good understanding of git and how to use it. But Git is really big. I encourage you to read the docs to learn a lot more about it.

DEV Community: Maximo Martinez Soria

Not everything is an object in JavaScript

Primitive datatypes

Objects

Memory

Why you should create your own Webpack configuration for React and how to do it

Set Up

Babel for React

Development

Hot Module Replacement

Production

Dynamic Link Library

React code and Webpack Docs

Let's create a Webpack configuration from scratch

Setup

Getting into Webpack

Giving it a shot

Loaders and Plugins

Handle HTML

Babel for modern JavaScript

Styles

Images, videos and fonts

Development vs Production

Development

Development server

Production

Extracting styles

Cleaning

Minify CSS

The perfect configuration

HTTP Explained

Verbs

Status

Common Status Codes

Mastering Git

Table of Contents

Getting started

Installation

Configuration

First steps

Tracking code

Branches

Take a look at the changes

Go back to a previous version

Git WorkFlow

New features

Fix

Save the repository in an online server

Asymmetric encryption

Pulling and pushing code

Gitignore

Readme

Tags

Rebase

Stash

Removing files

Git cherry-pick

Amending commits

Clone

Git reflog

Search

Complete log

Aliases

Git is really big