Forem: Francesco Agnoletto

How to add styled-components to a React application

Francesco Agnoletto — Mon, 27 Jul 2020 18:47:52 +0000

I've talked about the advantages of CSS-in-JS and styled-components in a previous article you can find here.
A few days ago I had to set up it from scratch again and hated doing it. It does require quite a few actions to leverage the full advantages it can offer so let's see all the steps required.

Install emotion

I prefer emotionjs between the CSS-in-JS libraries. It works very well with TypeScript and has an easy syntax.

$ npm i @emotion/core @emotion/styled

will add the basic packages. @emotion/core is required, @emotion/styled only if you want styled-components. I favor the latter but sometimes use core for either some small styling with css or keyframes.

The vscode styled-components extension for syntax highlight and IntelliSense is a must.

Setting up .babelrc

Babel requires a plugin to parse emotion.
The default setup requires installing babel-plugin-emotion but it does not include the css prop. @emotion/babel-preset-css-prop does and includes the default plugin.

// the css prop
const Button: React.FC<IProps> = props => (
  <a
    css={{
      color: 'hotpink',
      '&:hover': {
        color: 'darkorchid'
      }
    }}
    {...props}
  />
)

$ npm i -D @emotion/babel-preset-css-prop

will install it.

The emotion plugin needs to appear after @babel/preset-react and @babel/preset-typescript in the list of plugins in case you are using them (you should!).

// recommended .babelrc config for emotionjs
{
  "env": {
    "production": {
      "presets": [
        "@babel/react",
        "@babel/typescript",
        "@emotion/babel-preset-css-prop"
      ]
    },
    "development": {
      "presets": [
        "@babel/react",
        "@babel/typescript",
        ["@emotion/babel-preset-css-prop", { "sourceMap": true }]
      ]
    }
  }
}

Linting with style

Stylelint adds rules and checks for styled-components libraries. Since emotionjs is based on styled-components, the linting is fully compatible. It is also enabled by default.

$ npm i -D stylelint stylelint-config-standard

You can set up custom rules as well, declaration-empty-line-before is for prettier compatibility.

// .stylelintrc
{
  "extends": [
    "stylelint-config-standard"
  ],
  "rules": {
    "declaration-empty-line-before": null,
  }
}

Install the vscode extension to enable default detection on vscode.

Closing thoughts

Setting up new libraries can be a chore, especially when the documentation is spread in different places.
The advantages of using styled-components outweigh the initial set up chore. But it doesn't mean it has to be a time-consuming activity.

How to write a custom React fetch hook

Francesco Agnoletto — Wed, 01 Jul 2020 19:50:14 +0000

Writing the same fetch code in every component that needs it can be extremely boring, long, and prone to bugs.
Luckily this can be optimized with a custom React hook. Leaving us to handle the render logic only.

The standard hooks

At the end of the day, a custom hook is just a function that calls the standard React hooks inside of it.

We will leverage both useState and useEffect hooks for our custom fetch hook.

We want to make sure the hook allows us to display its status when loading data, failure, or success.
For this reason, we can start by defining the type for our data to handle all three cases.

// loading type has no data nor error
interface ILoadingState {
  status: "loading";
  data: null;
  error: null;
}

// error type has no data but an error
interface IErrorState {
  status: "error";
  data: null;
  error: Error;
}

// success type has data with type provided by user
// and no error
interface ISuccessState<T> {
  status: "success";
  data: T;
  error: null;
}

// By writing 3 interfaces instead of a conditional one
// we are sure that if the status is "success" it will always have data
// and "error" will always have an error
type state<T> = ILoadingState | IErrorState | ISuccessState<T>;

Once the types are done we can jump on drafting the hook.

// we don't know the type returned from the fetch
// so we leave it as any unless the user provides it
function useFetch<S = any>(url: string): state<S> {
  // standard useState hook to save our data
  const [state, setState] = useState<state<S>>({
    status: "loading",
    data: null,
    error: null,
  });

  // standard useEffect to fetch data
  useEffect(() => {
    fetch(url)
      .then((response) => {
        return response.json();
      })
      .then((data: S) => {
        setState({
          status: "success",
          data,
          error: null,
        });
      })
      .catch((error: Error) => {
        setState({
          status: "error",
          data: null,
          error: error,
        });
      });
  }, []);

  return state;
}

