DEV Community: Carl-W

Ghost Jobs: 30% of What You're Applying to Doesn't Exist

Carl-W — Mon, 13 Apr 2026 21:24:16 +0000

You applied to 100 jobs last month. About 30 of them didn't exist.

Not "the role was filled." Not "they went with an internal candidate." The job was never real. Nobody was ever going to get hired. The posting was there to serve a purpose that had nothing to do with you.

The numbers are worse than you think

27.4% of U.S. LinkedIn listings are ghost jobs. A Resume Builder survey found 3 in 10 companies have fake job postings live right now. Not by accident. On purpose.

81% of recruiters admit their employer posts roles that don't exist or are already filled. In tech, 40% of companies posted fake jobs in the past year. 79% of those are still up.

Los Angeles has a 30.5% ghost job rate. But it's not a local thing. It's everywhere.

Why companies do this

The reasons are almost never about hiring. That's the part that should piss you off.

Companies post jobs to look like they're growing. If you're raising a Series B and your careers page shows 40 open roles, investors see scale. Whether those roles are real doesn't matter. The perception is the product.

Some companies post jobs to do free market research. They want to see who applies, what salary expectations look like, how deep the talent pool goes in a given city. You spend 45 minutes on your application. They get a data point. Nobody was ever going to call you.

Others use ghost postings as a retention tool. "Look at all these open roles. We could replace you tomorrow." It's a threat dressed up as a careers page.

And then there's plain negligence. A role gets filled internally. Nobody turns off the auto-renew in the ATS. The posting sits there for 6 months collecting applications from people who think it's real. This is probably the most common one, and somehow it's also the most insulting. They couldn't even be bothered to click "close."

15 hours you're not getting back

Each application takes about 30 minutes when you actually do it right. Reading the description, adjusting your resume, writing responses, submitting. Apply to 100 jobs in a month, 30% are ghosts, that's 30 wasted applications. 15 hours. Gone.

But the time isn't the worst part.

You applied. You were qualified. You heard nothing. And you start wondering if you're the problem. Maybe your resume sucks. Maybe you need to learn another framework. Maybe you're too expensive. You internalize the rejection when there was nothing to be rejected from.

The job didn't exist.

72% of job seekers report negative mental health impacts from drawn-out hiring processes. Ghost jobs are a huge part of that. Every fake listing adds another false data point to your "maybe I'm not good enough" story.

How to spot them

None of these are guaranteed. But stacking them together filters out most of the garbage.

Check the posting date. If it's been up for 60+ days, especially at a tech company, something is off. Most real positions fill within 30-45 days. Three months? Either it's a ghost, the role is impossibly niche, or the company can't get their act together. None of those are encouraging.

Read the actual description. Ghost jobs are almost always vague. "Looking for a talented engineer to join our growing team." No tech stack mentioned. No team name. No specific project. Real hiring managers get specific because they need a specific person. Vagueness is a tell.

Look at the company's pulse. Are they active on social media? Have they made recent hires you can see on LinkedIn? Do they have an engineering blog that's been updated this year? A company listing 20 open roles with zero public activity for 4 months is suspicious.

Cross-reference the source. If a job shows up on Indeed, LinkedIn, Glassdoor, and three other boards but isn't on the company's own careers page, it's a stale aggregation. Some distribution service is auto-syndicating a dead listing that nobody bothered to kill.

Job boards won't fix this

Job boards make money from listings. More listings means more page views. More page views means more ad revenue or higher subscription fees. A ghost job and a real job generate the same engagement metrics.

Indeed, LinkedIn, Glassdoor. None of them have an incentive to remove ghost postings. The ghost job is doing exactly what their business model needs. Just not what you need.

The platforms you trust to help you find work are economically rewarded for keeping fake listings live. That's a broken foundation and no amount of UI polish fixes it.

Regulation is coming, slowly

Ontario passed legislation requiring companies to disclose whether a posting is for a real, active vacancy. The U.S. has the TJAAA bill working through Congress with similar requirements.

