DEV Community: Douglas Matoso

HTTP primer for frontend developers

Douglas Matoso — Sun, 27 Dec 2020 16:51:03 +0000

HTTP — Hypertext Transfer Protocol — is how client and server (frontend and backend) talk to each other. As frontend developers (and web developers in general) we should understand at least the basics of this communication, because an important part of our job is to send requests to the server and handle the responses.

Request and response

Basically the way that communication works is by exchanging messages. The client sends a request and the server sends back a response.

Anatomy of a request

An HTTP request is composed of the following parts:

Method

Also referred as verb, is the kind of action to be performed (GET information, POST information back to the server, etc). The most common are:

GET Retrieve information from the server. For example: a webpage, an image file.
POST Send data to the server. For example: a filled registration form.
PUT Send data to completely replace an existing resource.
PATCH Send data to apply partial modifications to a resource.
DELETE Delete the specific resource from the server.

URI

Uniform Resource Identifier — is the path on the server that identify the information (the resource to be fetched, created, modified).

Header

Additional information about the request and about the client, in the form of key-value pairs.

Body

Optional. The content the client sends to the server. GET and DELETE requests usually don’t need one. For POST, PUT and PATCH requests this is where the information to be created or modified is sent.

Anatomy of a response

An HTTP response is composed of the following parts:

Status

Indicates, by a numeric code, whether a request has been successfully completed. They are grouped in five classes, identified by the first digit. Some of the most used statuses are:

1xx — Information
2xx — Success 200 OK: The request was completed successfully.
3xx — Redirect 301 Moved Permanently: The resource is permanently located in a different URI. A new URI should be given in the response. 302 Found: The resource temporarily moved to a new location.
4xx — Client error 400 Bad Request: The request could not be understood by the server. 403 Forbidden: User not authorized to perform the requested operation. 404 Not Found: The requested resource could not be found at the given URI. 405 Method Not Allowed: The request method is not allowed on the specified resource.
5xx — Server error 500 Internal Server Error: The server encountered an unexpected condition, preventing it to fulfill the request. 503 Service Unavailable: The server is temporarily unavailable, usually due to overloading or maintenance.

For a more comprehensive list:
http://www.restapitutorial.com/httpstatuscodes.html

Header

Like the request header, this contains additional information about the server and about the response itself.

Body

Optional. This is the content returned by the server.

Practical examples: HTTP requests with JavaScript

See some examples of how to send HTTP requests on the frontend and how to handle responses.

Example #1: GET information about the latest React release on GitHub

// the request:
// GET information about the latest React release on GitHub
// we don't need to inform the method (GET is the default), 
//   headers or body (GET request doesn't need one)
fetch('https://api.github.com/repos/facebook/react/releases/latest') // the URI
  .then(response => {
    // we received the response and print the status code
    console.log(response.status)
    // return response body as JSON
    return response.json()
  })
  .then(json => {
    // print the JSON
    console.log(json)
  })

// on success will log:
// 200
// { ... contents of the response body as JSON ... }

Example #2: POST a new email to be associated to my GitHub account

// the request:
// POST a new email address to my GitHub account
fetch('https://api.github.com/user/emails', { // the URI
  method: 'POST', // the method
  body: JSON.stringify(["octocat@github.com"]) // the body
})
  .then(response => {
    // we received the response and print the status code
    console.log(response.status)
    // return response body as JSON
    return response.json()
  })
  .then(json => {
    // print the JSON
    console.log(json)
  })

// on success will log:
// 201
// { ... contents of the response body as JSON ... }

Example #3: Handling a failed request (status code different than 2xx)

// the request:
// try to GET an nonexistent URI
fetch('https://api.github.com/nonexistent-uri')
  .then(response => {
    if (response.ok) {
      // we should not reach here
      console.log('success')
    } else {
      console.log(response.status)
    }
  })

// will log:
// 404

Additional resources

Feedback? Suggestions?

How to Access Device Cameras with JavaScript (Front and Rear)

Douglas Matoso — Sat, 30 May 2020 12:57:38 +0000

Hey folks! In this post I will show you how to access the device’s cameras on a web page, via JavaScript, with support for multiple browsers and without the need for external libraries.

How to access the camera

To access the user’s camera (and/or microphone) we use the JavaScript MediaStream API. This API allows to access the video and audio captured by these devices through streams.

The first step is to check if the browser supports this API:

if (
  "mediaDevices" in navigator &&
  "getUserMedia" in navigator.mediaDevices
) {
  // ok, browser supports it
}

Support is decent in modern browsers (no Internet Explorer, of course).

Capturing the video stream

To capture the video stream generated by the camera, we use the getUserMedia method of the mediaDevices object.

This method receives an object with the types of media we are requesting (video or audio) and some requirements. To start, we can just pass {video: true} to get the video from the camera.

const videoStream = await navigator.mediaDevices.getUserMedia({ video: true });

This call will ask the user for permission to access the camera. If the user denies it, it throws an exception and does not return the stream. So it must be done inside a try/catch block to handle this case.

Note that it returns a Promise, so you have to use async/await or a then block.

Video requirements

We can improve the requirements of the video by passing information about the desired resolution and minimum and maximum limits:

const constraints = {
  video: {
    width: {
      min: 1280,
      ideal: 1920,
      max: 2560,
    },
    height: {
      min: 720,
      ideal: 1080,
      max: 1440,
    },
  },
};

const videoStream = await navigator.mediaDevices.getUserMedia(constraints);

That way the stream comes in the correct proportion of width and height. If it is a cell phone in portrait mode it takes care of inverting the dimensions.

Displaying the video on the page

Okay, now that we have the stream, what can we do with it?

We can display the video on the page, in a video element:

// considering there is a
// <video autoplay id="video"></video> 
// tag in the page
const video = document.querySelector("#video");
const videoStream = await navigator.mediaDevices.getUserMedia(constraints);
video.srcObject = videoStream;

Note the autoplay attribute in the video tag. Without it, you need to call video.play() to actually start displaying the image.

Accessing the phone’s front and rear cameras

By default getUserMedia will use the system’s default video recording device. In the case of a cell phone with two cameras, it uses the front camera.

To access the rear camera, we must include facingMode: "environment" in the video requirements:

const constraints = {
  video: {
    width: { ... },
    height: { ... },
    facingMode: "environment"
  },
};

The default is facingMode: "user", which is the front camera.

Be aware that, if you want to change the camera with the video already playing, you will need to stop the current stream before replacing it with the stream from the other camera:

videoStream.getTracks().forEach((track) => {
  track.stop();
});

Taking screenshots

Another cool thing you can do is capture images (screenshots) of the video.

