DEV Community: Darlan Alves

Playwright + Angular CLI

Darlan Alves — Thu, 19 Aug 2021 10:08:13 +0000

Looking for a way to run your Playwright specs with Angular CLI?

Here's how:

Install a module to run a command after the CLI serves your project:

npm i -D @dot-build/serve-and-run-angular

In your angular.json, create a new entry for Playwright. This assumes your project already has another target you use for local development, which runs with ng serve, and that your project name is my-project.

// ...
  "projects": {
    "my-project": {
      // ...
      "architect": {
        "playwright": {
          "builder": "@dot-build/serve-and-run-angular:run",
          "options": {
            "devServerTarget": "my-project:serve",
            "command": "npm",
            "args": ["run", "playwright"]
          },
          "configurations": {
            "production": {}
          }
        },
// ...

Now you go to package.json and create new scripts that will run Playwright specs and your project together:

// ...
"scripts": {
  "e2e": "ng run my-project:playwright",

  // or whatever command you use for run Playwright here
  "playwright": "npx playwright test"
  // ...
}

Now, you can set up Playwright in your project following their documentation.

If you want to watch file changes and keep executing the specs, you can pass --watch to the Angular CLI.

Example: ng run my-project:playwright --watch

That's all I have for today!
Happy coding!

The saga of Javascript errors and async/await

Darlan Alves — Fri, 16 Jul 2021 12:33:35 +0000

We went full circle with error management in Javascript!

Long ago, before AJAX was a thing, JS was pretty much synchronous and linear. Still, we had to handle errors, so we used try/catch:

function divide(a, b) {
  return a / b;
}

try {
  divide(1, 0);
} catch (error) {
  // uh, oh
}

But then Ajax came along, along with a lot of other async API's. We started using more callbacks for our error management:

const xhr = new XMLHttpRequest();
xhr.onreadystatechange = function (content) { /* ... */ };
xhr.onerror = function (error) { /* ... */ };

And then Node.JS came along, with a callback based API. Error handling was quickly turning into callback hell:

fs.readFile('foo.txt', function (error, fileContent) {
  fs.writeFile('bar.txt', fileContent, function (otherError) {
    // ...
  });
});

And then... Then we created Promise to make it more readable and consistent (apparently):

// Fetch full content of the first item found
fetch('www.example.com/items')
  .then(response => response.json())
  .then(response => 
    fetch('www.example.com/items/' + response[0].id)
  )
  .catch(error => {
    // Wait! Is this from the first or the second request?
  });

A bit better, but we still need sequential execution, and soon we get into promise hell.

async/await to the rescue

Okay, we need to fix this.
So we decided to introduce a new syntax that will internally wait for a promise resolution and clean up the code. async/await is the solution:

// Fetch full content of the first item found
const items = await fetch('www.example.com/items')
const firstItem = (await items.json())[0]
const fullContent = await fetch('www.example.com/items/' + firstItem.id)

But wait! What if the first or the second request fails?
Don't worry! We have a solution for that too!

Behold the full circle of errors: try/catch 😆

try {
  // Fetch full content of the first item found
  const items = await fetch('www.example.com/items')
  const firstItem = (await items.json())[0]
  const fullContent = await fetch('www.example.com/items/' + firstItem.id)
} catch (error) {
  // Wait! Is this from the first or the second request?
}

Pitfalls, pitfalls everywhere!

Cool! Try/catch is now async. YAY!

But what happens if I forget to use await? Well, more errors for you!

If you actually want to return a promise from a function but still handle errors, it looks like this:

try {
  return fetchAndParse('www.example.com/items.json')
} catch (error) {
  // synchronous errors end up here
}

Can you guess what happens if fetchAndParse returns a rejected promise?

function fetchAndParse() {
  return new Promise((resolve, reject) => {
    reject(new Error('Nope!'));
  };
}

And the answer is: nothing. Your try/catch block won't do anything to catch that error.
Why? Because you need the magic word in front of the function call to "connect" the chain of promises:

try {
  return await fetchAndParse('www.example.com/items.json')
} catch (error) {
  // the rejection error ends up here
}

See the difference? Subtle, but quite important!

Conclusion

So basically, if you want to use async/await, you need to wrap everything with try/catch, and you must ensure every single promise has an await in front of it.

Otherwise, JS will just ignore the errors and continue like nothing happened.

10 commandments of programming

Darlan Alves — Thu, 07 Jan 2021 20:21:42 +0000

These are 10 rules that I follow and will help you with being a better professional and effective developer.

1. If it’s hard, it’s wrong.

If a problem seems too hard to tackle, either you don’t know exactly what you are doing or you are doing it wrong.

Break down your problem into smaller pieces and try to decouple everything. Write pseudocode or create a PoC. Use pen an paper and talk about your solution with a colleague. These are great ways to check if you’re going in the right direction.

2. Don’t reinvent the wheel.

We love coding. Of course we do. But writing your own solution to everything just because we want it to be exactly like “this” or “that” is a waste of time and money.

But you should reinvent things from time to time, just for fun.

You will understand how things work to the tiniest detail. And you can only innovate or improve on things that you know very well.

3. Never stop learning.

Programming is hard. Thinking about all possible ways that something can go wrong is exhausting. Dealing with edge cases and crazy users is an insanity. But you will have to spend some time out of that madness to keep learning new things.

Try a new framework, write pet projects, fill your Github account will endless crap that no one will ever see.

That’s gonna be great for your one day, when you face a problem and “Aha, hold on!”, you know how to fix it because you tried that before.

4. Always be clear about what you are doing.

Don’t start coding until you know exactly what needs to be done.

There’s nothing worse than someone writing code at random and just hoping it will work at some point.

That only adds up to a pile of unmaintainable mess.

5. Don’t repeat yourself.

Reuse everything you can and keep things coherent. But don’t go too crazy either.

The whole point here is… if you need to change something, you should have to change it only in one place. Otherwise, you will make mistakes.

6. Write tests for everything.

Not a single line of code should go to production without some form of testing. And don’t trust your coverage either!

Code Coverage is a lie you tell yourself. It's just code porn.

Make sure you write a test, then write a line of code to pass that test.

Only this way you will know for sure that every single thing in your system is tested.

7. Don’t comment, unless you really, really need it.

Unless something incredibly hard to understand is part of your job, no comments should be tolerated.

Long if condition? Write the condition to a local constant that explains what’s that.
Weird algorithm? Write a function with a name that explains what it does.

Comments rot, and rot very fast.

8. The best code is no code at all.

Code is hard to maintain, so whenever possible, don’t write it.

Think how you can make it both more elegant and less verbose, and over time, it will shrink and work better.

9. Always leave the code you changed cleaner than you found it.

Follow the Boy's Scout rule of programming.

10. Stick to the rules!

Discipline will pay off in quality and clarity over time.

Things should be black and white. If you establish a rule, follow it to the letter.

Why? Because you don’t have to think about it!

Your precious brain juice is better spent on things that you DO have to think about.

Which rules do you follow?

Create a post or share in the comments which rules you follow every day!

Also recommended: Watch this series of Clean Code talks from Uncle Bob:

https://www.youtube.com/watch?v=7EmboKQH8lM
https://www.youtube.com/watch?v=2a_ytyt9sf8
https://www.youtube.com/watch?v=Qjywrq2gM8o
https://www.youtube.com/watch?v=58jGpV2Cg50
https://www.youtube.com/watch?v=sn0aFEMVTpA

Automatically Publish to npm using GitHub Actions

Darlan Alves — Fri, 25 Dec 2020 18:39:15 +0000

This is a quick step by step on how to publish a package to NPM automatically using semantic releases. You can read more about semantic release conventions before we continue.

What you will need

A publish token from NPM, which you can generate in npmjs.com, in your profile.
A token for GitHub API, which you can generate if you go to your Profile > Settings > Developer Settings > Personal access tokens. Using “repo” permissions should be enough. Add more as needed.

Step 1: start a new workflow file

Go to your repository > Actions and create a new action.
Use the link “set up a workflow yourself” to get started

Step 2: add a workflow configuration

Just copy paste this snippet into your new Action text. Then create a commit and save it.

name: release
on:
  push:
    branches:
      - master
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      # - name: Install dependencies and build, if needed
      #   run: npm ci && npm run build
      - name: Semantic Release
        uses: cycjimmy/semantic-release-action@v2.5.0
        env:
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

If looks like this, the you’re doing it right:

Step 3: make sure you can publish

Let's check your package.json to make sure you have the configuration to allow a publish command to NPM.

Copy this snippet and change with your repository name:

"repository": {
  "type": "git",
  "url": "https://github.com/user/repo.git"
},
"publishConfig": {
  "access": "public"
},

Step 4: add GitHub and NPM secrets

Go to your project Settings > Secrets and add GH_TOKEN and NPM_TOKEN secrets.

You can add to a repository or to an entire organisation. I use orgs when I have several small packages under the same scope.

And that’s it!

Now you can start pushing to your repository and see it auto-published if everything went as planned.

Any changes to master will trigger a new patch/minor/major change based on your commits.

Start a new library with TS in under 30 seconds

Darlan Alves — Wed, 09 Dec 2020 22:27:12 +0000

Have an awesome idea you wanna try?

Great!

You can start coding it in under 30 seconds with Typescript, Jasmine, TDD and even a coverage report!

mkdir -p idea/src
cd idea
npm init -y && npm i -D @types/jasmine \
 ts-node typescript nodemon nyc jasmine

Now open package.json and add this to the "scripts" section:

...
"scripts": {
  "test": "./node_modules/.bin/ts-node ./node_modules/jasmine/bin/jasmine --config=./jasmine.json",
  "tdd": "./node_modules/.bin/nodemon -w src -e ts -x ./node_modules/.bin/ts-node ./node_modules/jasmine/bin/jasmine --config=./jasmine.json",
  "coverage": "./node_modules/.bin/nyc -r html -e .ts -x \"src/**/*.spec.ts\" npm run test",
  "build": "tsc --project ./tsconfig.json"
}
...

Doing good!

Now create a jasmine.json

{
  "spec_dir": "src",
  "spec_files": ["**/*.spec.ts"]
}

Still counting? Okay, last one!

Create a file called tsconfig.json with this:

{
  "compilerOptions": {
    "moduleResolution": "node",
    "target": "es2019",
    "lib": ["ESNext", "DOM"],
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "typeRoots": ["./node_modules/@types"],
    "types": ["jasmine"],
    "outDir": "./dist"
  },
  "include": ["./src/**/*.ts"]
}

You did it!

Now create a folder named src/, run the test suite with npm run tdd and start coding!

When you're ready to show it to the world, npm run build and publish to NPM :)

And make sure your package.json is up to date! Change name, version and main file if needed.

By the way, did you know you can also automate your releases to npm?