When lawmakers write bills specifically about fake job postings, the problem has gone past "industry nuisance" into "systemic failure." But regulation is slow. Enforcement is slower. You can't wait for Congress to fix your job search.

Stop searching for jobs. Start tracking companies.

Sounds backwards. But think about it.

The ghost job problem exists because you're interacting with listings, not companies. A listing can be fake. A company can't fake its existence, its tech stack, or whether it's actually made hires recently.

Pick 10-20 companies where your tech stack genuinely overlaps. Track them. Watch for new roles at those specific companies. When one of them posts something, you know it's more likely to be real because you've been watching the company, not a random feed of disconnected listings.

This is what I built Remoet around. 725+ remote tech companies, tracked, with real tech stack data. You star the ones that match your skills, and your AI agent monitors them for you. It doesn't eliminate ghost jobs entirely. Some companies will always play games. But you go from fishing in a pool that's 30% fake to watching a handful of companies you've already vetted.

Apply fewer. Apply better.

The instinct when you learn about ghost jobs is to compensate with volume. "If 30% are fake, I'll just apply to 3x as many." That's the trap. More volume means more time wasted on ghosts, more silence, more false rejections eating at your confidence.

The opposite works. Narrow your target. Verify the company is real and active. Check the posting date. Look at the tech stack. Then apply once, with effort, to something that's actually there.

30% of what you're applying to doesn't exist. The fix isn't applying harder. It's not applying to bullshit.

Frequently Asked Questions

What is a ghost job?

A ghost job is a posting for a position that isn't actually open or that the company never intends to fill. It exists for other reasons: signaling growth to investors, collecting market data, pressuring existing employees, or just negligence where nobody closed the listing after the role was filled internally.

How common are ghost jobs?

Between 27-30% of job listings, depending on the study. Resume Builder found 3 in 10 companies currently have fake postings live. In tech specifically, 40% of companies posted at least one fake job in the past year, and 79% of those are still active.

How do I know if a job posting is fake?

Look for a combination of red flags: the posting has been up for 60+ days, the description is vague with no specific tech stack or team, the same listing appears on aggregator sites but not on the company's own careers page, and the company shows no other signs of active hiring (no recent LinkedIn hires, no social media activity).

Are ghost jobs illegal?

In most places, not yet. Ontario passed legislation requiring disclosure of whether a posting is for an active vacancy. The U.S. has the TJAAA bill in Congress. Regulation is moving, but slowly.

Why don't job boards remove ghost jobs?

Because ghost jobs make them money. A fake listing generates the same page views, ad impressions, and engagement metrics as a real one. The platforms have no economic reason to clean them up.

What Is MCP (Model Context Protocol)? A Practical Guide

Carl-W — Wed, 25 Mar 2026 11:21:58 +0000

MCP (Model Context Protocol) is an open standard that lets AI agents connect to external software, discover available tools, and take actions on your behalf. Instead of being trapped in a chat window, your AI can search databases, manage projects, update profiles, and interact with any service that runs an MCP server.

You've probably seen MCP mentioned everywhere lately. Twitter threads, blog posts, product announcements. Every AI company seems to be shipping an "MCP server" and every developer tool is adding "MCP support." But if you've tried to figure out what MCP actually is, you've probably run into a wall of jargon and protocol specs.

I'm going to cut through that.

MCP in Plain English

Anthropic introduced MCP in November 2024. In December 2025, they donated it to the Agentic AI Foundation under the Linux Foundation, with OpenAI, Block, and others as co-stewards. It's a genuinely open protocol now.

Here's the problem it solves. When you use Claude or ChatGPT, the AI can talk to you, but it can't actually do anything outside that conversation. It can't check your calendar, search a database, file a bug report, or look up your job applications. It's stuck inside a text box.

MCP changes that. It's a universal plug that lets an AI agent reach into other software and take actions on your behalf. Search a job board. Update a project. Star a company. Send a message. Whatever the connected service supports.

Yeah, I know, the USB analogy is the cliche everyone uses for MCP. But it's accurate, so I'll use it anyway: before USB, every device had its own proprietary connector. Printers, keyboards, cameras, all different cables. USB standardized the physical connection. MCP standardizes the AI-to-software connection.