You can draw the current video frame on a canvas, for example:

// considering there is a
// <canvas id="canvas"></canvas>
// tag in the page
const canvas = document.querySelector("#canvas");
canvas.width = video.videoWidth;
canvas.height = video.videoHeight;
canvas.getContext("2d").drawImage(video, 0, 0);

You can also display the canvas content in an img element.

In the example I created for this tutorial, I added a button that creates images dynamically from the canvas and adds them to the page. Something like:

const img = document.createElement("img");
img.src = canvas.toDataURL("image/png");
screenshotsContainer.prepend(img);

Conclusion

See the running example here: https://doug2k1.github.io/javascript-camera/

And the complete source code is here: https://github.com/doug2k1/javascript-camera

React: Forms and Validations with React Hook Form

Douglas Matoso — Sun, 10 May 2020 20:44:56 +0000

Hey, folks! In this post I will show you how to work with forms and validation in React, in a simple and efficient way, using the React Hook Form library.

React Hook Form x Formik x Redux Form

React Hook Form brought some improvements over other form manipulation libraries in React, such as Formik and Redux Form.

Among these points are built-in validation (with other libs you need to do the validation manually or install one more lib for that), performance (it makes less renders than other libs when changing fields) and ease of use (with the React Hook Form you need to write less code and the learning curve is shorter).

And the two cherries on top the cake: it works with React Native, with few changes, and for those who use TypeScript, it already comes with its own type definitions.

Example: Login Form

Let’s see in practice how to work with React Hook Form by building a login form.

To start, let’s create a pretty basic LoginForm component, with the email and password fields:

import React from "react";
import "./LoginForm.css";

const LoginForm = () => {
  return (
    <div className="login-form">
      <form>
        <label htmlFor="inputEmail">E-mail</label>
        <input
          type="email"
          id="inputEmail"
          name="email"
          ref={register({ required: true })}
        />

        <label htmlFor="inputPassword">Password</label>
        <input
          type="password"
          id="inputPassword"
          name="password"
          ref={register({ required: true })}
        />

        <button type="submit">Login</button>
      </form>
    </div>
  );
};

export default LoginForm;

Now we need to install React Hook Form:

npm i react-hook-form

And import the useForm hook in our component:

import { useForm } from "react-hook-form";

From the properties the hook returns, we will need handleSubmit, register and errors:

const { register, handleSubmit, errors } = useForm();

Registering fields

The first property, register, is a function that registers fields. You need to register each field that you want to be managed by the React Hook Form, through the field’s prop ref:

<input name="email" ref={register()} />

Getting form data on submit

The next property, handleSubmit, it’s used to handle the form submission and get the filled data.

const LoginForm = () => {
  const { register, handleSubmit, errors } = useForm();

  function onSubmit(data) {
    console.log("Data submitted: ", data);
  }

  return (
    <form onSubmit={handleSubmit(onSubmit)}>
      //... campos do formulário
    </form>
  );
}

Our onSubmit function will receive an object with the form’s data, that we can send to some backend api or do whatever we want with it.

Validating and showing errors

To add field validation, we need to pass some parameters to the register function, informing the validation rules and error messages, in case the validation does not pass.

See how our email field looks:

<input
  type="email"
  name="email"
  ref={register({
    required: "Enter your e-mail",
    pattern: {
      value: /^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i,
      message: "Enter a valid e-mail address",
    },
   })}
 />

We have two validations: required field (required) and a regular expression (pattern) to validate that the email is in the right format.

With that, the React Hook Form will prevent the form from being sent if any field fails validation.

To display the error messages to the user, we will use the other hook property: errors:

<input
  type="email"
  name="email"
  ref={register({
    required: "Enter your e-mail",
    pattern: {
      value: /^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i,
      message: "Enter a valid e-mail address",
    },
   })}
 />

{errors.email && <p className="error">{errors.email.message}</p>}

The errors property will be automatically filled in with the field errors, which we can use to show a message below each invalid field. We could also use it to change some CSS class and change the style of the error fields (add a red border, some icon, etc.).

Conclusion

The complete code for this example is in GitHub: https://github.com/doug2k1/react-login-form

You can see the form in action below:

https://www.webdevdrops.com/wp-content/uploads/2020/05/demo-react-login-form.mp4

Node.js with TypeScript

Douglas Matoso — Sun, 03 May 2020 19:27:40 +0000

Hey, folks! In this post I will show you how you can develop in Node.js using TypeScript and have the benefits of this language also in the backend.

ts-node-dev

To transpile TypeScript code to JavaScript, we will use ts-node-dev.

It provides an executable that we will use instead of Node to run TypeScript code. Behind the scenes it will transform TypeScript into JavaScript and execute it using Node itself.

Another nice thing about ts-node-dev is that it also replaces nodemon, so whenever we change a .ts file it will reload the application to reflect the changes.

Setup

We will need ts-node-dev and the typescript itself as development dependencies:

npm i -D ts-node-dev typescript

We will also need a config file for the TypeScript compiler. We can generate a default configuration with the command:

npx tsc --init

It will create a tsconfig.json at the root of the application. You can customize the options, but the default will work for us.

Writing the code

With this setup we can now write the application code using .ts files and all TypeScript functionality.

As an example, let’s create a “Hello World” with Express.js.

We will need to install express itself, and also the type definitions for it. Note that express is an application dependency, while type definitions are development dependencies.

npm i express

npm i -D @types/express

Some libraries already provide their own type definitions, so this second installation is not necessary. You will find out if a lib needs it when you try to import it into the code and the editor complains that the type definitions are missing.

For our “Hello, World” I will write this code in an index.ts file:

import express, { json } from "express";

const app = express();
app.use(json());

app.get("/", (request, response) => {
  return response.json({ message: "Hello, TypeScript!" });
});

app.listen(3000, () => {
  console.log("🚀 Server started on http://localhost:3000");
});

Note that we can use ES Modules (import … from …).

Running the application

To run the application, let’s add this start script, in package.json:

"start": "ts-node-dev --transpileOnly --ignore-watch node_modules index.ts"

I’ve added some options to make the transpilation process quicker:

--transpileOnly will tell it to just transpile, without doing type checking. This checking can be done in the editor, pointing the errors directly in our code.

--ignore-watch node_modules is saying to ignore node_modules files, as we are not going to tamper with these files and hope they are already in JavaScript.

Production

In production, as we want maximum performance, we will use Node directly with the code transpiled in JavaScript. For that we can add a build script:

"build": "tsc"

It will use the TypeScript compiler to transpile all the .ts code and save the corresponding .js files to disk.

Concluding

The final code for this example is here: https://github.com/doug2k1/node-typescript

