DEV Community: Carl-W

Why Companies Area Restrict Jobs, Even if They Are Remote

Carl-W — Thu, 29 Feb 2024 16:39:45 +0000

Currently, remote work is becoming more mainstream than ever, especially for software engineers who actually only need a computer and a stable internet connection to perform their duties, the fact that companies restrict jobs to geographic areas might seem weird.

Why would it matter where you are if your work and contributions are happening over the internet? This question is often discussed by software engineers looking for remote positions with mostly eye-rolling 🙄 and ridicule. However, there are very valid reasons for this from the company's point of view.

Navigating the maze of taxation and legalities

The primary hurdle for companies employing internationally is the legal complexity. Different countries have unique employment laws, tax regulations, and social security requirements. For a company based in one country, ensuring compliance across all these different jurisdictions can be a logistical nightmare. This complexity isn't just about following the law; it's also about the significant administrative burden involved in managing these requirements for employees in multiple countries. For software engineers, this means that despite the borderless nature of their work, the legal borders significantly impact where they can be employed even if they are remote.

Most globally remote companies that hire regardless of location solve this issue by legally treating everyone as a contractor. The responsibility then falls on the engineer who needs to handle taxes and the administration work by themselves in the country they reside in.

We are making a focused post on this topic alone soon, but in short, this also means that if a software engineer is not prepared for this they might lose out on an opportunity because they do not understand the legal foundation on which they operate. Candidates must also understand that as contractors the contract to the hiring company is just that, a contract. Subsequently, that also means less employment security compared to if you were employed locally since contracts are often renewed on a fixed time basis and the terms might be unfavorable.

We can make the assumption that companies who only hire in their own legal region, want to operate their business more predictably, and they also want to provide the same standard to all their employees. For example, health insurance, pension, vacation days, sick leave, and so forth works differently in almost all countries. Further, equity schemes which are a great way for companies to invest in their employees most likely do not work over international borders easily.

Tax Implications

If the company has the intention of hiring a real employee, taxation is a critical concern for them when hiring internationally. Employing someone in a different country can introduce tax obligations not only for the employee but also for the employer in the employee's country of residence. This can include corporate taxes, payroll taxes, and other contributions that vary widely across jurisdictions. For companies, managing this tax landscape is challenging and often leads them to restrict job postings to regions where they are fully equipped to handle these obligations.

Practically if the candidate is in a different country and they are not going to be treated as a contractor, the company will need to register their company in that jurisdiction, officially employ them, set up bank accounts, and submit tax reports to that government regularly. This is not likely something a small to medium company has the capacity to do.

Offering Equitable Benefits

Beyond legal and tax issues, there's the challenge of providing fair employee benefits. Health insurance, retirement savings plans, and other benefits are deeply tied to local laws and market standards.

A benefits package that's competitive in one country might be lacking in another due to different expectations or requirements. Companies strive to offer fair and attractive benefits to all employees, but the variance in what that means across different countries can lead to geographic restrictions on job postings.

Some companies offer services in this capacity helping hiring companies to bridge the gap but that comes at the cost of having another entity to deal with and obviously, they are not doing it for free.

Collaboration and Time Zones

Software engineering is a collaborative field. While asynchronous work is possible, real-time communication is sometimes crucial for team cohesion, brainstorming, and problem-solving.

Time zone differences can make these interactions difficult, if not almost impossible, to coordinate when team members are spread too thinly across the globe. By restricting jobs to certain areas, companies aim to cluster their workforce within time zones that allow for efficient collaboration.

There can be benefits of having the workforce spread over the world, for instance when it comes to server monitoring. The on-call schedule will be natural as people go on and off work as the world rotates. That is most a benefit for a larger company but most likely impossible for a smaller one.

Conclusion

For software engineers looking for remote work, these restrictions might initially seem like unnecessary. However, they are rooted in legitimate challenges related to legal compliance, taxation, and the practicalities of managing a distributed team. If you understand these reasons it can help you navigate the remote job market more effectively.

If asked during interviews it also shows that you have a fundamental grasp of what it means to work remotely. Not only in a worker capacity but also what responsibility you have towards the company. If you cannot handle your own taxes as a small business you will struggle in your role.

As the remote work landscape continues to evolve, we might see more companies developing strategies to overcome these barriers, expanding the opportunities for software engineers to be "employed" across borders. But until then, if you are looking at global job postings, you will need to be prepared to also handle the extra administration that comes with that, together with the understanding that a substantial part of the money coming in will go to taxes and social fees.

P.S.

If you like this sort of content from engineers who have been working remotely for close to a decade consider creating an account at https://remoet.dev where we send and collect related information. Remote working is the future, and we need to be as informed as we can be.

This post was created for https://blog.remoet.dev

Making GraphQL Codegen Work For You: GraphQL Integration with React and TypeScript

Carl-W — Wed, 01 Mar 2023 11:09:45 +0000

TL;DR

In this guide, we’ll be showing you how to use GraphQL alongside React and GraphQL Codegen to create a simple page that can pull data from an API and send emails. We’ll be using Novu as an open source notification system for developers that can send our emails after being passed through a form created within React.

Intro

We’ve all been there: you’ve been coding away in React with Typescript enjoying type-checking until it’s time to time to integrate your application with an API. And then, all of your data types are wrong, ending up with a ton of errors, or just not working at all. Thankfully, integrating APIs doesn’t need to be complicated with GraphQL. It enables you to quickly get an API integrated without the hassle of a standard REST API, thanks to tools like Codegen.

In this article, I will demonstrate the problem that many developers face and how to improve the workflow when integrating your react app with a GraphQL API.

This tutorial assumes that you have been working with React before and want to improve, so you already have your workstation set up.

What We Will Do:

Bootstrap a new Next.js TypeScript project
Install Apollo GraphQL and fetch data from a public API
Showcase why using GraphQL Codegen is a good idea
Create a Next.js API endpoint for sending emails with data
Use the Novu.co platform for setting up and sending emails to a given email

If you want to skip the writeup, you can go to GitHub directly and look at the code: https://github.com/ugglr/next-typescript-graphql-integration

Creating an Example Project with React and Next.js

Learning is faster when you get your hands dirty, so let’s jump straight in. We’ll bootstrap a new React project using Next.js with Typescript. Next.js is a full-stack framework for React that allows us to quickly start up a web app.

Run the following command in your terminal to scaffold a new Next.js project with Typescript:

yarn create next-app --typescript

It will then prompt you for the name of the project. Let’s name it next-typescript-graphql-integration so we know what we’re working with, and we’ll leave anything else to default values.

While we’re still in the terminal, navigate to our newly created project and run it to make sure that the installation was successful.

cd next-typescript-graphql-integration

yarn dev

The output will be similar to this:

yarn dev
yarn run v1.22.15
$ next dev
ready - started server on 0.0.0.0:3000, url: http://localhost:3000
event - compiled client and server successfully in 1457 ms (165 modules)

From this, we can determine that the page is available at localhost:3000. Opening the browser and checking the page will show the default Next.js screen.

Install Dependencies & Initialize Apollo Client

We are now ready to install some packages. We start by installing one of the most popular GraphQL clients, Apollo Client. Apollo is a tool that enables devs to utilize GraphQL APIs within almost any tech stack and integrates it within your UI. Then, we’ll start doing some fetching from this public Rick & Morty GraphQL API.

yarn add @apollo/client graphql

When that’s done, let’s open up our code editor and initialize the Apollo Client. When inspecting the folder you can see that it’s a standard bare-bones Next project with the following folder structure:

root
--- .next
--- pages
--- public
--- styles

Inside of _app.tsc we can start initializing our client by following the steps described by the official Apollo Client React docs.

We include the necessary imports and create the client, then include it in our React app via ApolloProvider. In the end, the file should look something like this:

import "@/styles/globals.css";
import type { AppProps } from "next/app";

import { ApolloClient, InMemoryCache, ApolloProvider } from "@apollo/client";

const client = new ApolloClient({
  uri: "https://rickandmortyapi.com/graphql",
  cache: new InMemoryCache(),
});

export default function App({ Component, pageProps }: AppProps) {
  return (
    <ApolloProvider {...{ client }}>
      <Component {...pageProps} />
    </ApolloProvider>
  );
}

This is everything we need to initialize our brand new GraphQL client on the client side. 🚀 Let’s continue with fetching some data the un-safe way.

Fetching Data without Type Checking

Now that we have our project up and running, it’s time to add some data from our API. If we want to get a list of characters from the API we need to run a query like so:

query {
  characters {
    results {
      id
      name
            species
    }
  }
}

The Apollo documentation will tell us to create the query document and then use it together with the useQuery hook provided by Apollo. I’ve deleted everything in index.tsx and replaced it with the following:

import { gql, useQuery } from "@apollo/client";
import { NextPage } from "next";

const GET_CHARACTERS = gql`
  query {
    characters {
      results {
        id
        name
                species
      }
    }
  }
`;

const Home: NextPage = () => {
  const { loading, data } = useQuery(GET_CHARACTERS);

  return (
    <div>
      <main>
        {loading && <p>Loading...</p>}

        {data?.characters.results.map((character) => (
          <p key={character.id}>{character.name}</p>
        ))}
      </main>
    </div>
  );
};

export default Home;

This is what it will look like, so let’s check back to our application:

Everything seems like it’s good, right?

What Went Wrong with GraphQL?

While our code may work as intended, it’s not exactly reliable. There are two common errors we made here that we need to look at:

No GraphQL Type Validation

We didn’t add any type validation to our GraphQL calls. This means if you request a field that doesn’t exist in the schema, you will get weird and hard-to-understand error messages. Let’s see what can happen if we change our project:

const GET_CHARACTERS = gql`
  query {
    characters {
      results {
        id
        name
        species
                notInSchema // 👈 this will result in error
      }
    }
  }
`;

Running this will give us an “Error! Response not successful: Received status code 400”, which doesn’t tell you what went wrong at all, becoming a huge time waster.

Considering that some queries and mutations might have a variety of variables, fields, and subfields this gets complex fast (believe me, I’ve done this to my breaking point before!). So you should be ensuring that your GraphQL queries don’t call for items not in the schema.

No Types In The Response

We also didn’t include any form of autocomplete in our response, so our code doesn’t know what is supposed to be returned from our API. We need to ensure that we validate the data we receive from our API to ensure our data is correct. If we don’t, this can become a nightmare in the future.

Let’s take a look at our code editor. You should see a red line under the character variable with the following Typescript validation error:

So how do we fix this issue?

If we’re just building something small, we can create our own type like so:

type GetCharactersQueryResponse = {
  characters: {
    results: Array<{
      id: string;
      name: string;
            species: string;
    }>;
  };
};

And then passing it into our query hook:

const { loading, error, data } =
    useQuery<GetCharactersQueryResponse>(GET_CHARACTERS);

This will give us type-checking from Typescript and work just fine.

But this solution becomes a nightmare when return types become large or if you need to pass variables. All of those are checked in the GraphQL API and will send you confusing errors that are hard to debug.

Fortunately, there are some smart people who realized that all this information is already available inside GraphQL schemas & can be used to generate this information for us.

Enter: GraphQL Codegen 🚀

What Is Graphql Codegen?

Graphql Codegen is a code generation library for GraphQL that enables developers to generate custom code. It provides us developers with the ability to generate type definitions, query builders, documentation, and more by analyzing our GraphQL schemas. This makes it easier and faster to build GraphQL applications and reduces the time spent coding.