How It Actually Works

Under the hood, MCP uses JSON-RPC 2.0 as its wire protocol. If you've worked with LSP (Language Server Protocol), the architecture will feel familiar. There are two sides to every MCP connection:

The client is your AI agent. Claude Desktop, Cursor, Windsurf, Claude Code, Cline. These are the apps where you type prompts and have conversations. They speak MCP natively.

The server is whatever tool or service you want the agent to access. A GitHub MCP server lets your agent manage repos and issues. A Notion MCP server lets it read and write documents. A Remoet MCP server lets it search remote job listings, manage your developer profile, and track applications.

When a client connects to a server, the server advertises its capabilities through three primitives:

Tools: Actions the agent can execute. Searching listings, creating a profile entry, submitting an application. These are the most commonly used primitive.
Resources: Data the agent can read, like files, database records, or configuration. Think of these as GET endpoints.
Prompts: Predefined templates that guide the agent through specific workflows. Less common but useful for complex multi-step tasks.

Each tool has a name, a description, and a JSON Schema defining its inputs. The AI reads those descriptions and figures out which tools to call based on what you ask.

So when you say "find me remote companies hiring React developers," the agent looks at the available tools, picks the search tool, fills in the right parameters, calls it, and returns the results. You never have to know the tool exists. You just describe what you want.

MCP vs Function Calling

This is the confusion I see most often. Function calling is a model-level feature where the AI can output structured JSON to invoke predefined functions. It's been around since 2023. MCP is the transport and discovery layer that sits on top of function calling.

Think of it this way: function calling is the engine. MCP is the road network.

Without MCP, every developer has to manually define function schemas, wire them up to API clients, handle authentication, and build the plumbing for each integration from scratch. MCP standardizes all of that. The server describes its tools once, any MCP client can discover and use them, and the client's function calling capability handles the actual invocation.

So they're complementary, not competing. Function calling is what lets the model decide to call a tool. MCP is what lets the model discover tools dynamically from external servers and execute them over a standardized transport.

MCP vs A2A (Agent-to-Agent Protocol)

Google released their Agent-to-Agent (A2A) protocol in early 2025, and I keep seeing people ask whether it competes with MCP. Short answer: no. They solve different problems.

MCP connects an agent to tools and data. A2A connects an agent to another agent. MCP is about giving one agent hands to interact with software. A2A is about letting multiple agents collaborate with each other on a task. You'd likely use both in a mature agentic system, with MCP for tool access and A2A for multi-agent coordination.

The Three Primitives in Practice

I mentioned Tools, Resources, and Prompts above, but it's worth seeing how they play out in a real MCP server.

Remoet has 38 MCP tools. When your agent connects, it receives all 38 tool definitions with their descriptions and parameter schemas. The agent doesn't need documentation. It reads the tool descriptions and figures out the right calls.

Ask "find companies using Go and Kubernetes" and the agent picks the search tool. Ask "show my applications" and it picks the applications tool. Ask "update my summary" and it picks the profile update tool. All from the same conversational interface. No menus, no navigation, no context switching.

This is fundamentally different from a traditional API integration. With an API, a developer writes code to call specific endpoints with specific parameters. With MCP, you describe your intent in natural language and the AI handles the rest.

Security: OAuth 2.1, PKCE, and Prompt Injection

I won't sugarcoat this: connecting AI agents to live services introduces real security considerations.

On the authentication side, MCP supports OAuth 2.1 with PKCE (Proof Key for Code Exchange). This is the same security standard used by major web applications. Each connection requires explicit user authorization, and you can revoke access at any time. Remoet's MCP implementation enforces PKCE on every authorization, with session limits and LRU eviction to prevent resource exhaustion.