As you might notice, all this code is the exact same that would be written in any component needing to fetch data. Nothing special is going on other than the fact we are using these hooks inside a simple function.

I wrote a simple example to test the hook below:

const App = () => {
  const { status, data, error } = useFetch("https://aws.random.cat/meow");

  if (status === "error") {
    return <div>Error: {error.message}</div>;
  } else if (status === "success") {
    return (
      <div>
        <img src={data.file} width={600} />
      </div>
    );
  } else {
    return <div>Loading</div>;
  }
};

The code works! It displays an initial loading, then an error in case of failure and a cat pic in case of success.

What if we want a new cat pic? Unfortunately, this code only works when the component initially renders. It has no way of being called again.

We can improve the hook to allow an optional parameter to re-run useEffect when the value changes.

function useFetch<S = any>(url: string, params: unknown[] = []): state<S> {
  const [state, setState] = useState<state<S>>({
    status: "loading",
    data: null,
    error: null,
  });

  useEffect(() => {
    // each time we re-run useEffect
    // we change the state to loading
    // to provide feedback to the user
    setState({
      status: "loading",
      data: null,
      error: null,
    });
    fetch(url)
      .then((response) => {
        return response.json();
      })
      .then((data: S) => {
        setState({
          status: "success",
          data,
          error: null,
        });
      })
      .catch((error: Error) => {
        setState({
          status: "error",
          data: null,
          error: error,
        });
      });
    // optional array of parameters for re-running the useEffect hook
  }, params);

  return state;
}

The new functionality expands our code without modifying the original hook.

An example of how this code could be used for refreshing data.

const App = () => {
  const [reloading, setReloading] = React.useState<boolean>(false);
  // we define the custom shape of our data
  const { status, data, error } = useFetch<{ file: string }>(
    "https://aws.random.cat/meow",
    // array of parameters
    [reloading]
  );

  // simple hack to refresh our hook
  // when button is pressed
  // the value of reloading changes
  // triggering our custom hook to re-run
  // and give us a new cat pic
  const reloadImage = () => {
    setReloading(!reloading);
  };

  if (status === "error") {
    return <div>Error: {error.message}</div>;
  } else if (status === "success") {
    return (
      <div>
        <img src={data.file} width={600} />
        <button onClick={reloadImage}>New cat!</button>
      </div>
    );
  } else {
    return <div>Loading</div>;
  }
};

And that's all there is to it.

The full code is available on GitHub.

I also published the fetchHook source code on npm, it is available here, you can simply install it and use as described above.

How to setup NextJS with TypeScript and ESLint + prettier

Francesco Agnoletto — Mon, 25 May 2020 17:46:51 +0000

Sharing code on front-end and back-end has always been my dream. NextJS makes it easy with a simple framework including both, simple to run, simple to use.

NextJS makes it really easy to modify its setup, making compatibility a first class citizen.

To jumpstart a NextJS project you don't need anything more than this command.

$ npm init next-app nextjs-example

Change nextjs-example to whatever name you want the project to have.

$ cd nextjs-example to get in the folder, and now we're ready to start.

NextJS and TypeScript

NextJS comes with TypeScript just one click away, creates an empty tsconfig.json file and run $ npm run dev.\
The tsconfig will be populated automatically and all .js files are ready to be converted to .ts.

Differently from the babel TypeScript presets (used by Gatsby, for example), NextJS will not compile on type errors. I don't feel a great difference between the two options. At the end of the day, if you are using TypeScript you want your types to be correct, regardless of compilation.

NextJS + prettier

Adding prettier is easily achieved as well.

$ npm i - prettier

And next, create a .prettierrc file.

// .prettierrc
{
  "endOfLine": "lf",
  "semi": true,
  "singleQuote": false,
  "tabWidth": 2,
  "trailingComma": "es5"
}

And that's pretty much it.

NextJS + ESLint

ESLint needs to be configured with both TypeScript and prettier, but also NextJS's React implementation.

There are quite a few libraries that need to be added for this all to work properly.