TypeScript has many advantages, and the integration with other tools is becoming more mature every day. It is easier to adopt, either on the frontend or backend, and is an interesting option for most projects.

Git on Windows and GitHub: How to Install and Configure

Douglas Matoso — Fri, 03 Apr 2020 12:58:14 +0000

In this post I will make a simple tutorial on how to use Git on Windows and commit your code to GitHub.

1) Install Git on Windows

On the official Git website (http://git-scm.com/) click on “ Downloads for Windows ”.

Run the downloaded file and go “ Next ” to the “ Select Components ” screen. In this screen I choose the options as in the image:

In particular I check the options under “ Windows Explorer integration ”, so I can open the Git command prompt (Git Bash) in any folder, just right click and “ Git Bash Here ”. The last option is also interesting, because it installs a better font for the command prompt.

Note : Git for Windows comes with its own command prompt (Git Bash), which in addition to git commands also provides some Unix commands that can be quite useful (in addition to being much nicer than the standard Windows command prompt) .

On the next screen, I choose the option: “ Use Git from the Windows Command Prompt “.

This option allows you to use the git command both in Git Bash and in the standard Windows terminal.

The third option adds Unix commands to the Windows terminal, in addition to the git command itself, but some Windows commands will be replaced by Unix commands that have the same name (such as find and sort).

Another important configuration: line endings.

As you may know Windows and Unix systems (Linux, Mac) have different line breaks in text files. If you write code with line breaks in Windows format, someone else may have problems opening the same file on Linux, and vice versa. This option allows you to normalize this.

The first option converts files to Windows standard when you pull the files, and converts them to Unix format when you commit them to the repository. The second option does not do any conversion when the files arrive, but converts to Unix format when you commit. The third option does not convert at all.

I choose the second one, because I prefer to keep everything in the Unix format (since any good code editor can read files in the Unix standard even if they are on Windows).

That done, “ Next “, “ Finish ” and Git is installed.

2) Create a local Git repository and commit your first changes

Let’s test it? Create a folder on your computer, right click it and “ Git Bash Here ”.

First of all, inform Git your name and e-mail, which will identify your commits. Enter the commands:

git config --global user.name "Your Name"   
git config --global user.email "your_email@email.com"

Tip : to copy and paste commands in Git Bash, right click on the terminal screen.

Now we are going to initialize a Git repository in this folder we are in.

git init

Did you see this (master) text that appeared on the command line? It indicates that you are in a Git repository, on the master branch. Nice, huh?

Let’s add an empty file to this repository and commit it. See the sequence of commands:

touch test.txt   
git add .   
git commit -m "First commit"

First we create an empty test.txt file. Then we add all the new files (in this case, just test.txt) to the index of the repository, and finally we commit all the files that are in the index and have been modified.

3) Push to GitHub

Cool, you have a Git repository on your machine, but how about sharing your codes on GitHub and enjoying all that this community has to offer?

3.1) Initial preparation

Go to https://github.com/ and click on “ Sign Up ” to create your free account.

Having registered and logged into your account, you now need an SSH key to start committing. In Git Bash type:

ssh-keygen -t rsa -C "your_email@email.com"

Enter your e-mail address registered on GitHub. Hit Enter on the next question (about the file to be created – let’s leave the defaults).

The next question will ask you for a passphrase. Create a password and enter it. He will ask for confirmation. Type the password again and Enter. Type now:

notepad ~/.ssh/id_rsa.pub

to open the file that was created in Notepad.

Now on GitHub , go to “ Settings ” and then “ SSH and GPG Keys “. Click “ New SSH key ”. Enter a title to identify the computer where the key was generated and in the “ Key ” field, paste all the contents of the file id_rsa.pub (which you opened in Notepad)

Be careful to copy and paste the entire contents of the file, starting with “ssh-rsa…” and including your email (as in the image). Click on “ Add Key “.

Let’s test to see if it worked. In Git Bash type:

ssh -T git@github.com

It will ask if you are sure you want to connect (yes / no). Type yes and Enter. In the next question (Enter passphrase …) enter your password (the one you chose when creating the SSH key).

If you receive a message like:

Hi doug2k1! You’ve successfully authenticated, but GitHub does not provide shell access.

So everything worked out!

3.2) Create the remote repository

On GitHub we will create a new repository (“ New Repository ” button on your dashboard). Enter a name without spaces and special characters. The other options do not need to change.

You will be taken to the page of your repository, which has no files yet.

Important! If the email informed to Git at the beginning of step 2 is not the one used to register with GitHub , redo the command informing the registered email. That way, GitHub will be able to link the commits to your account.

In Git Bash (in your local repository folder) type:

git remote add origin git@github.com:login/repository.git

Note that login / repository must be entered as it appears in the URL of your repository, in the example:

https://github.com/doug2k1/projeto-tutorial

Now to update GitHub with the contents in your local repository, type:

git push -u origin master

Enter your password (for the SSH key) when prompted.

Reload your repository page and now, instead of the initial message, you will see your commits and files.

4) Conclusion

Even though Git originated on Linux (Did you know that Linus Torvalds created it?), Windows users can also benefit from it, thanks to Git for Windows. In addition to Git itself being an excellent version control system, the open-source community that populates GitHub is vibrant. It’s rewarding as finding a code that “saves your skin” and also being able to contribute to a project, make forks, share.

See you next!

Links

The post Git on Windows and GitHub: How to Install and Configure first appeared in Web Dev Drops.

Build a static site generator in 40 lines with Node.js

Douglas Matoso — Thu, 02 Apr 2020 18:30:17 +0000

There are excellent static site generators out there, in different languages, with lots of features, but actually building your own is easier than you might think, and we learn some things in the process.

Why build your own?

When I was planning to build my own personal website — a simple portfolio-like site, with few pages, with some info about myself, my skills and projects — I decided it should be static (it’s fast, no need to setup a backend and can be hosted anywhere). I had some experience with Jekyll, Hugo and Hexo, but I think they have too many features for my simple project. So I thought it shouldn’t be that hard to build something small, with just the features I need.

The requirements

The requirements this generator must satisfy are:

Generate HTML files from EJS templates
Have a layout file, so all pages have the same header, footer, navigation, etc.
Allow partials (blocks of reusable interface components)
Read global site config from a file (site title, description, etc.)
Read data from JSON files. For example: list of projects, so I can easily iterate and build the “Projects” page

Why EJS templates?
Because EJS is simple. There is no new template language to learn. It’s just JavaScript embedded in HTML.

Folder structure

public/  
 src/  
   assets/  
   data/  
   pages/  
   partials/  
   layout.ejs  
 site.config.js