Additionally, Graphql Codegen is also a type-safe code generator. This means that the generated code is checked for errors by the Graphql Codegen compiler before it is used in an application. This ensures that any errors in the code are caught before they cause problems in production.

Plus, it also provides developers with an easy way to manage GraphQL schemas. It allows devs to easily add, remove, and update their schemas without any hassle. This makes it much easier to keep your schemas up-to-date.

Setup and Configuring GraphQL Codegen

Before we can start using Graphql Codegen, we’ll need to configure it. This process is relatively simple and can be done in a few steps:

The first step is installing GraphQL Codegen by running this command 👨‍💻

yarn add -D @graphql-codegen/cli @graphql-codegen/typescript @graphql-codegen/typescript-graphql-request @graphql-codegen/typescript-operations @graphql-codegen/typescript-react-apollo

This will install the following packages as devDepencencies

@graphql-codegen/cli
@graphql-codegen/typescript
@graphql-codegen/typescript-graphql-request
@graphql-codegen/typescript-operations
@graphql-codegen/typescript-react-apollo

After installing, we need to configure GraphQL Codegen. I prefer to do this by adding a .yml file to the root of our directory.

$ touch graphql.config.yml

Open up the file and let’s add the following configuration:

schema:
  - "https://rickandmortyapi.com/graphql" 
documents:
  - "./graphql/**/*.graphql"
generates:
  ./generated/graphql.ts:
    plugins:
      - typescript
      - typescript-operations
      - typescript-react-apollo

The configuration file does the following:

schema This points to our GraphQL endpoint for fetching the API schema map.
documents This tells GraphQL Codegen where to look for our schema files
generates This tells GraphQL Codegen where to create and store generated code.
plugins Specifies what GraphQL Codegen plugins to use.

To finalize the setup we also need to add the generation script to our package.json

{
  "name": "next-typescript-graphql-integration",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "lint": "next lint",
    "generate": "graphql-codegen --config graphql.config.yml" 👈 here
  },
  "dependencies": {
    "@apollo/client": "^3.7.7",
    "@next/font": "13.1.6",
    "@types/node": "18.11.18",
    "@types/react": "18.0.27",
    "@types/react-dom": "18.0.10",
    "eslint": "8.33.0",
    "eslint-config-next": "13.1.6",
    "graphql": "^16.6.0",
    "next": "13.1.6",
    "react": "18.2.0",
    "react-dom": "18.2.0",
    "typescript": "4.9.5"
  },
  "devDependencies": {
    "@graphql-codegen/cli": "^3.0.0",
    "@graphql-codegen/typescript": "^3.0.0",
    "@graphql-codegen/typescript-graphql-request": "^4.5.8",
    "@graphql-codegen/typescript-operations": "^3.0.0",
    "@graphql-codegen/typescript-react-apollo": "^3.3.7"
  }
}

If you run yarn generate now you will see an error output like this:

yarn generate
yarn run v1.22.15
$ graphql-codegen --config ./graphql.config.yml
(node:15632) ExperimentalWarning: stream/web is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
✔ Parse Configuration
❯ Generate outputs
✔ Parse Configuration
⚠ Generate outputs
  ❯ Generate to ./generated/graphql.ts
    ✔ Load GraphQL schemas
    ✖
      Unable to find any GraphQL type definitions for the f…
      - ./graphql/**/*.graphql
    ◼ Generate
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

This means the setup is complete and we are ready to add some schema files.

Adding Our Schema File

Starting off, create a folder in the root of the directory called graphql, and inside create a file called get-characters.query.graphql. We already told Codegen where to look for our schemas, but the second filename is up to you.

The folder structure now looks like this 👇

root
--- .next
--- pages
--- public
--- styles
--- graphql 👈 here 🤩

Then inside of the file get-characters.query.graphql, add the query that we previously used, but without wrapping it in a gql template string, like this:

query GetCharacters {
  characters {
    results {
      id
      name
      species
    }
  }
}

And then re-run the generate script, and you will see the following:

yarn generate
yarn run v1.22.15
$ graphql-codegen --config ./graphql.config.yml
(node:16009) ExperimentalWarning: stream/web is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
✔ Parse Configuration
❯ Generate outputs
✔ Parse Configuration
✔ Generate outputs
✨  Done in 7.43s.

Congratulations! We are almost done. Now, check root and you will notice that the script has created a new folder called generated with a file called graphql.ts. This is as we configured in the graphql.config.file.

root
--- .next
--- pages
--- public
--- styles
--- graphql 
--- generated 👈 here 👀

If you inspect that file you can see that we have generated a bunch of types pulled from the API and generated custom React hooks for the query that we authored in get-characters.query.graphql.

GraphQL Codegen in Action

Now that you have Graphql Codegen set up and configured, you can start using it in your React application. Let’s modify index.tsxto the following:

import {
  GetCharactersDocument,
  GetCharactersQuery,
  GetCharactersQueryVariables,
} from "@/generated/graphql";
import { useQuery } from "@apollo/client";
import { NextPage } from "next";

const Home: NextPage = () => {
  const { loading, data } = useQuery<
    GetCharactersQuery,
    GetCharactersQueryVariables
  >(GetCharactersDocument);

  const characters = data?.characters?.results;

  return (
    <div>
      <main>
        {loading && <p>Loading...</p>}

        {characters &&
          characters.map((character, index) => (
            <p key={character?.id ?? index}>
              {character?.name ?? "No name: something is wrong"}
            </p>
          ))}
      </main>
    </div>
  );
};

export default Home;

And now, our data is type-safe and validated. If there was something wrong within the query that didn’t match the API, it would have thrown an error during generation. Now, inside our component, we now have fully typed data, which can be demonstrated by hovering over character.

But where are the custom hooks?

Let’s take it one step further and use the typescript-react-apollo plugin we told GraphQL Codegen to use. This will make our code super clean.

Using Generated End-To-End Type-Safe Apollo Hooks

Let’s clean up our code a little bit to something like this:

import { NextPage } from "next";
import { useGetCharactersQuery } from "@/generated/graphql";

const Home: NextPage = () => {
  // This hook is validated towards the API & will infer 
  // types and throw you type errors if you have not
  // provided the right variables.
  const { loading, data } = useGetCharactersQuery();

  const characters = data?.characters?.results;

  return (
    <div>
      <main>
        {loading && <p>Loading...</p>}

        {characters &&
          characters.map((character, index) => (
            <p key={character?.id ?? index}>
              {character?.name ?? "No name: something is wrong"}
            </p>
          ))}
      </main>
    </div>
  );
};

export default Home;

Look at how neat and clean that is! 🤩 And it’s still typed, too!

For this project to continue API integration, all developers need to do is add new files into the graphql folder and run yarn generate before restarting the dev server. Then, everything gets generated automatically.

One more check to see if it works. Don’t forget to start your development server if you stopped it.

Obviously, this is a very small app so far. Even so, I think I have been able to demonstrate that even at this scale, GraphQL Codegen is a very valuable tool.

Best Practices for GraphQL Codegen

There are some best practices that developers should follow when using GraphQL Codegen:

First, it is important to keep your GraphQL Codegen configuration file up-to-date. This will ensure that the generated code is always accurate. It’s also important to make sure your configuration file is well-structured and easy to understand. This makes it easier for changes in the future.

Second, for production projects, it is important to test your generated code. This ensures the code is working as expected and any errors are caught before they cause problems in production.

Adding In New Functionality With Novu

Showing data is pretty neat, but what if we could aggregate that data and send it to our users?

For this, we can use Novu!

Novu is an open-source notification infrastructure for developers. They make it possible to send notifications though a unified API. With their platform, it’s possible to bundle notification sending into “triggers”.

Managing all notification handlers normally becomes a big chore for us developers as our applications become more complex. Only handling code for email notifications might be doable in a small team, but adding in SMS and push notifications quickly becomes a time drain to get up and running. Which is exactly what Novu intends to help with.

How to Get Started with Novu

The quickest way to get started with Novu is by signing up for their cloud platform. Its totally free, and with a generous free tier of 10k events per month, you’ll have plenty to work with. There is also the option to self-host the platform on your own servers but will require extra work. For this tutorial, we’ll be going with the simpler option through Novu’s cloud platform.

Step 1: Sign Up

After signing up they will ask for an organization name, and then you will be greeted with a welcome screen.

Step 2: Connect the Novu Email Provider

For most providers, Novu sits between them and your application. That means if you are sending an SMS to your user, Novu doesn’t send that, it’s done by your provider.

However, to get started, I recommend using their built-in email provider. It lets you send up to 300 emails, which is plenty for small applications like ours. The emails will come from no-reply@novu.co, and the sending will be the organization name you picked earlier.

Step 3: Create a New Notification Trigger

We also need to define a trigger by going to Notifications in the cloud panel.

Press New and add our trigger.

This is what our settings should look like, but feel free to switch it up if you want:

Then head into the Workflow Editor and configure what happens when triggered.

Add an email field and then enter the email editor to edit the template or any other settings you’d like to add.

Email templates often inject variables with {{ VARIABLE }}. This is how we’ll inject the request payload into our email template. Apply variables in the editor, and you’ll see them show up in the variables box. In this case, {{ name }} and {{ species }} will need to be present in the payload we send to the API. This is what our template should look like:

Press update and see that the payload variables show up in the variables box:

That’s all we need for now! Let’s continue with writing the components and wire everything together. 🪡

Step 4: Create the React Form Component

Let's jump back into the code and create a form to take our users’ email and store it locally.

We will create a folder in root called components, with a file called EmailForm.tsx.

import { FormEvent, useState } from "react";

const EmailForm = () => {
  const [success, setSuccess] = useState<boolean>(false);
  const [email, setEmail] = useState<string>("");

  const onSubmit = (e: FormEvent<HTMLFormElement>) => {
    e.preventDefault();
    // send the email to user
  };

  return (
    <div>
      <p>Send me random character 🚀</p>
      <form onSubmit={onSubmit}>
        <input
          type="text"
          value={email}
          onChange={(e) => setEmail(e.target.value)}
        />
        <button type="submit">Send!</button>
      </form>
    </div>
  );
};

export default EmailForm;

With our form set up and ready to go, we can connect it to the Novu API!

Step 5: Install Novu-client

The easiest way to interact with the Novu API is to install their client package. We can install the @novu/node package from npm by running yarn add @novu/node.

After this, create a folder in root called lib which will hold the logic for interacting with the Novu API. We’ll call it novu.ts, and it’s going to export an async function which we can then re-use.

Then, we’ll head into the Novu Dashboard and grab this Node.js code snippet:

import { Novu } from '@novu/node'; 

const novu = new Novu('<API_KEY>');

novu.trigger('randm-random-email', {
    to: {
      subscriberId: '<REPLACE_WITH_DATA>',
      email: '<REPLACE_WITH_DATA>'
    },
    payload: {
      name: '<REPLACE_WITH_DATA>',
      species: '<REPLACE_WITH_DATA>'
    }
  });

Pretty neat! They’ve done most of the work for us ☕️. Novu adds the payload variables and everything, saving us time from going to the docs.

Now back to the editor:

// lib/novu.ts
import { Novu } from "@novu/node";

const novu = new Novu("<API_KEY>");

type Payload = {
  name: string;
  species: string;
};
export const sendEmail = async (email: string, payload: Payload) => {
  if (!email) throw new Error("No email");

  await novu.trigger("<REPLACE_WITH_TRIGGER_ID>", {
    to: {
            email,
      subscriberId: email,
    },
    payload,
  });
};