The trickier risk is prompt injection. If an MCP server returns malicious content in tool results, it could theoretically trick the agent into taking unintended actions. Good MCP implementations mitigate this by treating all tool results as untrusted data (Remoet's server description explicitly instructs agents to do this), but it's an active area of research. The MCP spec itself is evolving to add better guardrails here.

If you're evaluating MCP servers, look for ones that use OAuth 2.1 rather than just API keys, enforce PKCE, and document their approach to prompt injection defense.

Who Supports MCP Today

The ecosystem has grown fast. Thousands of MCP servers are now listed across various directories, and the number is climbing weekly.

On the client side:

Claude Desktop and Claude Web have native MCP support, including custom connectors via OAuth
Claude Code supports MCP servers out of the box via the CLI
Cursor has built-in MCP configuration
Windsurf supports MCP servers in its settings
VS Code now has native MCP support through GitHub Copilot
Cline and Continue also support MCP

On the server side, the ecosystem spans every category:

Category	Examples
Development	GitHub, Linear, Sentry
Productivity	Notion, Slack, Google Drive
Data	Supabase, PostgreSQL, various database connectors
Search	Brave Search, Context7 (documentation search)
Career & Jobs	Remoet (remote job search, profile management, applications)
Automation	n8n, Zapier

What's striking is that MCP servers aren't just developer tools anymore. They're showing up in every vertical: job platforms, finance tools, CRM systems, e-commerce. Any software with an API can become an MCP server, and increasingly, they are.

Why This Matters For You

If you're a developer, MCP means you can automate a huge chunk of your workflow through conversation. Instead of context-switching between 15 browser tabs, you tell your agent what you need and it handles the tool-hopping.

If you're job hunting, this is where it gets genuinely interesting. Traditional job boards make you do all the work: search, filter, scroll, click into each listing, apply one by one. An MCP-connected job platform flips that. You tell your agent "find companies using my tech stack that are actively hiring" and it does the searching, filtering, and shortlisting for you.

That's exactly what Remoet does. Connect your AI agent once, and it handles the rest: finding companies that match your stack, tracking applications, messaging hiring teams. Your agent becomes your career assistant.

But beyond any single platform, the bigger shift is this: software is becoming conversational. Instead of learning each app's UI, you describe what you want and your agent navigates the tools for you. MCP is what makes that possible at scale.

Getting Started

If you want to try MCP yourself, the setup is simpler than you'd expect. Most MCP-compatible AI apps let you add servers through a configuration file or settings page. You typically need an API key or OAuth authorization from the service you want to connect, and then you're up and running.

We've got a detailed setup guide covering Claude Desktop, Claude Code, Cursor, and Windsurf in our post on how to set up MCP servers.

For a complete walkthrough of what AI-powered job search looks like in practice, check out our agent job search guide.

Frequently Asked Questions

Is MCP only for Claude?

No. MCP is an open protocol governed by the Linux Foundation. While Anthropic created it, it's been adopted by Claude, Cursor, Windsurf, VS Code, Cline, Continue, and others. Any AI client can implement MCP support. OpenAI added MCP support to their agents SDK in early 2025.

Do I need to be a developer to use MCP?

Not necessarily. Some setups require editing a JSON config file, which is a bit technical. But Claude Web supports custom MCP connectors through a point-and-click OAuth flow that requires zero coding. Desktop Extensions are also making one-click installs possible. The trend is clearly toward making MCP accessible to everyone.

Is MCP secure?

MCP supports OAuth 2.1 with PKCE for authentication, which is the same security standard used by major web applications. Each connection requires explicit authorization. You control which services your agent can access and can revoke access at any time. The main emerging concern is prompt injection through tool results, which is an active area of research in the MCP community.

What's the difference between MCP and a browser extension or plugin?

Browser extensions and plugins are specific to one application. A Chrome extension only works in Chrome. A ChatGPT plugin only worked in ChatGPT (and OpenAI deprecated them). MCP is standardized across all compatible AI clients. Build one MCP server and it works with Claude, Cursor, Windsurf, VS Code, and any future client that supports the protocol. Build once, work everywhere.

How many MCP servers can I connect at once?

There's no hard protocol limit. You can connect as many MCP servers as your AI client supports. Most people connect 3 to 10 servers depending on their workflow, covering things like code management, documentation, search, and whatever domain-specific tools they need.

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!