public: where the generated site will be.
src: the source of the site contents. src/assets: contains CSS, JS, images, etc. src/data: contains JSON data. src/pages: are the templates that will be rendered to HTML. The directory structure found here will be replicated in the resulting site. src/partials: contains our reusable partials. src/layout.ejs: contains the common page structure, with a special placeholder, where the contents of each page will be inserted.
site.config.js: it just exports an object that will be available in the page templates.

The generator

The generator code is inside a single file, scripts/build.js, that we can run with npm run build, every time we want to rebuild the site, by adding the following script to our package.jsonscripts block:

"build": "node ./scripts/build"

This is the complete generator:
(Below I explain each part of the code.)

const fse = require('fs-extra')
const path = require('path')
const { promisify } = require('util')
const ejsRenderFile = promisify(require('ejs').renderFile)
const globP = promisify(require('glob'))
const config = require('../site.config')

const srcPath = './src'
const distPath = './public'

// clear destination folder
fse.emptyDirSync(distPath)

// copy assets folder
fse.copy(`${srcPath}/assets`, `${distPath}/assets`)

// read page templates
globP('**/*.ejs', { cwd: `${srcPath}/pages` })
  .then((files) => {
    files.forEach((file) => {
      const fileData = path.parse(file)
      const destPath = path.join(distPath, fileData.dir)

      // create destination directory
      fse.mkdirs(destPath)
        .then(() => {
          // render page
          return ejsRenderFile(`${srcPath}/pages/${file}`, Object.assign({}, config))
        })
        .then((pageContents) => {
          // render layout with page contents
          return ejsRenderFile(`${srcPath}/layout.ejs`, Object.assign({}, config, { body: pageContents }))
        })
        .then((layoutContent) => {
          // save the html file
          fse.writeFile(`${destPath}/${fileData.name}.html`, layoutContent)
        })
        .catch((err) => { console.error(err) })
    })
  })
  .catch((err) => { console.error(err) })

Dependencies

For this basic feature set we only need three dependencies:

ejs Compile our templates to HTML.
fs-extra Adds new functions to Node’s native file-system module (fs) and add promise support for the existing ones.
glob Recursively read a directory, returning an array with all files that match an specified pattern.

Promisify all the things!

One thing to note in our code is that we use Node’s util.promisify function to convert all callback-based functions to promise-based. It makes our code shorter, cleaner and easier to read.

const { promisify } = require('util')  
const ejsRenderFile = promisify(require('ejs').renderFile)  
const globP = promisify(require('glob'))

Load the config

At the top we load the site config file, to later inject it in the templates rendering.

const config = require('../site.config')

The site config file itself load the additional JSON data, for example:

const projects = require('./src/data/projects')

module.exports = {  
  site: {  
    title: 'NanoGen',  
    description: 'Micro Static Site Generator in Node.js',  
    projects  
  }  
}

Empty the public folder

We use emptyDirSync from fs-extra to empty the public folder.

fse.emptyDirSync(distPath)

Copy assets

Here we use the copy method from fs-extra, that recursively copy a folder with contents.

fse.copy(`${srcPath}/assets`, `${distPath}/assets`)

Compile the pages templates

First we use glob (our promisified version) to recursively read the src/pages folder looking for .ejs files. It will return an array with the paths of found files.