This is how the payload should look in the new Payload type, which will be sent to Novu and injected into our email template. Replace API_KEY and TRIGGER_ID with our variables, and we should be good to go!

Note: Before pushing this to git, please make sure you’re using environmental variables, not what’s shown in this tutorial.

Step 6: Create a Next.js API Endpoint

Next.js is a full-stack framework for React, and they make it easy for us to create full-stack apps. One of the most notable features is that we can create API endpoints on our server. These are then hidden from the client browser for extra security.

The way these works is by adding a new file to our pages folder and using the folder structure to define our endpoints. The below structure will create an endpoint at /send-email :

root
--- .next
--- pages
        --- api
                --- hello.ts
                --- send-email.ts
--- public
--- styles
--- graphql 
--- generated

And here’s the code for the handler, where we get our parameters from the request:

import { sendEmail } from "@/lib/novu";
import { NextApiRequest, NextApiResponse } from "next";

const handler = async (req: NextApiRequest, res: NextApiResponse) => {
  // we are only handling post requests.
  if (req.method === "POST") {
    try {
      const { email, name, species } = JSON.parse(req.body);

      if (!email || !name || !species) {
        // return bad request status.
        res.status(400).end();
        return;
      }

      await sendEmail(email, { name, species });

      res.status(200).end();
    } catch (error) {
      // Just response internal server error;
      res.status(500).end();
    }
  }
};

export default handler;

This handler will:

Look at any incoming POST requests to the endpoint
Check if the body of the request has the necessary params
Send the email if everything is correct, or return an error if something is wrong

And that’s all we need for our backend! So let’s add in the client-side.

Step 7: Add Our Email Functionality

Now that we’re back at the client-side, let’s add in the rest of the functionality. We’ll start at the top of the tree in index.tsx and import our EmailForm.tsx component like so:

import { NextPage } from "next";
import { useGetCharactersQuery } from "@/generated/graphql";
import EmailForm from "@/components/EmailForm";

const Home: NextPage = () => {
  const { loading, data } = useGetCharactersQuery();

  const characters = data?.characters?.results;

  return (
    <div>
      <main>
        {loading && <p>Loading...</p>}

        {characters && (
          <div>
            <EmailForm {...{ characters }} />

            {characters.map((character, index) => (
              <p key={character?.id ?? index}>
                {character?.name ?? "No name: something is wrong"}
              </p>
            ))}
          </div>
        )}
      </main>
    </div>
  );
};

export default Home;

That was simple! Let’s finish the implementation in EmailForm.tsx :

import { Character } from "@/generated/graphql";
import { FormEvent, useState } from "react";

type Props = {
  characters: (Character | null)[] | null | undefined;
};

const EmailForm: React.FC<Props> = ({ characters }) => {
  const [email, setEmail] = useState<string>("");

  const onSubmit = async (e: FormEvent<HTMLFormElement>) => {
    e.preventDefault();
    if (characters && characters?.length > 0) {
      // Get random character from the array.
      const random = Math.floor(Math.random() * (characters.length - 1));
      const randomCharacter = characters[random];
      // Make send email request to /api/send-email
      fetch("http://localhost:3000/api/send-email", {
        method: "POST",
        body: JSON.stringify({
          email,
          name: randomCharacter?.name,
          species: randomCharacter?.species,
        }),
      });
    }
  };

  return (
    <div>
      <p>Send me random character 🚀</p>
      <form onSubmit={onSubmit}>
        <input
          type="text"
          value={email}
          onChange={(e) => setEmail(e.target.value)}
        />
        <button type="submit">Send!</button>
      </form>
    </div>
  );
};

export default EmailForm;

This form component will:

Render a text input for email, and store the data in local storage
Submit the data when the button has been pressed
Makes a request to our API which sends a request to Novu.co, which in turn will send en email to the given email address

And that’s it! Now we need to test it out.

Step 8: Send Emails!

If we take a look in the browser at this point, it should look like this:

It’s not pretty, but it’s functional!

Enter your email and see if it shows up in your inbox!

Wrapping It Up

Integrating APIs into a project can be difficult, but it doesn’t have to be. And with GraphQL, it’s easier than ever before! It allows you to set up API integrations with ease and can pair with tools like GraphQL Codegen to automate some of the hassles.

Paired with a powerful notification platform like Novu, you can easily get a project up and running in no time, with notifications and communication options at your disposal.

And the best part? You can do it all for free! No buy-in required. I know I’ll be using Novu in my future, what about you?

Full source code can be found here https://github.com/ugglr/next-typescript-graphql-integration

Helping developers find remote jobs since 2019

Carl-W — Sun, 08 Jan 2023 06:30:01 +0000

TLDR

I just launched a website where I have collected resources for developers to look for remote jobs. There are over 200 companies that work remotely and hire engineers, and then there are some other resources like job boards and online communities.

If this sounds interesting to you do check it out, it's all free, and I'm adding companies and features as time permits.

👉 https://remoet.dev 👈

I also submitted it to ProductHunt if you like the project do consider checking it out there and support it so more people can get access.

👉 https://www.producthunt.com/posts/remoet-dev 👈

If you want to know a little bit of the back story and overall reasoning do continue with this post. 👇

How it started

Back in 2019, I was making the infamous switch to Software Engineering and for location reasons, I had to go remote.

It was a lot of hard work, late nights, tutorials, and janky projects. It almost broke me, and I almost gave up on the idea. Because I was alone, I had no contacts, and being seen on the internet is not easy.

This was pre-pandemic and my perception was that very few companies were adopting the remote model. But I was wrong, and it gave me the confidence to continue grinding.

I wrote my story down here if you are interested: https://dev.to/ugglr/junior-developers-checklist-for-landing-a-remote-job-2ldb

Being in good company

During my job search, I collected all the resources I could find into a Github repo:

https://github.com/ugglr/Remote-Developer-jobs-directory

and the sheer amount of companies who work remotely just blew my mind 🤯 Further this motivated me to keep going 💪 Because every day I could find a new awesome company to apply to or I could circle back to other companies in the list and see if they have any new job postings out.

This proved to be a much more solid strategy than applying through job postings on job boards. Because when you apply directly to a company you interact with them, and not through a middleman.

Job boards are a lottery

I must have applied to thousands of jobs through different job boards and I most often never heard anything back. This is not surprising because there is no friction in applying for a job on those sites. Many times it's a one-click deal and that means each post will be flooded with an ocean of applicants.

This is a problem for both serious applicants but also for employers, because how to shift through that amount of people in a reasonable amount of time?

In my opinion, it's a lottery, and not a valid strategy anymore. The chances of actually getting to interact with the company are close to zero.

What I would do if I was looking for a new remote job?

Do your research. Find companies that resonate with you and fit your general situation. Many companies, even though they are remote, have location restrictions. So pay attention. https://remoet.dev is a good place to start but there are other ways to find remote companies.
Check their careers page directly, look for jobs that apply to you, and organize a strategy for applying to them. Every company's application process will be slightly different.
Try to network with people who work inside the companies. Twitter is a great place to start building connections and is one of the most important tools for developers to create a virtual network. Comment on posts, be helpful, and hopefully, you can ask for a referral when an opening comes around.
Create content about your journey, it might include learnings in form of blog posts, or it might be vlogs uploaded on youtube or even just Twitter. It will make you stand out, but remember the point is to make an honest representation of who you are. I don't recommend adopting an over-the-top persona that is not genuine.
Build projects with a wide variety within your code niche. If you managed to gather attention, you also need to show that you got the skills, because, by the end of the day, that's what matters. Your job is to create value and solve problems with code.

That's all I have to say for now.

Support the project

Check out the site https://remoet.dev and if you think it might be helpful for others consider sharing it within your network. The more people use it the more I'm motivated to create new helpful features.

Support us on Producthunt https://www.producthunt.com/posts/remoet-dev Check us out and maybe even share it with your friends.

The original repo is still up: https://github.com/ugglr/Remote-Developer-jobs-directory If you are more inclined to stay on Github that's a good resource as well (although some things might be outdated by now).

Thanks for reading 🤓 Happy job hunting.

Events driven analytics service powered by Mongo Atlas

Carl-W — Sun, 09 Jan 2022 09:24:41 +0000

Overview of My Submission

When utilising MongoDB Atlas charting tools one can with little code create an events driven analytics service. It's a magical feature where we can get charts with data straight from the DB.

By creating your own service we can keep as much or as little of our users data as we want in-house without worrying about sharing sensitive information with third party products or services. It is also possible to extend the service endlessly to fit all types of applications, or with further request relay mechanisms. For instance relaying events to Facebook conversion API.

And since we are just making post requests over http our clients can be very thing, without pulling in any external SDKs or big npm packages.

There are two parts to my submission:

The backend - which collects all the events and stores them into mongodb atlas
The example app - The app mimics a regular landing page with a couple of CTA buttons and navigation.

The Backend

The backend consists of a Nest.js server running graphql where the events get's stored into mongodb. It's nothing fancy it's just a create function for the events.

One thing of note is that there is no resolver / query where one can get the events out from the server. So it's completely blocked from the outside world. Events goes in but events cannot be queried.

Except in mongodb charts where we grant a service account read rights to make the charts. So there's no need to do any data aggregation on the server, mongodb atlas handles that for you, and with a little bit of getting used to even non-coding people in the organisation can make charts at their will.

The example app

This part of the submission is just a simple landing website with two pages written in react.

On the first page (home), there are a few elements which are common to all websites where the user takes some type of action and where we want to track the analytics.

I've added sending tracking events on the CTA buttons, and the navigation.

And the events are called:

CTA1 clicked!
CTA2 clicked!
CTA3 clicked!
Navigation: home
Navigation: analytics
Navigation: logo

These are the events that then makes up the charts on the analytics page.

On the second page (analytics), there is an Analytics page where I display the use of the events by using MongoDB Atlas charting functionality. The charts are created in the mongodb atlas cloud website and then embedded into the page using iframes provided by the charting tools.

This is really cool because to make new charts does not require any coding, and can me made on the fly, or in personal dashboards, or as in this case embedded into any website. One can aggregate the data right on the dataset, while none of the events are query-able from the server.

Submission Category:

Own Adventure (I think 🤔)

Link to Code

ugglr / dev-mongodb-hackathon

Events driven analytics service created with MongoDB, TS, Nest.js and caffeine

dev.to MongoDB Hackathon project

By using MongoDB charting tools it's easy to setup ones own events driven analytics server. It's flexibility is far superior than using a SAAS, all the while keeing your users data safe and secure and not sharing it to any third partys unknowningly.

Demonstration Links:

backend: https://devmongo.herokuapp.com/
frontend: https://goofy-galileo-d36254.netlify.app/

Built with

nest.js
mongodb
mongoose
graphql
apollo server + client
react
typescript

A progressive Node.js framework for building efficient and scalable server-side applications.

Description

Nest framework TypeScript starter repository.

Installation

$ npm install

Running the app

# development
$ npm run start

# watch mode
$ npm run start:dev

# production mode
$ npm run start:prod

Test

# unit tests
$ npm run test

# e2e tests
$ npm run test:e2e

# test coverage
$ npm run test:cov

Support

Nest is an MIT-licensed open source project. It can grow thanks to the sponsors and support by the…

View on GitHub

Additional Resources / Info

[Note:] # (Be sure to link to any open source projects that are using your workflow!)

I wrote the service using Nest.js for the backend, and react for the frontend.

nestjs / nest

A progressive Node.js framework for building efficient, scalable, and enterprise-grade server-side applications with TypeScript/JavaScript 🚀