npm i -D eslint eslint-loader eslint-plugin-react eslint-config-prettier eslint-plugin-prettier @typescript-eslint/eslint-plugin @typescript-eslint/parser

A basic .eslintrc.js config will look like this.

// .eslintrc.js
module.exports = {
  // Specifies the ESLint parser
  parser: "@typescript-eslint/parser",
  extends: [
    "plugin:react/recommended",
    "plugin:@typescript-eslint/recommended",
    "prettier/@typescript-eslint",
    "plugin:prettier/recommended",
  ],
  settings: {
    react: {
      version: "detect",
    },
  },
  env: {
    browser: true,
    node: true,
    es6: true,
  },
  plugins: ["@typescript-eslint", "react", "prettier"],
  parserOptions: {
    ecmaFeatures: {
      jsx: true,
    },
    // Allows for the parsing of modern ECMAScript features
    ecmaVersion: 2018,
    // Allows for the use of imports
    sourceType: "module",
  },
  rules: {
    // Disable prop-types as we use TypeScript for type checking
    "react/prop-types": "off",
    "@typescript-eslint/explicit-function-return-type": "off",
    "prettier/prettier": "error",
    "@typescript-eslint/interface-name-prefix": "off",
    "@typescript-eslint/no-explicit-any": "off",
    "@typescript-eslint/ban-ts-ignore": "off",
    // needed for NextJS's jsx without react import
    "react/react-in-jsx-scope": "off",
  },
  globals: { React: "writable" },
};

I'm not a fan of an over personalized linting config. It takes time away from development and introduces complexity to an accepted standard.

BONUS: NextJS and Jest

Testing makes apps more reliable and bug fixing easier. I prefer to have it and write tests as the app progresses.

Interviews go a lot better when you display testing skills. Being on the other side of the interview, I always appreciate candidates who can write tests.

Jest is the go-to testing library for React applications, adding it to a NextJS application is not too difficult but requires some changes.

First, the packages. jest, @testing-library/jest-dom and @testing-library/react for testing, and babel-jest for the config.

npm i -D jest @testing-library/jest-dom @testing-library/react babel-jest

We need to create a .babelrc file to enable the testing environment.

// .babelrc
{
  "presets": ["next/babel"]
}

The Jest config is pretty short as well, I removed the .css transformations since NextJS includes a good css-in-js solution to handle styles.

// jest.config.js
module.exports = {
  collectCoverageFrom: ["**/*.{ts,tsx}", "!**/*.d.ts", "!**/node_modules/**"],
  // we need to create this file
  setupFilesAfterEnv: ["<rootDir>/setupTests.js"],
  testPathIgnorePatterns: ["/node_modules/", "/.next/",],
  transform: {
    "^.+\\.(js|jsx|ts|tsx)$": "<rootDir>/node_modules/babel-jest",
  },
  transformIgnorePatterns: ["/node_modules/"],
};

Last, the setup file for Jest is just one line.

// setupTests.js 
import "@testing-library/jest-dom/extend-expect";

BONUS 2: What about end-to-end tests?

It takes even less time to set up end-to-end testing, I wrote a small how-to here.

If you have any questions, feel free to leave a comment.

Write your first end-to-end test in 5 minutes

Francesco Agnoletto — Wed, 29 Apr 2020 18:34:01 +0000

There are some features and web applications that are not easy to test. Unit tests can only go so far in testing what the end-user sees when visiting your application.

Anything that requires real interaction with the DOM, for example tracking the mouse position or drag and drop, can be easily tested with end-to-end tests.

The main advantage of end-to-end tests is that you write tests that run in a real browser. That's the closest you can get to the end-user, making these tests highly reliable.
They are also technology agnostic, so whatever framework you happen to use, testing is exactly the same.

Setting up the repository

I'm using this repository as an example since it provides a perfect target to end-to-end tests. It does use react and TypeScript, but don't worry if you are not familiar with them, we are not going to touch the code.
Make sure to delete the /cypress folder as it contains what we are going to do below.

Run npm i and npm start to see how the app works (start is also required to run the tests, so keep it running!).

Setting up cypress