globP('**/*.ejs', { cwd: `${srcPath}/pages` })  
  .then((files) => {

For each template file found we use the Node’s path.parse function to separate the components of the file path (like dir, name and extension). Then we create a corresponding folder in the public directory with fs-extra mkdirs.

files.forEach((file) => {  
  const fileData = path.parse(file)  
  const destPath = path.join(distPath, fileData.dir)

 // create destination directory  
  fse.mkdirs(destPath)

We then use EJS to compile the file, passing the config data. Since we are using a promisified version of ejs.renderFile, we can return the call and handle the result in the next promise chain.

.then(() => {  
  // render page  
  return ejsRenderFile(`${srcPath}/pages/${file}`, Object.assign({}, config))  
})

In the next then block we have the compiled page template. Now we compile the layout file, passing the page contents as a body attribute.

.then((pageContents) => {  
  // render layout with page contents  
  return ejsRenderFile(`${srcPath}/layout.ejs`, Object.assign({}, config, { body: pageContents }))  
})

Finally we take the resulting compiled string (HTML of layout + page contents) and save to an HTML file, with the same path and name of the template.

.then((layoutContent) => {  
  // save the html file  
  fse.writeFile(`${destPath}/${fileData.name}.html`, layoutContent)  
})

Development server

To make it easier to view the results, we add a simple development server, like the serve module and the the following to our package.jsonscripts block:

"serve": "serve ./public"

Then run npm run serve and go to http://localhost:5000

Result

The complete example at this stage can be found here: https://github.com/doug2k1/nanogen/tree/legacy

Edit: after some time I decided to turn the project into a CLI module, to make it easier to use, which is in themaster branch of the repository. The original code created at the end of this post is in thelegacy branch (link above).

Bonus Feature 1: Markdown and front matter

Most static site generators allow writing content in Markdown format. Also, most of them allow adding some metadata on top of each page (aka front matter) in the YAML format, like this:

---  
title: Hello World  
date: 2013/7/13 20:46:25  
---

With a few changes we could add the same features to our micro generator.

New dependencies

We must add two more dependencies:

marked Compile Markdown to HTML.
front-matter Extract meta data (front matter) from documents.

Include the new file types

We change the glob pattern to include .md files. We leave .ejs, to allow for more complex pages that could not be possible with Markdown, and we also include .html, in case we want to include some pure HTML pages.

globP('**/*.@(md|ejs|html)', { cwd: `${srcPath}/pages` })

Extract front matter

Then, for each file path we have to actually load the file contents, so front-matter can extract the meta data at the top.

.then(() => {  
  // read page file  
  return fse.readFile(`${srcPath}/pages/${file}`, 'utf-8')  
})

We pass the loaded contents to front-matter. It will return and object with the meta data in the attributes property and the rest of the content in the body property. We then augment the site config with this data.

.then((data) => {  
  // extract front matter  
  const pageData = frontMatter(data)  
  const templateConfig = Object.assign({}, config, { page: pageData.attributes })

Compile files to HTML

Now we compile the page content to HTML depending on the file extension. If is .md, we send to marked, if .ejs we continue to use EJS, else (is .html) there is no need to compile.

let pageContent  

switch (fileData.ext) {  
  case '.md':  
    pageContent = marked(pageData.body)  
    break  
  case '.ejs':  
    pageContent = ejs.render(pageData.body, templateConfig)  
    break  
  default:  
    pageContent = pageData.body  
}

Finally, we render the layout, as before, sending the compiled page contents as body.

One nice thing with front matter is that now we can set individual titles for each page, like this:

---  
title: Another Page  
---

And have the layout dynamically render them like this:

<title><%= page.title ? `${page.title} | ` : '' %><%= site.title %></title>

Each page will have a unique <title> tag.

Bonus Feature 2: Multiple layouts

Another interesting feature is the ability to use a different layout in specific pages. Since our pages now can have front matter, we may use it to set a different layout than the default:

---  
layout: minimal  
---

Separate the layout files

We need to have separate layout files. I’ve put them in the src/layouts folder:

src/layouts/  
   default.ejs  
   mininal.ejs

Render the correct layout

If the front matter layout attribute is present, we render the layout file with the same name in the layouts folder. If it is not set, we render the default.

const layout = pageData.attributes.layout || 'default'

return ejsRenderFile(`${srcPath}/layouts/${layout}.ejs`, 
  Object.assign({}, templateConfig, { body: pageContent })
)

Result

The complete code, with the extra features, can be found here: https://github.com/doug2k1/nanogen

Even with the added features, the build script has about 60 lines. 😉

Next Steps

If you want to go even further, some additional features that shouldn’t be difficult to add:

Dev server with live reloading You may use modules like live-server (has auto reload built in) and chokidar (watch for file modifications to automatically trigger the build script).
Automatic deploys Add scripts to deploy the site to common hosting services like GitHub Pages, or simply copy the files to your own server via SSH (with commands like scp or rsync)
Support for CSS/JS preprocessors Add some preprocessing to your assets files (SASS to CSS, ES6 to ES5, etc) before copying to the public folder.
Better console output Add some console.log calls to better indicate what is going on. You could use a module like chalk to make it even prettier.

Feedback? Suggestions? Feel free to comment or contact me!

The post Build a static site generator in 40 lines with Node.js first appeared in Web Dev Drops.

Webpack sem Medo — Parte 1: Introdução

Douglas Matoso — Thu, 02 Apr 2020 18:28:58 +0000

Esta série tem o objetivo de apresentar as funcionalidades do webpack de forma gradativa, explicando conceitos e mostrando exemplos.

Por que “sem medo”?
Conheço algumas pessoas (incluindo eu mesmo) que tiveram um primeiro contato com webpack, não entenderam direito como usar, ficaram mais confusas ainda lendo a documentação e criaram uma aversão à ferramenta.
Muitas dessas pessoas tiveram contato com a versão 1 do webpack, que tinha uma configuração mais confusa e uma documentação menos organizada.
A boa notícia é que a partir da versão 2 isso mudou radicalmente. A configuração ficou mais fácil de compreender, e a documentação foi completamente reescrita, com excelentes guias, explicações claras e completas.
Se tinha medo do webpack, a hora de perder o medo é essa!

Mas o que é webpack?

webpack é um module bundler (empacotador de módulos) para JavaScript, em outras palavras, ele junta os arquivos JS (e também outros formatos) da sua aplicação (seja arquivos seus ou dependências externas) em um arquivo só (ou mais de um), de forma otimizada. Os arquivos são unificados na ordem certa, sem duplicação e podem ser minificados para reduzir o tamanho.

Um ponto forte do webpack que ele é altamente configurável e extensível através de plugins. Isso permite fazer algumas coisas interessantes como:

Utilizar outros sabores de JS, como ES6+, TypeScript, JSX e fazer a transpilação (conversão para ES5) automaticamente no processo de empacotamento.
Tratar e empacotar outros tipos de arquivos, como CSS (e variações como SASS, LESS, Stylus), SVG, imagens, arquivos de templates (Pug, Handlebars).
E muito mais, como veremos mais pra frente…

Grafo de dependências

Como o webpack sabe quais arquivos incluir e em qual ordem? Ele monta um grafo de dependências, que é uma estrutura mais ou menos assim:

Partindo de um arquivo inicial (entrada), ele verifica quais outros arquivos são importados por este, e os adiciona ao grafo. Para cada um desses ele também verifica quais eles importam, assim sucessivamente até que o grafo contenha todos os arquivos (módulos) necessários para a aplicação.

Módulos

Para indicar que um arquivo JS depende de outro, ele precisa importá-lo. Ex.:

import React from 'react'
import utils from './utils'

No exemplo acima ele importa uma dependência externa (React) e uma interna (o caminho começa com ./). Note também que não é necessário informar a extensão do arquivo se for JS.

O arquivo que vai ser importado, em contrapartida, precisa indicar o que ele exporta. Ex.:

const utils = { ... }  
export default utils

Cada arquivo desses, que exporta algum dado ou funcionalidade, é chamado de módulo.

Dividir sua aplicação em módulos é uma boa prática, pelos seguintes benefícios:

Manutenibilidade: as funcionalidades ficam menos acopladas, é mais fácil alterar uma parte do código sem afetar o sistema inteiro.
Isolamento: variáveis e funções declaradas dentro de um módulo são acessíveis apenas dentro dele (exceto aquilo que o módulo explicitamente exporta), evitando conflitos de variáveis e acesso desnecessário de uma parte do código a outra não relacionada.
Reusabilidade: um módulo com uma funcionalidade bem definida, é como uma peça de lego, pode ser reutilizada em outras partes do mesmo sistema, ou em outros sistemas.
Testabilidade: com o código menos acoplado, fica mais fácil escrever testes unitários para validar cada funcionalidade.

A forma de fazer import/export mostrada acima usa o padrão ES Modules, que é o adotado a partir do ES6 nos navegadores. O Node.js atualmente usa o padrão CommonJS, que muda um pouco a sintaxe:

const express = require('express')  
const utils = require('./utils')

module.exports = ...

Ambas as sintaxes são suportadas pelo webpack, mas aqui vamos usar ES Modules, que é o padrão no navegador, e está caminhando para se tornar o padrão no Node.js (veja referência [8]).

Leitura importante
Recomendo se familiarizar com a sintaxe do ES Modules, e as diferentes formas de import/export. Veja referências [5], [6] e [7] ao final do artigo.

Os 4 conceitos fundamentais do webpack

Antes de começar a colocar a mão na massa é importante compreender os 4 *core concepts* do webpack: entry, output, loaders e plugins. Tendo estes conceitos em mente fica mais fácil entender como o webpack trabalha.

Nesta primeira parte vamos ver apenas os dois primeiros, que já serão suficientes para os primeiros exemplos. Veremos os outros quando forem necessários.

Entry (entrada)

Lembra que eu falei lá em cima sobre o grafo de dependências, e que para montá-lo o webpack parte de um arquivo inicial e vai seguindo os imports? Pois é, este arquivo inicial é o entry point (ponto de entrada) da aplicação.

Veremos que toda configuração de webpack possui pelo menos um entry point. Pode ter mais de um (nesse caso serão gerados mais de um grafo de dependências), mas vamos ver esses casos mais avançados em outro momento.

Output (saída)

Uma vez montado o grafo de dependências, o webpack precisa saber onde ele vai salvar o arquivo unificado, ou vários arquivos, dependendo da configuração.

Exemplo 1: Minificação de JS

Vamos ver na prática o exemplo mais básico de um setup de webpack, com apenas uma entrada e uma saída. Vamos pegar uma aplicação divida em arquivos JS (módulos) e gerar um arquivo único.

Este exemplo completo pode ser encontrado aqui: https://github.com/doug2k1/webpack-scenarios/tree/master/1-basic

Pré-requisitos

Possuir Node.js instalado (de preferência uma versão recente)
Conhecimento básico de terminal/linha de comando (saber navegar entre pastas e executar comandos simples)

Instalação

Inicializar o arquivo package.json para gerenciar dependências, caso sua aplicação ainda não possua. Rode no terminal, na raiz da aplicação:

npm init -y

Instalar o webpack e o webpack-cli (que é o utilitário de linha de comando do webpack):

npm i -D webpack webpack-cli

Usamos -D para salvar o webpack nas dependências de desenvolvimento (devDependencies), já que ele só vai ser usado durante o desenvolvimento. Serão criadas as entradas abaixo no package.json (a versão pode ser diferente, dependendo de qual versão é a mais recente quando você executar o comando):

"devDependencies": {  
  "webpack": "^4.20.2",  
  "webpack-cli": "^3.1.2"  
}

A estrutura de pastas vai ficar assim:

|-- node_modules  
|-- package.json  
|-- package-lock.json

Explicando: node_modules é a pasta que guarda todos os arquivos baixados das dependências instaladas, package.json é onde listamos as dependências e versões (entre outras informações da aplicação) e package-lock.json é um arquivo que “trava” as versões das dependências. Quando outros desenvolvedores executarem npm i para baixar as dependências, este arquivo garante que serão instaladas as mesmas versões para todo mundo.

Zero Config

Vou mostrar daqui a pouco como configurar o webpack usando um arquivo de configuração, mas para este exemplo simples você nem vai precisar deste arquivo.

Arquivos da aplicação

Por enquanto o projeto ainda não tem nenhum arquivo da aplicação em si. Uma prática comum é colocar o código-fonte da aplicação em uma pasta src. Primeiro vamos criar um index.js nesta pasta como nosso ponto de entrada:

|-- src  
  |-- index.js

Com o conteúdo:

import cow from './cow'  

document.querySelector('#box').innerText = cow.say('Webpack is great!')

Este arquivo importa outro arquivo que está na mesma pasta, o cow.js (./ significa “mesma pasta do arquivo atual”). Vamos agora criar este outro arquivo:

|-- src  
  |-- index.js  
  |-- cow.js

Com o conteúdo:

import cowsay from 'cowsay-browser'

export default {  
  say: function (str) {  
    return cowsay.say({ text: str })  
  }  
}

Veja que este arquivo já importa uma dependência externa (nome da dependência, sem ./). Precisamos usar o NPM para instalá-la:

npm i -S cowsay-browser

Aqui usamos -S para salvar a dependência no package.json como dependência normal, isto é, que será usada pela aplicação final. Vai ser adicionada esta entrada:

"dependencies": {  
  "cowsay-browser": "^1.1.8"  
}

Arquivo HTML

Para ver o resultado no navegador, vamos precisar de um arquivo HTML. Vamos criar então um index.html na raiz da aplicação, com este conteúdo:

<!doctype html>  
<html>  
<head>  
  <title>Webpack</title>  
</head>  
<body>  
  <pre id="box">  
  <script src="dist/main.js"></script>  
</body>  
</html>

Veja que carrega um arquivo dist/main.js que ainda não temos. Este é o arquivo que o webpack vai gerar a partir de nossos fontes.

Configurando o webpack

Por default, o webpack considera como ponto de entrada (entry point) o arquivo src/index.js e como arquivo de saída (output) dist/main.js. Por isto este primeiro exemplo não precisa de um arquivo de configuração.

Mas, se quiséssemos alterar o entry point ou o output, poderíamos criar um arquivo webpack.config.js na raiz da aplicação com o conteúdo:

const path = require('path')

module.exports = {  
  entry: './src/index.js',

  output: {  
    path: path.resolve('dist'),  
    filename: 'main.js'  
  }  
}

Veja que este arquivo é um módulo, que exporta um objeto. Aqui devemos usar o padrão CommonJS, pois este arquivo vai executar no Node.js, quando o webpack for acionado.

O primeiro item, entry, é o nosso ponto de entrada.

O segundo, output, é onde o webpack vai salvar o bundle gerado. Esta configuração pede o caminho da pasta (path) e o nome do arquivo (filename) separados. O caminho da pasta deve ser absoluto, por isso usamos a função path.resolve do Node para gerar um caminho absoluto a partir de um relativo.

Gerando o bundle (Fazendo a magia acontecer)

Agora que o circo está montado, vamos gerar esse tal main.js! Para isso, vamos adicionar uma entrada no nosso package.json:

"scripts": {  
  "build": "webpack"  
}

Com isso, basta executar no terminal:

npm run build

Este comando irá executar o webpack (através do webpack-cli), que vai percorrer o grafo de dependências, partindo do entry point, e gerar o main.js, que contém todo o código da aplicação e das dependências.

Você pode abrir o index.html no navegador e ver o resultado.

Modos: desenvolvimento e produção

Se você olhar o arquivo main.js gerado vai ver que ele está minificado (sem identação e quebras de linhas, com os nomes de variáveis alterados e com tamanho bem menor que os arquivos originais). Isso acontece porque o webpack, por padrão, roda em modo produção (production).

O modo production faz duas coisas por baixo dos panos:

Ativa o plugin UglifyJS para minificar o bundle. O UglifyJS faz uma minificação agressiva. Além de remover espaços, quebras de linha e comentários, ele renomeia variáveis e faz transformações no código para deixar o mais curto possível.
Seta a variável process.env.NODE_ENV="production". Algumas bibliotecas olham esta variável, e se estiver com o valor “production” ativam algumas otimizações para produção.

O outro modo, desenvolvimento (development), não minifica o código, mas ele roda mais rápido. Ideal (como o nome diz) para usar enquanto ainda está desenvolvendo o código.

Para escolher o modo, basta passar a opção --mode para o webpack-cli:

webpack --mode development

Opção watch

Legal, mas toda vez que alterar um JS vou precisar rodar este comando manualmente?

Não, jovem! Para isso tem a opção watch, onde o webpack vai ficar monitorando os arquivos e a cada alteração ele vai reconstruir o arquivo final.

Para isso basta passar a flag -w para o cli:

webpack -w

Com isso, para deixar o workflow mais versátil você pode definir dois scripts no package.json:

"scripts": {  
  "build:watch": "webpack -w --mode development",  
  "build:prod": "webpack --mode production"  
},

Assim, durante o desenvolvimento você usa npm run build:watch para rodar em modo development com a opção watch, e para mandar o código para produção você usa npm run build:prod.

O que vem pela frente

Nos próximos artigos da série vamos falar de loaders, para tratar outros formatos de arquivos, plugins, para realizar diferentes tarefas e apresentar cenários mais avançados.

Feedbacks?

Qualquer crítica ou sugestão, comente ou entre em contato.

Referências

[1] https://webpack.js.org/ — Site oficial do webpack (inglês). Toda a documentação, com excelentes guias. Sua melhor referência, se não tiver problemas com inglês.
[2] https://www.udemy.com/webpack-2-the-complete-developers-guide/learn/v4/overview — Curso de webpack (inglês) na Udemy, com o excelente instrutor Stephen Grider. Geralmente rola promoção e este curso sai por R$20 ou R$30.
[3] https://coderweb.com.br/webpack-e-complexo-mas-so-um-pouquinho/ — Artigo do Coder Web sobre webpack (offline).
[4] https://willianjusten.com.br/configurando-o-webpack-para-rodar-react-e-es6/ — Artigo do Willian Justen sobre webpack com React e ES6.
[5] http://exploringjs.com/es6/ch_modules.html — Capítulo sobre ES Modules do livro Exploring ES6 (inglês)
[6] https://developer.mozilla.org/pt-BR/docs/Web/JavaScript/Reference/Statements/import — Referência na MDN sobre import.
[7] https://developer.mozilla.org/pt-BR/docs/Web/JavaScript/Reference/Statements/export — Referência na MDN sobre export.
[8] https://blogs.windows.com/msedgedev/2017/08/10/es-modules-node-today/ — Post sobre o uso de ES Modules no Node.js (inglês)

5 Ferramentas de Produtividade Essenciais no Desenvolvimento Web

Douglas Matoso — Thu, 02 Apr 2020 02:07:08 +0000

Neste post vou mostrar 5 ferramentas essenciais para aumentar sua produtividade no desenvolvimento web e programação em geral.

1. Emmet

O Emmet acelera a escrita de HTML e CSS (também funciona com outros formatos como JSX e SASS ) através de abreviações no editor.

HTML

No HTML , por exemplo, se você digita o nome de uma tag e aperta Tab ou Enter, ele completa a tag, com abertura fechamento e atributos. Inclusive colocando o cursor nos pontos de edição.

p → <p></p>
a → <a href=""></a>

Você também pode usar seletores CSS para criar blocos maiores.

#conteudo>ul.links>li*3

↓

<div id="conteudo">
  <ul class="links">
    <li></li>
    <li></li>
    <li></li>
  </ul>
</div>

Outro exemplo, com pseudo seletores:

form>input:text+input:submit

↓

<form action="">
  <input type="text" name="" id="">
  <input type="submit" value="">
</form>

E o mais legal é este: para criar toda a estrutura inicial de um documento HTML, basta usar !. Veja:

CSS

No CSS também ele agiliza um monte! Você pode escrever propriedade e valores em uma tacada só. Veja:

.seletor {
  /* básico */
  df → display: flex;
  dib → display: inline-block;
  ffa → font-family: Arial, "Helvetica Neue", Helvetica, sans-serif;
  bt → border-top: 1px solid #000;

  /* com valores */
  m10 → margin: 10px;
  bt2e → border-top: 2em;
  p2px4px → padding: 2px 4px;
}

No início demora até ir decorando as abreviações, mas como o tempo você vai ficando cada vez mais produtivo e economiza alguns milhares de toques no teclado no seu dia-a-dia.

🔥 Para facilitar a sua vida, aqui tem um cheat sheet oficial com todas as abreviações: https://docs.emmet.io/cheat-sheet/

Vale lembrar que o Emmet possui plugins para quase todos os editores.

2. Prettier

Lembra quando a gente perdia tempo formatando o código na mão pra ficar legível? Alinha indentação, adiciona umas quebras de linha, ajusta o espaçamento, troca o tipo de aspas pra ficar consistente…

Aí, depois de todo esse esforço, você fazia um pull e vinha o código do coleguinha todo mal formatado! 🤬

Todo esse sofrimento pode acabar, bastando usar um formatador automático de código, como o Prettier.

Ele se integra ao seu editor e formata seu código assim que você salva. Simples assim. Pode escrever tudo embolado, do jeito que sair da sua cabeça. Salvou. Tá formatado.

Ele tem suporte oficial para várias linguagens como HTML , CSS , JS (e derivadas como JSX , SASS e TypeScript ), e através de plugins suporta também Java , PHP , SQL , Ruby , Swift , entre outras.

Você pode customizar as regras de formatação, se quiser, ou usar o padrão dele com zero config.

Além de configurar o editor para formatar no save, é interessante também adicionar um git hook para formatar no commit. Assim garante que nenhum código 💩(mal formatado) passe. Aumenta a produtividade e reduz desavenças. Olha aí, que beleza!

3. Live reload

Aqui não é uma ferramenta específica, mas uma técnica de desenvolver uma página web tendo feedback instantâneo das alterações que você faz no código.

Se você usa webpack, você pode ativar o live reload com o webpack-dev-server. Inclusive tem um artigo aqui no blog onde mostro como usar: Webpack sem Medo — Parte 3: Plugins e Dev Server

Outra alternativa fácil, sem webpack , é usar o live-server. Você só precisa ter o Node.js com NPM instalado e rodar este comando no terminal, na pasta onde está seu arquivo HTML :

npx live-server

Ele vai subir um servidor local e abrir sua página com o live reload ativado. A partir daí, cada alteração nos arquivos é refletida instantaneamente na página aberta.

E se você tem dois monitores, ou tem espaço suficiente para abrir o editor e o navegador lado a lado, a coisa flui ainda melhor.

4. DevDocs

Quando estamos codando, gastamos boa parte do tempo consultando documentações, não é mesmo? Então o ideal é que este processo seja o mais fluído possível. Uma ferramenta que ajuda muito aqui é o DevDocs.

Ele possui uma busca rápida, que busca ao mesmo tempo em várias documentações. Você pode habilitar ou desabilitar documentações específicas e até habilitar a busca offline!

Você pode até buscar direto na barra de endereço do Chrome. Basta começar a digitar o endereço do site, e quando o Chrome sugerir, aperte Tab e digite seu termo de busca.

Mac e Alfred

Com o app Alfred, para Mac , dá pra buscar no DevDocs através de um atalho global, sem precisar nem abrir o browser.

Você vai precisar da versão paga do app e deste addon: https://github.com/yannickglt/alfred-devdocs

Certamente deve ter alguma alternativa parecida no Windows e Linux. Se alguém souber, comenta aí!

5. VS Code

Para fechar, vou deixar algumas dicas de produtividade para o ótimo editor de códigos VS Code. Se você usa outro editor, provavelmente ele possui estas mesmas funcionalidades, talvez com atalhos diferentes.

Edição múltipla

Uma das funcionalidades mais úteis nos editores modernos é a possibilidade de ter mais de um cursor e poder editar mais de um ponto ao mesmo tempo.

No VS Code você pode adicionar mais cursores clicando em diferentes pontos enquanto segura Alt.

Outra forma é selecionando uma parte do código e apertando Cmd+D para selecionar a próxima ocorrência do mesmo texto. Cada vez que o atalho é pressionado ele procura pela próxima ocorrência e adiciona à seleção, mantendo um cursor em cada ocorrência. Depois você pode alterar todas de uma vez.

Go to file

Outra funcionalidade que salva muito tempo, principalmente em projetos com muitos arquivos, é ir direto para um arquivo específico, sem precisar procurá-lo na estrutura de pastas.

Se você sabe o nome, ou parte dele, é só usar o Go to File (Cmd+P no Mac) e começar a digitar parte do nome. Ele faz uma busca fuzzy, portanto, mesmo você não digitando exatamente o nome, ele traz os arquivos que mais se aproximam. Depois é só dar Enter para abrir o arquivo.

Find and replace

Buscar e substituir um texto em um arquivo já é útil, agora buscar e substituir em todo o projeto é uma tremenda mão na roda!

No VS Code basta usar a busca na barra lateral (Cmd+Shift+F) para buscar em todo o projeto, e se você expandir a setinha na lateral ele abre o campo de substituição e até mostra uma prévia do que vai ser substituído, pra você ter certeza.

Split editor

Por fim, muito útil para editar arquivos relacionados, é a opção de dividir o editor para mostrar diferentes arquivos ao mesmo tempo. É legal, por exemplo, para fazer TDD e ficar chaveando entre o arquivo de teste e o arquivo da funcionalidade em si.

No VS Code dá pra dividir na horizontal, vertical, de várias maneiras diferentes.

Conclusão

Estas foram algumas dicas que, pra mim, ajudam muito na produtividade. Algumas coisas são muito pessoais, mas a ideia é procurar sempre melhorar seu workflow.

Tem outras dicas legais para melhorar a produtividade? Comenta aí!

[]’s

O post 5 Ferramentas de Produtividade Essenciais no Desenvolvimento Web apareceu primeiro em Web Dev Drops.

Curso Pacote Full-Stack Danki Code é bom? Vale a pena?

Douglas Matoso — Fri, 18 Oct 2019 01:34:42 +0000

Muita gente está me perguntando se o curso Pacote Full-Stack Danki Code é bom mesmo. Será que vale a pena?

Veja minha análise completa neste post.

O que é o Pacote Full-Stack?

O curso Pacote Full-Stack da Danki Code é, na verdade um pacote de cursos que engloba toda a formação de Desenvolvedor Web, incluindo backend, frontend e web design.

Conteúdo

O pacote, que vai desde o iniciante até o avançado, é composto pelos cursos:

✅ Front-End Completo : vai desde os conceitos básicos, HTML, CSS, design responsivo, JavaScript e lógica de programação, frameworks JS, ES6, Sass, Less.

✅ Desenvolvimento Web Completo : este é focado no backend em PHP. Vai desde configuração do servidor, hospedagem, lógica de programação e algoritmos, banco de dados, SEO, analytics, MVC, segurança e muito mais.

✅ Web Design Express : focado em design, Photoshop, UI, UX.

✅ PHP Jedi : aqui vem a parte mais avançada de PHP, incluíndo PHP 7+ e projetos mais desafiadores.

✅ Além de outros bônus para complementar o aprendizado.

Você pode conferir mais detalhes das grades do cursos e dos bônus visitando o site oficial aqui.

Atualizações vitalícias

Os cursos são atualizados frequentemente para cobrir novas tecnologias. E o melhor de tudo é que você paga uma vez e tem acesso vitalício , incluindo todas as futuras atualizações.

Projetos desenvolvidos

Um grande diferencial do pacote é que ele une bem teoria e prática. Durante os cursos você irá desenvolver mais de 100 projetos práticos , o que reforça o aprendizado e já constrói um respeitável portfólio de projetos para atrair clientes (caso queira ser um freelancer) e recrutadores (caso queira seguir carreira em empresas).

Garantia

A Danki Code oferece uma garantia de 30 dias. Se não gostar do curso, por qualquer motivo, eles devolvem 100% do valor pago.

Preço

Com todo esse conteúdo, bônus, atualizações, e o quanto ele vai transformar sua carreira de desenvolvedor web full-stack, o preço é irrisório. Atualmente sai a menos de 1 Real por dia!

O primeiro projeto que você pegar como freelancer ou o próximo emprego que você conseguir com essas habilidades já paga o curso com folga!

⚠️ Atenção! O pessoal da Danki Code está para aumentar o preço em breve devido a tantas atualizações! Recomendo ir lá no site oficial e garantir logo sua vaga com o preço atual.

Conclusão

A Danki Code é referência em cursos de TI, possui atualmente mais de 25.000 alunos matriculados e tem nota máxima nas plataformas de cursos online.

Um curso bem estruturado faz muita diferença na sua carreira. Muitos desenvolvedores ficam “correndo atrás do rabo”, buscando conteúdos gratuitos fragmentados e, muitas vezes, de qualidade duvidosa, e acabam estagnados e frustrados.

O Pacote Full-Stack é um excelente investimento atualmente, tanto para quem quer começar quanto para o profissional que quer dar um upgrade na carreira de desenvolvedor web.

🔥 Atualização :

A Danki Code liberou algumas aulas grátis do Pacote Full-Stack!

Veja como acessar no post: Aulas Grátis do Curso Pacote Full-Stack da Danki Code

O post Curso Pacote Full-Stack Danki Code é bom? Vale a pena? apareceu primeiro em Web Dev Drops.