A progressive Node.js framework for building efficient and scalable server-side applications.

Description

Nest is a framework for building efficient, scalable Node.js server-side applications. It uses modern JavaScript, is built with TypeScript (preserves compatibility with pure JavaScript) and combines elements of OOP (Object Oriented Programming), FP (Functional Programming), and FRP (Functional Reactive Programming).

Under the hood, Nest makes use of Express, but also provides compatibility with a wide range of other libraries, like Fastify, allowing for easy use of the myriad of third-party plugins which are available.

Philosophy

In recent years, thanks to Node.js, JavaScript has become the “lingua franca” of the web for both front and backend applications, giving rise to awesome projects like Angular, React, and Vue, which improve developer productivity and enable the construction of fast, testable, and extensible frontend applications. However, on the server-side, while there are a lot of superb libraries…

View on GitHub

facebook / react

The library for web and native user interfaces.

React ·

React is a JavaScript library for building user interfaces.

Declarative: React makes it painless to create interactive UIs. Design simple views for each state in your application, and React will efficiently update and render just the right components when your data changes. Declarative views make your code more predictable, simpler to understand, and easier to debug.
Component-Based: Build encapsulated components that manage their own state, then compose them to make complex UIs. Since component logic is written in JavaScript instead of templates, you can easily pass rich data through your app and keep the state out of the DOM.
Learn Once, Write Anywhere: We don't make assumptions about the rest of your technology stack, so you can develop new features in React without rewriting existing code. React can also render on the server using Node and power mobile apps using React Native.

Learn how to use React…

View on GitHub

Some other open source packages that I used:

mongoose
Graphql
apollo server & client

The deployment is powered by heroku and netlify.

Hope you like what I've built!

Step 3: Setting up Storybook with React Native Web: show your mobile components the browser!

Carl-W — Sat, 31 Oct 2020 05:52:58 +0000

In the last part of this series it's finally time to use what we installed in the first two parts and use everything together!

If you have not been following along please go and have a look at the first parts in this series!

Article	Link
setup react native & @storybook/react-native	Step 1: Setting up React Native with Storybook
setup react from scratch together with react native web	Step 2: Setting up react with react native web
setup @storybook/react + react native web to run as a parallel storybook	You are here now!

Starting point

To just do a quick recap I want to state where we are at at this point in our journey.

After Step 1, was completed we had a running React Native project with Storybook installed. It means when we run the code we have a storybook installation, which listens to the storybook development server for react native. Further we have react-native-storyloader set up. It loads our Storybook stories files for us when we run the dev command.
After Step 2, we have in parallel a detached vanilla React project set up, with it's own webpack configuration, which is also using react native web.

So! what do we do now?! 🤷‍♂️

Manually installing Storybook for React.js 🤸‍♂️

For our repos web alter ego React.js installation we need to install Storybook, and since this was initiated as a React Native project we need to do that manually.

It's pretty straight forward and is described well in the storybook docs here: Storybook Docs: React.js Guide. Edit: WAS well described They changes the docs....

Let's go through the steps:

1.) at the root run the command in your terminal: 🚀

$ npx sb init --type react -f

--type react tells the Storybook CLI to install stuff for a react project
-f Forces the installation, because the CLI will detect the react native installation and abort the installation without the face flag.

If everything completes properly you will see a newly created .storybook folder in the root of you project and a .stories folder added to your .src folder. Further it added a couple of scripts, and @storybook/react + react-is packages was installed + added to your devDependencies in your package.json.

2.) Add our scripts to `package.json` 🚀

It's a habit of mine to add scripts first, because it reminds me of what I'm trying to accomplish. All this work is because I want to run a script and something should happen right.

The Storybook CLI might overwrite some of the scripts already present in your package.json, I fiddled around a bit and landed on this final version for my scripts:

  "scripts": {
    "android": "yarn run prestorybook && react-native run-android",
    "ios": "yarn run prestorybook && react-native run-ios",
    "start": "react-native start",
    "test": "jest",
    "lint": "eslint .",
    "prestorybook": "rnstl",
    "storybook": "start-storybook -p 7007",
    "build-react": "webpack --mode production",
    "start-react": "webpack-dev-server --config ./webpack.config.js --mode development",
    "start-storybook-web": "./node_modules/@storybook/react/bin/index.js",
    "build-storybook-web": "./node_modules/@storybook/react/bin/build.js",
    "storybook-web": "yarn run start-storybook-web",
  },

The one we are focusing on right now are the start-storybook-web, build-storybook-web and storybook-web. The previous scripts we covered in the first two steps in the series.

3.) [Optional] Test our React.js Storybook installation before modifying it. 🚀

At this point we already have React Native component(s) inside of src/components and they cannot be rendered by Storybook as it is right now. To see that error in action you can right now run the script, by typing this command in your terminal:

$ yarn start-storybook-web

The error looks like this for me:

ERROR in ./node_modules/react-native-swipe-gestures/index.js 121:11
Module parse failed: Unexpected token (121:11)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders

However we can try our installation on the test components the Storybook CLI added for a React.js project inside of src/stories.

so open the file .storybook/main.js and change the stories array

From

module.exports = {
  "stories": [
    "../src/**/*.stories.mdx",
    "../src/**/*.stories.@(js|jsx|ts|tsx)"
  ],
...
}

module.exports = {
  "stories": [
    "../src/stories/**/*.stories.mdx",
    "../src/stories/**/*.stories.@(js|jsx|ts|tsx)"
  ],
...
}

and then run the script:

yarn start-storybook-web

and it should compile! Behold! 🥳

4.) Adding our React Native Stories to Storybook 🚀

Close any instances and let's start adding our react native stories to our Storybook React.js setup.

Again let's modify .storybook/main.js to load our React Native written components and *.stories.js files.

From the above stories configuration

  "stories": [
    "../src/stories/**/*.stories.mdx",
    "../src/stories/**/*.stories.@(js|jsx|ts|tsx)"
  ],

stories: ['../src/components/**/*.stories.[tj]s'],

Note that I removed the .mdx files, I don't use that

Again, running the yarn start-storybook-web script will result in an error, because we have not configured the React.js Storybook installation to use React Native Web yet in a custom Webpack config.

so let's do that!

5.) Add a custom Webpack configuration to Storybook 🚀

Storybook already comes with a Webpack configuration which we don't really want to modify, but rather inject our own stuff into. And since we already what we want to configure, as described in Step 2 of the series, where we got React Native Web working with React.js, we have ALMOST all the stuff we want to inject into the Storybook webpack configuration already prepared. (We are missing one alias soon to be described)

So where do we inject our stuff?

open .storybook/main.js and at the top of the file import our webpack configuration like this:

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

and then in the module.exports = { ... } add an entry called webpackFinal like this:

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

module.exports = {
  stories: ['../src/components/**/*.stories.[tj]s'],
  webpackFinal: (config) => {
    return {
      ...config,
      resolve: { alias: { ...config.resolve.alias, ...custom.resolve.alias } },
      module: { ...config.module, rules: custom.module.rules },
    }
  },
}

In this way we don't overwrite, or destroy the Webpack configuration that Storybook already comes with, but rather we inject our own alias rules and our own module.rules into it.

Note: yes yes I removed the addons array

Also let's not forget that we need to modify our webpack.config.js because we want atleast more things in our aliases:

all @storybook/react-native imports should resolve to @storybook/react

because in the React Native side we are always using the import from @storybook/react native and obviously that's not what we want on the web side of Storybook. First the component go through React Native Web so there is no trace left of React Native Code in them after being compiled, and then we want to run Storybook as "normal" on them.

const path = require('path')
const HTMLWebpackPlugin = require('html-webpack-plugin')

const HTMLWebpackPluginConfig = new HTMLWebpackPlugin({
  template: path.resolve(__dirname, './public/index.html'),
  filename: 'index.html',
  inject: 'body',
})

module.exports = {
  entry: path.join(__dirname, 'index.web.js'),
  output: {
    filename: 'bundle.js',
    path: path.join(__dirname, '/build'),
  },
  resolve: {
    alias: {
      'react-native$': 'react-native-web',
      '@storybook/react-native': '@storybook/react', //<-here
    },
  },
  module: {
    rules: [
      {
        test: /\.js$/,
        exclude: /node_modules\/(?!()\/).*/,
        use: {
          loader: 'babel-loader',
          options: {
            presets: ['@babel/preset-env', '@babel/preset-react'],
          },
        },
      },
    ],
  },
  plugins: [HTMLWebpackPluginConfig],
  devServer: {
    historyApiFallback: true,
    contentBase: './',
    hot: true,
  },
}

and if that is super confusing to you please read Step 2, where I try my best to explain the webpack part 😅

Let's try our yarn start-storybook-web script again and see if it runs!

yarn start-storybook-web

🚀🚀🚀🚀🚀🚀 BEHOOOLD! 🚀🚀🚀🚀🚀

Adding Styled components to webpack

Just for the ones of us that want's to use styled components when we create our react native components, add this line to your aliases in the webpack config and it should hook right in 👨‍💻

'styled-components/native': 'styled-components',

so aliases look like this:

    alias: {
      'react-native$': 'react-native-web',
      '@storybook/react-native': '@storybook/react',
      'styled-components/native': 'styled-components',
    },

Fin!

Hope this was educational and a little cool!

Now you can host a static website with your React Native components, or you can actually develop them in a browser without firing up a simulator / emulator. Which is really niiiiiiice, especially if you are running on an older machine!

See the full repo here! --> Github: react-native-storybook-boilerplate

I got it hosted on Netlify, and again, the components are all written in React Native syntax!

Hosted Boilerplate

The other parts again!

Step	Link
Series: The ultimate react native ui library starter repo	Step 0 link
Step 1: Setting up react native with Storybook	Step 1 link
Step 2: Setting up react with react native web	Step 2 link

Thanks! 🎉

Publish/Update NPM packages with GitHub Actions

Carl-W — Tue, 15 Sep 2020 14:58:40 +0000

Ever had an NPM package that never get's updated even though you make changes from time to time. I do! which I talked about in a previous post: cross-platform-react-native-scroll-picker-component. It's time to make my life just slightly easier and automate the publish step with Github Actions.

Since the release of GitHub Actions everyone I know have been raving about them, so In an attempt to learn a little bit, and solve a problem I have, I thought I could try it out :)

oh and here's the official GitHub Actions docs: GH Actions Docs

Goal

It's important to know what you want to do, before starting configuring (or.. doing anything, really!). For me it's going to be something quite simple, but very useful.

This is my starting point and what I want to achieve:

I have an open source package which is published to NPM
- NPM: react-native-value-picker
- Github: react-native-value-picker
When I make a new "official" release on Github I want to update / re-publish this package, so my updates go live.

To do this manually we need to login in and publish/re-publish through the NPM CLI, something like this:



# Authenticating with npm
$ npm login

# Publish the package
$ npm publish

I know, I know, it's not a massive amount of work to do those two steps each time I want to push out an update to the package, but we are learning something here.

Prior to GitHub Actions in order to automate this task, I would have needed to involve a third party CI/CD solution, and on top, it's free.

So let's get started with the config.

Preparing our repo to use GitHub Actions

The execution chains or jobs which we want to run inside of our GitHub Actions are called workflows.

So GitHub will look inside .github/workflows for workflows / execution chains so let's make a .github folder inside of our root, this folder is common if there are special configurations to the repository, like code owners. Further we need to make a folder inside our .github folder called workflows.