I'm going to use cypress.io as end-to-end testing library. The excellent documentation and ease of installation make it an easy choice to quickly write down some tests.

Since cypress doesn't require any configuration outside of its own folder, it's safe to install in any frontend codebase.

$ npm i -D cypress

There are 2 ways of running cypress: in the browser (in watch mode) or the command line (no watch mode).
We can try both by adding the scripts in package.json.

{
  "scripts": {
    "cypress": "cypress run", // cmd
    "cypress--open": "cypress open" // browser
  }
}

Running once npm run cypress-open will set up all the files required inside the /cypress folder.

The last step is to set up our port in cypress.json.

{
  "baseUrl": "http://localhost:8080" // change to whatever port you need
}

Writing the first test

Once you ran the command above once, you will have completed the setup to install cypress.
Cypress comes with a few example tests in /cypress/integration/examples but we can delete those, we will write our own soon.

Feel free to visit the application at localhost:8080 to see how it works.
The app just handles some mouse inputs. On the main div, pressing the left-click will generate a note, left-clicking the note's icon will make it editable and right-clicking on it will delete it.

Create a homepage.spec.js file inside /cypress/integration, and let's tell cypress to visit our app.

// cypress/integration/homepage.spec.js

it("successfully loads", () => {
  cy.visit("/");
});

And voilà the first test is done! You can check that it passes by running npm run cypress or npm run cypress--open.

Cypress looks very similar to many unit testing libraries like jest or mocha. It also comes with its own assertion library, so it is fully independent.

While this was easy, this test only checks that the app running.

Writing all the other tests

The first interaction in our app regards left-clicking on the main div, so let's write a test for that.

it("click generates a note in the defined position", () => {
  // First, we check that our base div is indeed empty,
  // no note elements are present in the page
  cy.get("#app > div").children().should("have.length", 0);

  // Cypress provides a very intuitive api for mouse actions
  const pos = 100;
  cy.get("#app > div").click({ x: pos, y: pos });

  // now that we have clicked the div
  // we can check that a note appeared on top of our div
  cy.get("#app > div").children().should("have.length", 1);
});

This test already does enough to make us happy. When the click happens, a new note element is created.
We can improve it further by checking the position of the new note.

it("click generates a note in the defined position", () => {
  // First, we check that our base div is indeed empty,
  // no note elements are present in the page
  cy.get("#app > div").children().should("have.length", 0);

  // Cypress provides a very intuitive api for mouse actions
  const pos = 100;
  cy.get("#app > div").click({ x: pos, y: pos });

  // now that we have clicked the div
  // we can check that a note appeared on top of our div
  cy.get("#app > div").children().should("have.length", 1);


  // Checking the position on the div of our new note
  cy.get("#app > div button")
    .should("have.css", "top")
    // we detract half the size of the button on note.tsx
    // 100 - 12 padding = 88
    .and("match", /88/);

  cy.get("#app > div button")
    .should("have.css", "left")
    // we detract half the size of the button on note.tsx
    // 100 - 12 padding = 88
    .and("match", /88/);
});

An important note on cypress tests, the DOM will not reset between tests, this makes it easy to test incremental features.
We can use this to keep testing the note we created in the previous test. The next interaction we can test is editing.

it("left click on note edits the note content", () => {
  // We don't care for position of the click
  // as long as the click happens inside the note
  cy.get("#app > div button").click();

  // Typing does not happen instantly, but one key at a time
  cy.get("input").type("Hello World");
  // {enter} will tell cypress to hit the enter key
  // this will save our text and close the edit input
  cy.get("input").type("{enter}");

  // Check to make sure our note has been edited correctly
  cy.get("#app > div div").contains("Hello World");
});

The last feature to test is the delete action, a simple right-click on a note button deletes it, the test is very similar to the edit note one, just shorter.

it("right-click on note deletes a note", () => {
  // defensive check to make sure our note is still there
  cy.get("#app > div").children("button").should("have.length", 1);

  // right-click on the note button
  cy.get("#app > div button").rightclick();

  // Check to make sure the note disappeared
  cy.get("#app > div").children("button").should("have.length", 0);
});

And with this all our app functionality has been tested.

Bonus test - login form