When all is done you'll have a a root/.github/workflows folder.

Like most CI/CD solutions GitHub Actions workflows are configured using a .yml file, and we need to put that that file into the workflow folder we created above. I named my yml-file npm-publish.yml and here's a badly made folder-tree to make it more clear.



---> root
|   ---> .github
|      ----> workflows
|          ----> npm-publish.yml // contains our workflows.
| ----> rest of app

Configuring our workflow

So inside of our npm-publish.yml we are good to go configuring our workflow. I'll post the finished thing first and then I'll go through it step by step what it does.



name: Npm Publish

on:
  release:
    types: [published]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v1
        with:
          node-version: 12
          registry-url: https://registry.npmjs.org/
      - run: yarn install
      - run: npm publish --access public
        env:
          NODE_AUTH_TOKEN: ${{secrets.NPM_AUTH_TOKEN}}

Let's break it down



name: Npm Publish

Giving the workflow a name, at the very top we give the encompassing workflow a name that makes sense to us, you are free to name it anything you'd like :)



on:
  release:
    types: [published]

The on-keyword tells GitHub when the workflow is going to run, in this case I specify that I want it to run when there is a new release, and more specifically I want it when the release type is published. This is important and required because releases could also be updated or deleted. This makes sure that we run on release publish only.



jobs:
  build:
    runs-on: ubuntu-latest

The jobs keyword tells our CI the different steps we want to execute.

In this case I want to build the project, on the latest version of Ubuntu, so that is specified as ubuntu-latest.

Further we need to define the steps within our job:



   steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v1
        with:
          node-version: 12
          registry-url: https://registry.npmjs.org/
      - run: yarn install
      - run: npm publish --access public

Inside of our job we are now defining the steps, We already defined the operating system of our virtual machine / box, so we are at the same stage as when we run the project locally on our computer.

Well, in plain English, what do we do locally when we run a project like this?

Normally it would look something like this in our terminal:

1. Clone our project



$ git clone git:repo-address

2. Install all packages / dependencies



$ yarn install

3. do the publishing steps



$ npm login
$ npm Publish

Locally we already have our development environment setup, we already have node, yarn, etc. But because we are essentially creating a new computer on Githubs servers running Ubuntu we need to be more specific, and that's what we are doing in the configuration file:

1. Clone the repo.



- uses: actions/checkout@v2

2. Install node on a known working version, Specify what package registry we want to use.



    - uses: actions/setup-node@v1
        with:
          node-version: 12
          registry-url: https://registry.npmjs.org/

3. Install dependencies



- run: yarn install

4. Publish to NPM



- run: npm publish --access public

5. Further since there is no human sitting and looking at the script to authenticate us by passing in username and password, we need to pass a pre-authenticated token to our node environment



        env:
          NODE_AUTH_TOKEN: ${{secrets.NPM_AUTH_TOKEN}}

And that's our new Github Action workflow configuration all done 🎉

Hold on! you might say, what about that NPM Auth token thingy?

Let's get that configured next.

Configuring Auth tokens

As I described earlier we need a pre-authenticated token to pass into our node environment. This is the way we authenticate towards NPM, and it's not very complicated to setup.

Never put your token into the configuration file, it should be kept private

Note: I presume you have an account on npmjs.org if you are interested in following along.

Head on over to your account in npm and in the quick account menu press Auth Tokens

Inside the Auth Token page you'll want to create a new Token.

You will then be prompted if you want to grant the token read and publish or just read, for the purpose in this case we need to have publishing rights, so read and publish it is.

After the token has been created copy it, and make sure you can keep it with you for a little while until we add it into our repository secrets.

Adding NPM token to our repository

Head over to your GitHub repository where your package exists and go to the settings page.

Inside of settings head on over to the secrets sub-page.

Click Create a new Secret

And in here you'll want to match the name of the token with what we wrote in our action configuration file.

In our case we named our secret variable reference NPM_AUTH_TOKEN and then you'll want to paste the token you got from NPM in the value field.

When everything is well and done we will have it added.

That's all we need for configuration, commit it, merge into master and let's try it out to see if it works.

Testing it out

So, to test our newly created workflow we need to make a new release (published), since that what we configured it to trigger on.

It does not really matter what you tag you choose for the release, but make sure the that the pre-release checkbox is not checked. And you bumped the version in package.json, NPM requires us to update the version when we publish changes.

When the release is done let's head on over to our repository's action tab and see if we have something running!

there we go, microphone drop.

End

If you like to visit the repo I've been working in it's available right here:

ugglr/react-native-value-picker

The package is available through NPM:

NPM: react-native-value-picker

And the creation of that package was part of a previous post right here:

DEV.to Cross platform react native scroll picker

Thanks for reading!

Step 2: Setting up React with React-Native-Web

Carl-W — Thu, 13 Aug 2020 04:31:50 +0000

In our pursuit of creating the ultimate UI development starting point, it is time to take the first step with react-native-web

This is the second part of a series where I go through all the steps of creating The Ultimate React Native UI Library starter repo. Please visit the first post (just linked 👆🏻) for a general description of what we are trying to accomplish and where all the Steps are numbered + linked.

The finished source code can be found here react-native-storybook-boilerplate

The other parts

Article	Link
setup react native & @storybook/react-native	Step 1: Setting up React Native with Storybook
setup react from scratch together with react native web	You are here now!
setup @storybook/react + react native web to run as a parallel storybook	Step 3: Setting up storybook with react native web: Show your mobile components in a browser

What's covered in this post? ->

setting up react from scratch
- installation
- webpack
- babel
setting up react-native-web
- installation
- webpack alias configuration

Please note that this is not a webpack or babel tutorial so I will more or less not cover the basics of those

If you want to go really in depth in how to set up React from scratch I really recommend a tutorial series from codecademy:

I thought that series was very good.

Setting up React - Installing our dependencies

If you are following along from the first part in the series you have a "normal" react-native and storbook already set up and running locally, and now it's time to add React into the mix.

installation

Obviously we need react, but it comes with the react-native installation but we need to add react-dom ->

yarn add react-dom

and then we need to install our babel dependencies babel

yarn add --dev @babel/core babel-loader @babel/preset-react @babel/preset-env

Then we also need to ochestrate the packaging so let's install webpack also while we are at it:

yarn add --dev webpack webpack-cli webpack-dev-server html-webpack-plugin

Add scripts to package.json

You can do this in any order you like but, I for some reason, like to add scripts first. I think it gives me a sense of what I'm trying to acomplish.

"scripts": {
  ...
  "build-react": "webpack --mode production",
  "start-react": "webpack-dev-server --config ./webpack.config.js --mode development",
  ...
}

You obviously can name the scripts anything you like & makes sense to you: I named my scripts start-react & build-react.

Configure Webpack

This is where the magic happens 🤹🏻‍♀️ In the root folder add a webpack.config.js file and add the folowing:

const path = require('path')
const HTMLWebpackPlugin = require('html-webpack-plugin')

const HTMLWebpackPluginConfig = new HTMLWebpackPlugin({
  template: path.resolve(__dirname, './public/index.html'),
  filename: 'index.html',
  inject: 'body',
})

module.exports = {
  entry: path.join(__dirname, 'index.web.js'),
  output: {
    filename: 'bundle.js',
    path: path.join(__dirname, '/build'),
  },
  module: {
    rules: [
      {
        test: /\.js$/,
        exclude: /node_modules\/(?!()\/).*/,
        use: {
          loader: 'babel-loader',
          options: {
            presets: ['@babel/preset-env', '@babel/preset-react'],
          },
        },
      },
    ],
  },
  plugins: [HTMLWebpackPluginConfig],
  devServer: {
    historyApiFallback: true,
    contentBase: './',
    hot: true,
  },
}

for a better description of what's going on I really recommend this article from codecademy React Setup, Part III: Webpack

Here's a rough description:

entry	what it does
entry	Tells Webpack the root file of our application. Starting from that file it will go through the whole tree and transform all code which match our webpack rules. I've named this file `index.web.js` we need to remember to create this file.
output	Configuration for the output files from react. `filename` gives the packed javascript a name. `path` sets an output folder for the packed files
rules	`test` is a regular expression which matches to our source files, i.e. `*.js`. `exclude` excludes files we don't want webpack to touch. `use` this is where we plug in `babel` i.e. the stuff that will transform our react code into vanilla js.

After webpack are dont with the JS it needs to make a new HTML file as well, that's where HTMLWebpackPluginConfig comes in, please refer to this article for a better description: React Setup, Part IV: HTMLWebpackPlugin.

Let's take a look at the code for the HTMLWebpackPlugin closer:

const HTMLWebpackPluginConfig = new HTMLWebpackPlugin({
  template: path.resolve(__dirname, './public/index.html'),
  filename: 'index.html',
  inject: 'body',
})

template: It tells our plugin what template file it should use and copy to our ./build folder. I set it to a file in the folder public and the file name is index.html. (We shall not forget to create these.)
filename: Is the name of the newly created file which it copies. As I mentioned above this file will wind up in ./build folder.
inject: Is where the our JavaScript script tag will be injected. Both head and body are valid options.

What's the path stuff?
It's just a way to concatenate path-strings instead of using a +sign, __dirname meaning the current directory which the file is in.

Add entry files

Add public `index.html`

As I've configured the HTMLWebpackPlugin, and shortly explained right above, we need to add a index.html into a folder called public,

So! In root create a folder called public and inside of that folder create a file called index.html and the following html

<!DOCTYPE html>
<html>
  <head>
    <title>React Native Web Storybook</title>
  </head>
  <body>
    <div id="app"></div>
  </body>
</html>

Take notice of the id-name (app) of the div where we are injecting the react single page application. All of these files are react boilerplate which are basically the same when using the library.

Add index.web.js

In the root add index.web.js and code the following:

import React from 'react'
import ReactDOM from 'react-dom'

import App from './App.web'

ReactDOM.render(<App />, document.getElementById('app'))

this is where <div id="app"></div> needs to match document.getElementById('app')

If you've used create-react-app before you'll see that it's basically the same code as they generate for you, in our case I wan't to keep web react seperate from react-native so I named the file with the extension .web.js.

From the code we also see that we need to add our <App /> component, so let's do that next:

Add App.web.js

In the root add App.web.js, this will be the entry component for react, and add the following code:

import React from 'react'

function App() {
  return (
    <>
      <h1>Hello world from react</h1>
    </>
  )
}

export default App

As you can see this is normal jsx, we will come to adding react-native-web after we confirm that our vanilla react setup works first.

Test our React configuration

It's time to check if we are able to run everything together so let's run our script:

yarn start-react

Hopefully this starts the Webpack development server for you and you see this page:

Great Success Time to add React-Native-Web into the configuration!

Install React-Native-Web

For those who are not quite familiar react-native-web makes it possible to use the react-native-api to write components for the web. It transforms View to div etc. so it's readable by a web browser. Really cool stuff!

"React Native for Web" makes it possible to run React Native components and APIs on the web using React DOM.

It's open source and do check it out!
react-native-web

Installation

yarn add react-native-web

When that's done we need to modify our webpack configuration so it swaps out all our react-native imports for react-native-web.

Re-configure webpack.config.js

so it our awesome webpack file let's add the following lines:

module.exports = {
  ...
  resolve: {
    alias: {
      'react-native$': 'react-native-web',
    },
  },
  ...
}

That's enough configuration for now!

Let's modify our App.web.js to use the react-native-api.

import React from 'react';
import {View, Text} from 'react-native';

function App() {
  return (
    <View>
      <Text>Hello world from react native</Text>
    </View>
  );
}

export default App;

run yet again:

yarn start-react

and BEHOLD!

With this we can now use the whole react-native-api for the web, you can have a look here: React-Native: Core Components and APIs

To extra check this we can, for instance, add an <ActivityIndicator /> component to our App.web.js

import React from 'react';
import {View, Text, ActivityIndicator} from 'react-native';

function App() {
  return (
    <View>
      <Text>Hello world from react native</Text>
      <ActivityIndicator />
    </View>
  );
}

export default App;

And here's the result!

That's it for this part in the series!

Thanks for reading and again, you can find the finished project here: react-native-storybook-boilerplate

Step 1: Setting up React Native with Storybook

Carl-W — Sun, 02 Aug 2020 03:18:18 +0000

This is the first post in a series of setting up a react native UI library development foundation. Please refer to the link collections here Series: The Ultimate React Native UI Library starter repo for the full series overview.

In the first step of setting up the ultimate UI library boilerplate we go through making a new init, and installing Storybook.

If you've done this sort of thing before you'll probably want to jump to the bottom where I install a package which will load stories dynamically

Oh right, I'm not using expo... ;)

The other parts

Article	Link
setup react native & @storybook/react-native	You are here now!
setup react from scratch together with react native web	Step 2: Setting up react with react native web
setup @storybook/react + react native web to run as a parallel storybook	Step 3: Setting up storybook with react native web: Show your mobile components in a browser

React Native Init

If you are completely new to react native please follow the steps on the official react native docs to get your environment setup.

Init



npx react-native init RNStorybook

This will set up a fresh new react native project for you.

Make sure that the installation was successful by running both the android and iOS builds of the project before going ahead. I always take things step by step, so when things bug out then I know exactly where it worked and where it broke.

so for the people who forgot etc. here's the commands for doing so.



cd ios && pod install

cd .. 

yarn run ios



yarn run android

Behold the welcome screen!

Android	iOS

Installing Storybook

Using the automated setup as recommended by the docs here: Storybook quick-start guide

inside the root folder run the following command to initiate the installation:



npx -p @storybook/cli sb init

When prompted if you want to install the react-native server accept.

After that open up your code editor and we will do the final steps in rendering storybook out on the screen.

inside the folder ./storybook open up index.js and we will add in our app name. You can either add it manually or you can be lazy as me and import the app name from app.json in the root folder. It has the benefit that if the app name changes you won't need to go in and change it manually.

Below is the result:

./storybook/index.js



import {AppRegistry} from 'react-native';
import {getStorybookUI, configure} from '@storybook/react-native';
import {name as appName} from '../app.json';

import './rn-addons';

// import stories
configure(() => {
  require('./stories');
}, module);

// Refer to https://github.com/storybookjs/storybook/tree/master/app/react-native#start-command-parameters
// To find allowed options for getStorybookUI
const StorybookUIRoot = getStorybookUI({});

// If you are using React Native vanilla and after installation you don't see your app name here, write it manually.
// If you use Expo you can safely remove this line.
AppRegistry.registerComponent(appName, () => StorybookUIRoot);

export default StorybookUIRoot;

after we have added our app name to Storybook, inside of the root folder, we open index.js. This is the default entry point for our React Native app.

Inside of ./index.js comment everything out and add the following line:



export { default } from './storybook'

This will render storybook as the first entry to your app, but later if you want Storybook to be rendered inside of a tab-view or another type of screen you'll just add storybook as any other component. More on that in the Storybook docs.

Now when you run the following command we can start up our React Native development server on port 7007:



yarn run storybook

It will give you the following screen:

Hold your horses you might say "That menu-bar never stops loading!" and you'll be right. This web interface is trying to connect to a iOS or Android emulator.

so run an emulator and if you put the browser window and the device side by side it should look like:

If you play around with this you notice that you can control the view which is being shown in the emulator / simulator from the browser. Neat right! ⭐️ It's a nice feature which makes navigating your component library on a device very fast and easy.

Setting up dynamic story-loading

As your project grows you don't want to add stories into storybook manually as is the default. It's tedious and you'll spent time "debugging" why your component does not show up.

In comes react-native-storybook-loader

I really like this project because after setting it up I don't have to worry about adding any new stories every again.

Setup

Install



yarn add -dev react-native-storybook-loader

Add script to package.json



{
  "scripts": {
    ......
    "prestorybook": "rnstl"
    ......
  }
}

Add into Storybook configuration

Open up ./storybook/index.js and modify the entry where the stories are loaded from:

./storybook/index.js



import { AppRegistry } from 'react-native'
import { getStorybookUI, configure } from '@storybook/react-native'
import { name as appName } from '../app.json'

import { loadStories } from './storyLoader'

import './rn-addons'

// Add React native storybook loader here!
configure(() => {
  loadStories() // <------------------
}, module)

// Refer to https://github.com/storybookjs/storybook/tree/master/app/react-native#start-command-parameters
// To find allowed options for getStorybookUI
const StorybookUIRoot = getStorybookUI({})

// If you are using React Native vanilla and after installation you don't see your app name here, write it manually.
// If you use Expo you can safely remove this line.
AppRegistry.registerComponent(appName, () => StorybookUIRoot)

export default StorybookUIRoot

Configure story loader

The last step in setting up react-native-storybook-loader is configuring in which directory it should look for stories.

Open up package.json again and add a config field:



"config": {
    "react-native-storybook-loader": {
      "searchDir": ["./src/components"],
      "pattern": "**/*.stories.js",
      "outputFile": "./storybook/storyLoader.js"
    }
  }

I wan't it to look inside of the ./src/components directory but you can set it up to look in a different folder, or even add more places it should look in by adding them into the searchDir array. If you change the other fields you'll need to change your other config to match accordingly.

Adding Test component

To test that this part of the setup works lets add a test component and check so everything works.

I'm making a new directory called src and inside of the directory I'm adding a folder called components -> ./src/components

and in these files I'm adding two new files called TestComponent.js & TestComponent.stories.js and let's code a test component and add a story for storybook.

./src/components/TestComponent.js



import React from 'react';
import {View, Text} from 'react-native';

function TestComponent() {
  return (
    <View>
      <Text>Hello from React Native</Text>
    </View>
  );
}

export default TestComponent;

and a story for storybook

./src/components/TestComponent.stories.js



import React from 'react';
import {storiesOf} from '@storybook/react-native';

import TestComponent from './TestComponent';

storiesOf('Test Component', module).add('example', () => <TestComponent />);

Note that while using react native we have to use the storiesOf api from Storybook.

Running everything together

Let's test it out on your device of choice!

yarn run iOS

This will first run the react-native-storybook-loader script. It will output a reference to all the files matching the pattern *.stories.js inside ./src/components to ./storybook/storyloader.js and load them into Storybook. After that it's running storybook as normal.

Here's what you should see:

Hopefully you'll see the test component on the screen.

Success!

What did we accomplish:

initiated a new react native project.
installed @storybook/react-native.
installed @storybook/react-native-server.
installed & configured react-native-storybook-loader.
Added our first test component and story.

If you like this content please bookmark the init post of this series here and stay tuned for part 2!

You can find the finished repository for the whole series on Github: react-native-storybook-boilerplate

Consider giving it a star or raising an issue, PRs are most welcome!

Series: The Ultimate React Native UI Library starter repo

Carl-W — Fri, 24 Jul 2020 11:59:06 +0000

If you are developing in React native chances are you are sitting on a personal UI library which you copy & paste between projects. Would it not be great to document, and publish the components online?

This is the collection post where I'm starting a series. With the goal to setup a repo which can be forked and then makes a very compelling case (in my opinion) for starting development of your own React Native UI library.

The parts I'm going to be covering:

Article	Link
setup react native & @storybook/react-native	Step 1: Setting up React Native with Storybook
setup react from scratch together with react native web	Step 2: Setting up react with react native web
setup @storybook/react + react native web to run as a parallel storybook	Step 3: Setting up storybook with react native web: Show your mobile components in a browser

I've already written out the code so this is a way for me to document how this repo was made, and for others to follow along.

If you want to jump straight into the code here's the repo react-native-storybook-boilerplate

Here's a hosted version of what I'm building: hosted site

Roughly what's going to be done

In a nutshell there's two different setups of Storybook running in parallel:

React Native + Storybook/React-Native

It was installed following the normal steps of

doing a fresh npx react-native init
running npx -p @storybook/cli sb init and choosing yes when asked if install @storybook/react-native-server
installing & configuring react-native-storybook-loader the project can be found here: react-native-storybook-loader

React + Storybook/React

This installation is less obvious because we have to setup react from scratch, configure babel & webpack, whereas in the webpack.config.js we need to resolve and apply aliases for our imports, so react-native becomes react-native-web. This needs to be done with other packages as well, in this boilerplate I have installed styled-components, i.e. styled-components/native imports needs to be switched out to styled-components when we bundle for the web.

It was roughly done like this:

Installing react, react-dom, babel & webpack dependencies
Configuring webpack to alias react-native with react-native-web, and styled-components/native should resolve to styled-components. See the full webpack config here: webpack.config.js also: babel config here: babel.config.js
Installing Storybook according to the manual guide in the docs React Storybook Manual Installation Steps
Inside of ./.storybook/main.js configure custom webpack for Storybook, see docs here: Storybook custom webpack docs, from my webpack.config.js I grab the alias configuration and plug it into Storybook.
Since Storybook does not support the new syntax of writing stories for React Native I needed to add one more alias where @storybook/react-native resolves to @storybook/react

Stay tuned for the write-up!

React Native: Getting user device timezone and converting UTC time-stamps using the offset.

Carl-W — Fri, 19 Jun 2020 12:37:33 +0000

Recently I was tasked to convert all backend generated timestamps from the default UTC to our users device timezone. This is my process of how I encountered some issues along the way and how I solved my ticket.

Flowchart

This is the flow I implemented:

Get user UTC offset in hours.
Send backend timestamp & offset into a conversion function that returns the converted+formatted string to the frontend

The function in step 2 would work like this:

params:
String: dateString
Int: offset

Parse the date string dateString.
Convert data into JS Date object.
Get the current hours of the date object by using JS Date built-in function getHours() method.
Set new hours on the Date object by using JS Date built-in function setHours(), where we pass in the current hours and add the offset passed into the function.
Format the string to the frontend
Return the new converted timestamp

Let's see that happen in code:

Building the conversion function

The function would be called like this:



const convertedTimeStamp = formatTimeByOffset(utcStringFromBE, offset)

And the function I built based on the steps above looks like this:



export const formatTimeByOffset = (dateString, offset) => {
  // Params:
  // How the backend sends me a timestamp
  // dateString: on the form yyyy-mm-dd hh:mm:ss
  // offset: the amount of hours to add.

  // If we pass anything falsy return empty string
  if (!dateString) return ''
  if (dateString.length === 0) return ''

  // Step 1: Parse the backend date string

  // Get Parameters needed to create a new date object
  const year = dateString.slice(0, 4)
  const month = dateString.slice(5, 7)
  const day = dateString.slice(8, 10)
  const hour = dateString.slice(11, 13)
  const minute = dateString.slice(14, 16)
  const second = dateString.slice(17, 19)

  // Step: 2 Make a JS date object with the data
  const dateObject = new Date(`${year}-${month}-${day}T${hour}:${minute}:${second}`)

  // Step 3: Get the current hours from the object
  const currentHours = dateObject.getHours()

  // Step 4: Add the offset to the date object
  dateObject.setHours(currentHours + offset)

  // Step 5: stringify the date object, replace the T with a space and slice off the seconds.
  const newDateString = dateObject
    .toISOString()
    .replace('T', ' ')
    .slice(0, 16)

  // Step 6: Return the new formatted date string with the added offset
  return `${newDateString}`
}