Most applications start with a login form, and I didn't write any code for this extremely common use case.
Below a quick example test including a timeout to load the next page once the authentication is successful.

describe("Login Page", () => {
  it("logs in", () => {
    cy.visit("/login");

    cy.get("input[name='login']").type("test user");
    cy.get("input[name='password']").type("password");
    cy.get("button[type='submit']").click();

    // change /success for the route it should redirect to
    cy.location("pathname", { timeout: 10000 }).should("include", "/success");
  });
});

Closing thoughts

End to end tests can be easier to write than unit test as they don't care for technologies or code-spaghetiness.

They are also very effective as they are the closest automated tests to the end-user.

The full repository can be found here.

originally posted on decodenatura

About CSS-in-JS and React

Francesco Agnoletto — Mon, 06 Apr 2020 19:20:59 +0000

CSS-in-JS is something I've been unable to stop using on both personal projects and work.
CSS has been introducing more and more features, making SCSS less of an obvious choice.

At the same time, CSS-in-JS libraries entered the scene. They add some interesting features: Server-Side-Rendering, code splitting as well as better testing.

For the purpose of this article, I will be using EmotionJS and React. EmotionJS features TypeScript support, easy setup, and testing integration.

Advantages of CSS-in-JS

Being JavaScript, it offers all the features modern front-end development relies on.

Server-Side Rendering and code split with Emotion

Server-Side Rendering (SSR) with Emotion and React is simple. If you have React SSR enabled then congratulations! You have enabled it for Emotion as well.

Code splitting is pretty much the same.
Emotion is JavaScript so it will code split just like the rest of the application.

Sharing props between React and Emotion

Building styles based on classes can become quite complicated for big codebases.
In most cases, having each prop become a class can increase the verbosity of the code.
Having props determine styles without classes would cut a lot of unnecessary code.

const classes = `${className} ${theme || "off-white"} ${size || "medium"} ${border !== false ? "with-border" : ""} ${inverted ? "inverted" : ""} ${disabled ? "disabled" : ""}`;

The example above shows how convoluted a template literal can become.

This can be avoided by leveraging Emotion.

import { css } from "@emotion/core";
import styled from "@emotion/styled";

const themes = {
  red: css`
    color: pink;
    background: red;
    border-color: pink;
  `,
  blue: css`
    color: light-blue;
    background: blue;
    border-color: light-blue;
  `,
};

const sizes = {
  small: '8px',
  medium: '12px',
  large: '16px'
}

const disabledCss = css`
  color: grey;
  border-color: grey;
`;

/* Defining the button with the conditional styles from props */
const StyledButton = styled.button`
  ${(props) => themes[props.theme]};
  font-size: ${(props) => sizes[props.size]};
  border: ${(props) => props.border ? '1px solid' : 'none'};
  ${(props) => props.disabled && disabledCss};
`;

/* And finally how to use it */
<StyledButton
  theme="red"
  size="medium"
  border={true}
  disabled={false}
>
  Hello
</StyledButton>

There are no classes to depend on. The styles are applied to the components, removing the classes layer.

New styles are easily added and even more easily removed, JavaScript handles variables far better than we handle classes.

These atomic styles are easy to share across the codebase. Being variables, they can be imported and exported to other files.

Testing Emotion and React

Style regression and changes have always been up to the developer to check manually. CSS and SCSS do not allow to test this in any meaningful way.

Jest allows to snapshot React components to see diffs in HTML, making sure changes are safe. In the same way, Emotion styles can be snapshotted.

Snapshotting CSS removes the need to have to check manually if the styles break when making new changes.
This can be a huge time saver for both developers and testers who can ship code with more confidence.

Achieving all this in Emotion is rather fast.

Add this to your Jest setup file

import * as emotion from 'emotion'
import { createSerializer } from 'jest-emotion'

expect.addSnapshotSerializer(createSerializer(emotion))

And it's done. When creating a snapshot, the EmotionJS output will be included in the snapshot.

Closing thoughts

CSS-in-JS has drastically changed the way to write CSS. Leveraging the most used programming language gives CSS new features to improve the way styles can be written.

Performance, maintainability, and testing are the core of a good application. CSS-in-JS offers improvements over older standards to all these issues.

originally posted on decodenatura

How to setup gatsby with TypeScript and ESLint + prettier

Francesco Agnoletto — Mon, 30 Mar 2020 17:29:37 +0000

Gatsbyjs starters are perfect for jumpstarting a new project. As all boilerplates, it lacks some tools to optimize our development experience.
Fortunately for us, Gatsbyjs is highly customizable.

TypeScript

Typescript is the easiest of them and the most impactful. Install the TS package, add it to the gatsby-config.js file, and create a tsconfig.json file.

// basic gatsbyjs tsconfig.json
{
  "compilerOptions": {
    "module": "commonjs",
    "target": "esnext",
    "jsx": "preserve",
    "lib": ["dom", "esnext"],
    "strict": true,
    "noEmit": true,
    "isolatedModules": true,
    "esModuleInterop": true,
    "noUnusedLocals": false
  },
  "exclude": ["node_modules", "public", ".cache"]
}

You can now start converting JS files to TS. Remember to add the @types/ packages, as by default they are not included.

As a bonus, install typescript and add a type check script to your package.json.

"type-check": "./node_modules/typescript/bin/tsc --noEmit --skipLibCheck"

Gatsby and gatsby-plugin-typescript use babel, so type checking will not stop the build. Use the script either manually or as a pre-commit hook to run it automatically.

Prettier

Like TypeScript, prettier is pretty straight-forward. One of the most used starters, gatsby-starter-blog already includes it. Let's see how to add it from scratch.

We have to install prettier as dev dependency npm i -D prettier. After that, a simple .prettierrc file will suffice.

// .prettierrc
{
  "endOfLine": "lf",
  "semi": true,
  "singleQuote": false,
  "tabWidth": 2,
  "trailingComma": "es5"
}

Install the prettier plugin on vscode and enable it on your personal settings.json file. View -> command palette -> search for "> preferences: open settings (JSON)".

// settings.json rules for prettier
{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "[javascript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "editor.formatOnSave": false
  },
  "[javascriptreact]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "editor.formatOnSave": false
  },
  "[typescript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "editor.formatOnSave": false
  },
  "[typescriptreact]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "editor.formatOnSave": false
  }
}

ESLint

ESLint requires a bit more than the other two. First, we need to install all the dev deps needed to run it.
We will need eslint, eslint-loader, and gatsby-plugin-eslint for the initial config.
eslint-plugin-react for react, eslint-plugin-prettier and eslint-config-prettier for prettier. @typescript-eslint/eslint-plugin and @typescript-eslint/parser for TypeScript compatibility.

$ npm i -D eslint eslint-loader gatsby-plugin-eslint eslint-plugin-react eslint-plugin-prettier eslint-config-prettier @typescript-eslint/eslint-plugin @typescript-eslint/parser

Open gatsby-config.js and add the ESLint config to make it work. We need to allow TS extensions and optimize a couple of options.

// gatsby-config.js with eslint for both JS and TS files
{
  ...
  plugins: [
    ...,
    {
      resolve: "gatsby-plugin-eslint",
      options: {
        test: /\.js$|\.jsx$|\.ts$|\.tsx$/,
        exclude: /(node_modules|.cache|public)/,
        stages: ["develop"],
        options: {
          emitWarning: true,
          failOnError: false,
        },
      },
    },
  ]
}

Then we need to set up a basic .eslintrc.js file. Here's where we will have to tell ESLint to be nice to react, prettier, and TypeScript.

// basic .eslintrc.js compatible with react prettier and typescript
module.exports = {
  // Specifies the ESLint parser for TypeScript
  parser: "@typescript-eslint/parser",
  extends: [
    "plugin:react/recommended",
    "plugin:@typescript-eslint/recommended",
    "prettier/@typescript-eslint",
    "plugin:prettier/recommended",
  ],
  settings: {
    react: {
      version: "detect",
    },
  },
  env: {
    browser: true,
    node: true,
    es6: true,
  },
  plugins: ["@typescript-eslint", "react", "prettier"],
  parserOptions: {
    ecmaFeatures: {
      jsx: true,
    },
    // Allows for the parsing of modern ECMAScript features
    ecmaVersion: 2018,
    // Allows for the use of imports
    sourceType: "module",
  },
  rules: {
    // Disable prop-types as we use TypeScript for type checking
    "react/prop-types": "off",
    "@typescript-eslint/explicit-function-return-type": "off",
    // Enable prettier rules
    "prettier/prettier": "error",
    // interface start with capital I
    "@typescript-eslint/interface-name-prefix": "off",
    // allow "any" as type
    "@typescript-eslint/no-explicit-any": "off",
    // allow @ts-ignore for testing purposes
    "@typescript-eslint/ban-ts-ignore": "off",
  },
};