GITHUB CODE

I tested it out and boom, it works when I pass in random offsets. The time converts properly even when time goes over midnight etc. that is taken care of the JS Date setHours() method.

Awesome now I just need to get the user offset and we are done.

Not quite

JS Date

My initial thought was that I simply use this method according to the docs here: JS Date getTimeZone() method



const now = new Date()
const utcTimeOffset = now.getTimezoneOffset() / 60;

NOTE: Divided by 60 because the method returns the offset in minutes.

Gave the wrong time
However, changing my timezone to the west coast in America (for instance) gave me the wrong converted timestamp by 1 hour!

Daylight Savings Time

If we running in a browser this probably would have worked, because the browsers these days will return you a DST adjusted offset (correct me if I'm wrong).

However, since we are not running in the browser we need to figure out a different way to determine if the user is affected by daylight savings time events. Doing this manually will be tricky because not all countries use DST and when they do, they don't use the same date and time when it goes into power. So what do we do?

Let's figure out the timezone of the user somehow first, even though we are not running in a browser we are running on a mobile device. There must be a way of getting the time of the device and use that to our advantage.

Getting the mobile device timezone

Every time I want to use a native module in react native, like using the camera, I turn to React native community on Github

Fortunately for us the community has a native module which is called react-native-community/react-native-localize

I went in and read the docs and found the following method:
getTimeZone()

it is described like this:

getTimeZone()

Returns the user preferred timezone (based on its device settings, not on its position).



console.log(RNLocalize.getTimeZone());
// -> "Europe/Paris"

Alright, good. I installed the package into my project by doing the usual:



yarn add react-native-localize

cd ios && pod install

cd ..

yarn run ios

I ran the example above:



console.log(RNLocalize.getTimeZone());
// -> "Asia/Shanghai"

Ok great if worse comes to worst I can make some kind of lookup table where I keep track of when different timezones go into DST etc. But there's no need for that, so let's bring in the moment time-zone library

Moment Timezone

Moment Timezone Docs

The moment timezone library can take the timezone value generated above and return the UTC offset. Neat!

Installation:



yarn add moment-timezone

Combined with getting the device timezone above we can use it like this



import React, {useState, useEffect} from 'react';
import {View, Text} from 'react-native';

import {formatTimeByOffset} from '../helpers/formatTimeByOffset';
import * as RNLocalize from 'react-native-localize';
import moment from 'moment-timezone';

function Component() {
  const [timeToDisplay, setTimeToDisplay] = useState('');

  const backEndTimeStamp = '2001-04-11 10:00:00';

  // get device timezone eg. -> "Asia/Shanghai"
  const deviceTimeZone = RNLocalize.getTimeZone();

  // Make moment of right now, using the device timezone
  const today = moment().tz(deviceTimeZone);

  // Get the UTC offset in hours
  const currentTimeZoneOffsetInHours = today.utcOffset() / 60;

  useEffect(() => {
    // Run the function as we coded above.
    const convertedToLocalTime = formatTimeByOffset(
      backEndTimeStamp,
      currentTimeZoneOffsetInHours,
    );

    // Set the state or whatever
    setTimeToDisplay(convertedToLocalTime);
  }, []);

  return (
    <View
      style={{
        height: '100%',
        width: '100%',
        alignItems: 'center',
        justifyContent: 'center',
      }}>
      <Text style={{fontSize: 22, marginBottom: 20}}>Time-Example</Text>
      <Text style={{fontSize: 14, marginBottom: 20}}>
        Time passed into the function: {backEndTimeStamp}
      </Text>
      <Text style={{fontSize: 14, marginBottom: 20}}>
        Converted To local timezone: {timeToDisplay}
      </Text>
      <Text>Your timezone: {deviceTimeZone}</Text>
    </View>
  );
}

export default Component;

Let's see that in action:

GITHUB RN CODE EXAMPLE

Success!

I think there are good ways to make this more compact and stuff, but for a tutorial, I rather go a little bit verbose than miss some detail.

Let me know if you found this helpful!

Tutorial: Write a re-useable React Native component and test it with Jest.

Carl-W — Thu, 11 Jun 2020 03:04:33 +0000

All code can be found here Github Repo I will use that repo as well for coming tutorials so if you like my style of ~~rambling~~ writing it can be worth looking at.

Note: I'm not an expert, and there's many ways to do ui component testing.

Cycle 1

Picture this: You have just delivered a new feature, you've passed code review and you send it to QA for one last check that everything is working before releasing it to production.

QA tests and passes your feature 🎉 So a product/project manager tests the app before the final approval.

After a few hours (days) he reports that there are bugs in completely different places in the app which seemingly are un-related to the feature you have been working on, and thus sends it back to you because it's your branch who introduces the issues.

Cycle 2

You notice that a style change in a commonly used UI component caused a lot of trouble all throughout the app. You fix it, tests all the screens, even the ones that are not related to your feature, sends it off to QA, who sends it to PM who finally gives it the OK. 🍾! This extra cycle took 3 days. (or it took 2 weeks because it was a long weekend, and someone in the chain was sick at some point.)

Now obviously that's a lot of hands in the mix to test new code and each step in between are prone to a lot of bottlenecks. People get sick, holidays, weekends, dog ate my laptop... you name it.

The Point

As you might expect: That the second cycle would not be there if there was automated testing in the project. The tests would notify you that the code introduces errors in the app, and you would have fixed it even before sending our a request for code review. Boom, days, weeks saved from testing.

Believe it or not this is how ~~most~~ many projects are governed because everything is prioritized before writing proper tests (😱).

The Tutorial

Let's write a React Native Button component which is re-useable and testing.

The designer has given you the following specification for buttons

Property	Values
Dimensions (HxW)	- standard: 40 x 200 - large: 60 x 200
Primary type	- base color: blue - text color: white
Secondary type	- base color: red - text color: white

And because we are l33t developers we also realize that we need to add some prop controls to this button because designers will change their minds. So we add controls for:

baseColor: Type String to set custom base color
textColor: Type string to set custom text color
height: Type number to set custom height
width: Type number to set custom width

following common API we also add a title prop and an onPress for a callback:

onPress: type function to execute when button pressed
title: type String to display inside the button

Alright, we know what to code so let's setup our component:

Actually! If you are looking for practice try to do it yourself first

import react from "react";
import { TouchableOpacity, Text } from "react-native";

export default function Button(props) {
  // destructure our props
  const { title, onPress, primary, secondary, height, width } = props;

  return (
    <TouchableOpacity onPress={onPress}>
      <Text>{title}</Text>
    </TouchableOpacity>
  );
}

Nice! Halfway done. Let's add styling and account for the different variants, for those who don't like nested ternary expressions: sorry... but not sorry.

import React from 'react';
import {TouchableOpacity, Text} from 'react-native';

export default (Button = props => {
  // destructure our props
  const {
    title,
    onPress,
    secondary,
    large,
    height,
    width,
    baseColor,
    textColor,
  } = props;

  if (!title) return new Error('No title added!');

  const HEIGHT = large ? 60 : height ? height : 40;
  const WIDTH = width ? width : 200;
  const BACKGROUND_COLOR = secondary ? 'red' : baseColor ? baseColor : 'blue';
  const TEXT_COLOR = textColor ? textColor : 'white';

  return (
    <TouchableOpacity
      style={{
        alignItems: 'center',
        justifyContent: 'center',
        backgroundColor: BACKGROUND_COLOR,
        height: HEIGHT,
        width: WIDTH,
      }}
      onPress={onPress}>
      <Text style={{color: TEXT_COLOR}}>{title}</Text>
    </TouchableOpacity>
  );
});

Let's talk about the conditionals for a bit:

HEIGHT
- if large is truthy then set HEIGHT = 60
- if height is truthy then set HEIGHT = height
- else set HEIGHT = 40
WIDTH
- if width is truthy set WIDTH = width
- else set WIDTH = 200
BACKGROUND_COLOR
- if secondary is truthy set BACKGROUND_COLOR = 'red'
- if baseColor is truthy set BACKGROUND_COLOR = baseColor
- else set BACKGROUND_COLOR = 'blue'
TEXT_COLOR
- if textColor is truthy set TEXT_COLOR = textColor
- else set TEXT_COLOR = 'white'

Usage

We can see how even simple re-usable components can become quite complicated fast so when the project grows and new variants are added all the different combinations often culminates in many mutations.

Let's have a look how we would use this component in our app:

import React from 'react';
import {View, Text, Dimensions, Alert} from 'react-native';

import Button from './src/Button';

const {height, width} = Dimensions.get('screen');

const App = () => {
  return (
    <View
      style={{height, width, alignItems: 'center', justifyContent: 'center'}}>
      {/* Renders standard / primary button */}
      <Text>Primary</Text>
      <Button title="Test Button" />

      {/* Renders Large standard / primary button */}
      <Text>Primary Large</Text>
      <Button title="Test Button" large />

      {/* Renders secondary button */}
      <Text>Secondary</Text>
      <Button title="Test Button" secondary />

      {/* Renders secondary button */}
      <Text>Secondary Large</Text>
      <Button title="Test Button" secondary large />

      {/* Renders button with custom width & height */}
      <Text>custom width & height</Text>
      <Button title="Test Button" height={100} width={300} />

      {/* Renders button with custom baseColor and custom textColor */}
      <Text>Custom colors</Text>
      <Button title="Test Button" baseColor="lightpink" textColor="purple" />

      {/* Renders button with alert callback function */}
      <Text>with onPress callback</Text>
      <Button
        title="Test Button"
        onPress={() => Alert.alert('Button pressed')}
      />
    </View>
  );
};

export default App;

Rendered out we get this View in our simulator:

Testing with Jest and react-test-renderer

As I was talking about in the intro it's important that our components come with tests so we don't break stuff without even realizing it.

If you are following along you can go ahead and init a new react native project like this: npx react-native init MyApp command. When doing this the project comes with all the things we need right out of the box so let's give it a try and open up a console and run:

// yarn
yarn run test

// npm
npm run test

If everything is setup correctly you should see something like this:

yarn run test
yarn run v1.22.4
$ jest
 PASS  __tests__/App-test.js
  ✓ renders correctly (694ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        2.72s, estimated 3s
Ran all test suites.
✨  Done in 7.54s.

So let's get cracking with the testing and create a new file called Button.test.js, do the initial setup and add our first test.

/**
 * @format
 */

import 'react-native';
import React from 'react';
// Note: test renderer must be required after react-native.
import renderer from 'react-test-renderer';

import Button from './Button';

describe('Testing primary button', () => {
  const wrapper = renderer.create(<Button title="Test Button" />);

  it('Should render', () => {
    expect(wrapper.toJSON()).toBeTruthy();
  });
});

Explaination

wrapper:

You can call it anything you want, but often when reading other tutorials or documentation it will be called wrapper. At the top of the file we import renderer from react-test-renderer which will give us a type of container (or wrapper) for our component.

Let's go through the initial test where we test if the component rendered:

describe:

This marks the start of a new test suite in Jest, the first argument is a String where we describe what the encompassing test-suite is testing and the second argument is a callback-function where we continue writing our relevant tests.

it:

This marks the start of a new test in Jest. Tests should be as small and consise as they can be and only test one thing. As above, the first argument is a String, describing what the test is testing for, and the second argument is a callback-function where we do the actuall testing.

Inside of the it-block is where we generally do our Jest assertions, in this case I'm convering our test wrapper into a JSON with .toJSON() and then I'm using the .toBeTruthy() assertion function provided by jest. (It just checks if it's not null or undefined)

I'm not going into all of those in this tutorial, here's a link to a cheat sheet: Link

Ok. So we want to test our button for all the different use cases that we have coded for so let's take a look at the different test cases:

primary
- height: 40
- width: 200
- baseColor: blue
- textColor: white
secondary:
- height: 40
- width: 200
- baseColor: red
- textColor: white
large
- can be applied to all above
custom width
- can be applied to all above
custom baseColor
- can be applied to all above
custom textColor
- can be applied to all above

I will only write out the tests for the primary button, because the methods for secondary button is the same.

If we write this out in a verbose way for the sake of clarity in code it might look something like this

Try to understand he code and then look at how I think about it

/**
 * @format
 */

import 'react-native';
import React from 'react';
// Note: test renderer must be required after react-native.
import renderer from 'react-test-renderer';

import Button from './Button';

describe('Testing primary button', () => {
  const wrapper = renderer.create(<Button title="Test Button" />);

  // Take a look at what the wrapper has inside of it
  console.log(wrapper.toJSON())

  // get's the styles of the wrapper
  const styles = wrapper.toJSON().props.style;
  // pulls the fields of interest out of the styles object
  const {height, width, backgroundColor} = styles;

  // get's the child styles
  const childStyles = wrapper.toJSON().children[0].props.style;
  // pulls the field of interest
  const {color: buttonTextColor} = childStyles;

  it('Should render', () => {
    expect(wrapper.toJSON()).toBeTruthy();
  });

  it('Should have height of 40', () => {
    expect(height).toBe(40);
  });

  it('Should have width of 200', () => {
    expect(width).toBe(200);
  });

  it('Should have blue background', () => {
    expect(backgroundColor).toBe('blue');
  });

  // Child Tests
  it('Should have white text', () => {
    expect(buttonTextColor).toBe('white');
  });
});

Step by step explaination

We want to get the wrapper styles and test for them.

styles > When testing that a component has the correct styling I make heavy use of that I can get the information of our test wrapper written out to me in JSON format. We can see how this looks like if we call console.log('wrapperJSON', wrapper.toJSON()). It gives me the following ourput =>

console.log src/Button.test.js:15
      wrapperJSON {
        type: 'View',
        props: {
          accessible: true,
          style: {
            alignItems: 'center',
            justifyContent: 'center',
            backgroundColor: 'blue',
            height: 40,
            width: 200,
            opacity: 1
          },

          ... Removed irrelevant things ...

        },
        children: [ { type: 'Text', props: [Object], children: [Array] } ]
      }

From this output we see that the top most rendered node in the tree is a type View, and further we can see inside props.style where we can see all the styles, so we can pull this information out and use Jest assertions to test if they are what we expect.

One way to pull this data out for us to use is like this:

  // get's the styles of the wrapper
  const styles = wrapper.toJSON().props.style;

  // pulls the fields of interest out of the styles object
  const {height, width, backgroundColor} = styles;

or more compact would be

  // get's the style fields of the wrapper
  const {height, width, backgroundColor} = wrapper.toJSON().props.style;

And then we use them in our testcases as:

  it('Should have height of 40', () => {
    expect(height).toBe(40);
  });

Testing the styles of children

We want to test that our textColor is what we expected.

From our earlier output log we saw a field called children which is an array of all the children seen from the root node in our render tree. Further with some investigation we see that we only have one child in this case, and we can pull console.log out the styles like so:

console.log('Children styles', wrapper.toJSON().children[0].props.style);

Clarification:

first in the array .children[0] and then .props.style gives us the styles object.

which get's us the following output:

console.log src/Button.test.js:22
      Children styles { color: 'white' }

and we can use them like the parent like this (for example)

  // get's the child styles
  const childStyles = wrapper.toJSON().children[0].props.style;

  // pulls the field of interest
  const {color: buttonTextColor} = childStyles;

I make use of re-naming in the destructuring so the variable name makes more sense

and using the same type of test case as above I land on this test case:

  // Child Tests
  it('Should have white text', () => {
    expect(buttonTextColor).toBe('white');
  });

After understanding these techniques we can easily write tests for all the other Button permutations.

Run the tests again and see how it looks:

yarn run test
yarn run v1.22.4
$ jest
 PASS  __tests__/App-test.js
 PASS  src/Button.test.js

Test Suites: 2 passed, 2 total
Tests:       6 passed, 6 total
Snapshots:   0 total
Time:        3.536s
Ran all test suites.
✨  Done in 6.20s.

Boom!

All green ok, so let's take a look at what we have left to test for our primary button.

large
- can be applied to all above
custom width
- can be applied to all above
custom baseColor
- can be applied to all above
custom textColor
- can be applied to all above

I'm going to be honest, I'm still figuring out how to do these variations effectively but one way is to make smaller more compact test suites where each test is more self contained, where we create different test wrappers and test the styles with the method above, for instance like this:

describe('testing other primary variants', () => {
  it('large button', () => {
    const wrapper = renderer.create(<Button title="test" large />);
    const {height, width, backgroundColor} = wrapper.toJSON().props.style;
    // Child
    const {color: buttonTextColor} = wrapper.toJSON().children[0].props.style;

    expect(height).toBe(60);
    expect(width).toBe(200);
    expect(backgroundColor).toBe('blue');
    expect(buttonTextColor).toBe('white');
  });

  it('custom width button', () => {
    const wrapper = renderer.create(<Button title="test" width={333} />);
    const {height, width, backgroundColor} = wrapper.toJSON().props.style;
    // Child
    const {color: buttonTextColor} = wrapper.toJSON().children[0].props.style;

    expect(height).toBe(40);
    expect(width).toBe(333);
    expect(backgroundColor).toBe('blue');
    expect(buttonTextColor).toBe('white');
  });
});

Here I pulled everything together into separate tests, which is a less verbose way of writing everything out explicitly.

Let's run the test command again and see so everything is good:

yarn run test
yarn run v1.22.4
$ jest
 PASS  __tests__/App-test.js
 PASS  src/Button.test.js

Test Suites: 2 passed, 2 total
Tests:       8 passed, 8 total
Snapshots:   0 total
Time:        3.141s
Ran all test suites.
✨  Done in 6.90s.

Now give yourself a pat on the back because your button tested and ready to ship. 🎉🍾

I would really like some input from someone who is testing expert who maybe can piggy back on this post and show some examples of how to write tests in a better way.

Code
Examples Code

Thanks!

React functional components: const vs. function

Carl-W — Wed, 03 Jun 2020 07:50:51 +0000

I have been performance optimizing our app recently and as such, I have been getting into the nitty gritty of Javascript. One of the things I thought about is if there's any real difference between declaring a component like this:

const MyComponent = () => {
    return(
      ..
    )
}

vs.

function MyComponent() {
    return(
      ..
    )
}

In this form the function syntax is slightly shorter.

And then?

At times, we can write the arrow function like this:

const MyComponent = () => (...)

If we put normal parenthesis after the arrow we don't need to write the return. So it's shorter if we can return immediately.

And then?

Another thing I have seen people talk about is the export of the component.

export default function MyComponent() {}

vs.

const MyComponent = () => {}

export default MyComponent

The function syntax gives us the ability to export default the component in place.

And then? (any Dude where's my car fans here?)

Hoisting

Turns out the biggest reason (as what I could find) is due to hoisting. Let's look at an example with Valid syntax:

// I like to write my components before I use them

const MyComponent = () => {}

const AlsoMyComponent = () => {}

const App = () => (
    <>
      <MyComponent />
      <AlsoMyComponent />
    </>
)

And then? Let's look at invalid syntax:

const App = () => (
    <>
      <MyComponent />
      <AlsoMyComponent />
    </>
)
// I like to keep my components at the bottom

const MyComponent = () => {}

const AlsoMyComponent = () => {}

This example 👆 will engage your linter to throw an error. Because the components are used before they are declared.

So if you like to keep your components on the bottom, and use them before they are declared we can write them with the function syntax, and have them hoisted to the top of the file.

 const App = () => (
    <>
      <MyComponent />
      <AlsoMyComponent />
    </>
)
// I like to keep my components at the bottom

function MyComponent() {}

function AlsoMyComponent() {}

This example 👆 will not engage your linter, because when we run the file it will look like this to the JavaScript engine:

// Components are hoisted to the top.

function MyComponent() {}

function AlsoMyComponent() {}

 const App = () => (
    <>
      <MyComponent />
      <AlsoMyComponent />
    </>
)
// I like to keep my components at the bottom

👀 where did they go?

And then?

That's it! I think...? If you have a different idea then me, or know more differences please let me know!

DEV Community: Carl-W

Why Companies Area Restrict Jobs, Even if They Are Remote

Navigating the maze of taxation and legalities

Tax Implications

Offering Equitable Benefits

Collaboration and Time Zones

Conclusion

P.S.

Making GraphQL Codegen Work For You: GraphQL Integration with React and TypeScript

TL;DR

Intro

What We Will Do:

Creating an Example Project with React and Next.js

Install Dependencies & Initialize Apollo Client

Fetching Data without Type Checking

What Went Wrong with GraphQL?

No GraphQL Type Validation

No Types In The Response

What Is Graphql Codegen?

Setup and Configuring GraphQL Codegen

Adding Our Schema File

GraphQL Codegen in Action

Using Generated End-To-End Type-Safe Apollo Hooks

Best Practices for GraphQL Codegen

Adding In New Functionality With Novu

How to Get Started with Novu

Step 1: Sign Up

Step 2: Connect the Novu Email Provider

Step 3: Create a New Notification Trigger

Step 4: Create the React Form Component

Step 5: Install Novu-client

Step 6: Create a Next.js API Endpoint

Step 7: Add Our Email Functionality

Step 8: Send Emails!

Wrapping It Up

Helping developers find remote jobs since 2019

TLDR

How it started

Being in good company

Job boards are a lottery

What I would do if I was looking for a new remote job?

Support the project

Thanks for reading 🤓 Happy job hunting.

Events driven analytics service powered by Mongo Atlas

Overview of My Submission

The Backend

The example app

Submission Category:

Link to Code

ugglr / dev-mongodb-hackathon

Events driven analytics service created with MongoDB, TS, Nest.js and caffeine

dev.to MongoDB Hackathon project

Built with

Description

Installation

Running the app

Test

Support

Additional Resources / Info

nestjs / nest

A progressive Node.js framework for building efficient, scalable, and enterprise-grade server-side applications with TypeScript/JavaScript 🚀

Description

Philosophy

facebook / react

The library for web and native user interfaces.

React ·

Step 3: Setting up Storybook with React Native Web: show your mobile components the browser!

Starting point

Manually installing Storybook for React.js 🤸‍♂️

1.) at the root run the command in your terminal: 🚀

2.) Add our scripts to package.json 🚀

3.) [Optional] Test our React.js Storybook installation before modifying it. 🚀

4.) Adding our React Native Stories to Storybook 🚀

So where do we inject our stuff?

Adding Styled components to webpack

Fin!

Thanks! 🎉

Publish/Update NPM packages with GitHub Actions

Goal

Preparing our repo to use GitHub Actions

2.) Add our scripts to `package.json` 🚀

Add public `index.html`