Last this we need to make sure vscode is actually working with us and understands all that we want. Install the ESLint package for vscode if you don't have it already. A few lines on the user's settings.json file will make it work (like we did for prettier).

// settings.json rules for ESLint
{
  "eslint.autoFixOnSave": true,
  "eslint.validate": [
    "javascript",
    "javascriptreact",
    {
      "language": "typescript",
      "autoFix": true
    },
    {
      "language": "typescriptreact",
      "autoFix": true
    }
  ]
}

Your Gatsbyjs template with TypeScript, prettier and ESLint enabled is ready.\
The initial time it costs to set it up is dwarfed by the advantages that these technologies can provide. Have fun coding!

originally posted on decodenatura

How to set up React Native, TypeScript and ESLint + prettier

Francesco Agnoletto — Mon, 23 Mar 2020 17:10:30 +0000

React Native has made mobile app development very close to a React application. Many tools we use on a React project are available to Native as well. In this article, I want to illustrate how easy and fast it is to add TypeScript, ESLint and prettier for a React Native project.

TypeScript with Expo

Expo.io makes emulating a React Native project on any device a walk in the park. It's my tool of choice when starting a new project.

$ npx expo init todo-app

It is all you need. Make sure to follow the instruction and pick a template with TypeScript.

Download the expo app on your phone and you can tunnel localhost on your phone as well, A+ dev experience.

Bonus: Enable React Native tools on vscode

Install React Native Tools on vscode for a better experience in your code editor.

Prettier + React Native

Setting up prettier tends to be straight-forward in most codebases. Install the package and set up a .prettierrc file if you want to override the default rules.

$ npm i -D prettier

// .prettierrc
{
  "endOfLine": "lf",
  "semi": true,
  "singleQuote": false,
  "tabWidth": 2,
  "trailingComma": "es5"
}

Bonus: Set up prettier for vscode

Install the prettier plugin on vscode and enable it on your personal settings.json file. View -> command palette -> search for "> preferences: open settings (JSON)".

// settings.json rules for prettier
{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "[javascript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "editor.formatOnSave": false
  },
  "[javascriptreact]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "editor.formatOnSave": false
  },
  "[typescript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "editor.formatOnSave": false
  },
  "[typescriptreact]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "editor.formatOnSave": false
  }
}

Add ESLint

ESLint requires a bit more tailoring for expo. We need to install all the ESLint dependencies plus the expo config for eslint. The package is made to be compatible with expo and React Native environments. It also supports TypeScript.

$ npm i -D eslint @typescript-eslint/eslint-plugin @typescript-eslint/parser eslint-config-universe

After, either package.json or .eslintrc.js have to be configured to use our config.

// package.json
{
  "eslintConfig": {
    // for expo projects using react native
    "extends": "universe/native"
  }
}

// .eslintrc.js
module.exports = {
  extends: "universe/native",
};

And you are set.

Bonus: Set up ESLint for vscode

Install the ESLint package for vscode if you don't have it already. A few lines on the user's settings.json file will make it work (like we did for prettier).

// settings.json rules for ESLint
{
  "eslint.autoFixOnSave": true,
  "eslint.validate": [
    "javascript",
    "javascriptreact",
    {
      "language": "typescript",
      "autoFix": true
    },
    {
      "language": "typescriptreact",
      "autoFix": true
    }
  ]
}

Closing thoughts

Setting up a good environment for developers should not take time away from coding. Modern tools can make this process really fast. My aim for this article is to help you get started in 5 minutes or less.

The complete code can be found here

originally posted on decodenatura