Problem

In the last article, I discussed to use runtypes to connect static types and runtime check. The theory behind is runtypes has its own definition language, which can convert to a runtime check function and a static typescript type. By doing that we can remove the duplication across the two world.

It is awesome, however one of the biggest cons of this approach is: runtypes defined a good definition language but it is not well known. Because of that, it is less possible to create a strong ecosystem for different scenarios.

For example, recently I am working on a REST…

Typescript introduced type system into javascript, but it is only existed till compiled into javascript. When we run those compiled code in runtime, all the types are disappeared.

This might not be a big issue, because in most case we can verify all the data type statically.

But how about the inputs from outside? A typically example is we need to fetch data from some REST APIs. We definitely cannot verify the inputs statically.

Happy path

Let’s give a example, check the following example:

type Person = {
 name: string;
 films: string[];
};const fetchPerson = async (id: string): Promise<Person> => {…

Quite often, when we develop npm packages, we want to test them as a consumer. In order to test, if you think you have to publish it, you are out. There are at least three ways to make your life a lot easier.

Test scenarios

Before we jump into the three method, let’s image the below scenarios we want to test:

• Test locally: We want to test the package locally, because we can simulate the consumer locally.
• Test within our team: My college want to test the package, as he/she is developing the consumer.
• Test out of our team: Other team or…

GraphQL is cool, it exposes the exact contract between frontend and backend in details.

However, when you try to use it, there is still gaps between GraphQL and the host programming language. For example, mostly frontend project is using typescript, while GraphQL is strong typed contract but still not typescript.

This situation is like when we develop SQL based application by using Java. At that time, we have ORM, stands for Object Oriented Mapping, which is a standard tool mapping object structure and sql relationship, and allow developer to access SQL database by knowing only JAVA or other object oriented…

Problem

When we stated to use useEffect and slowly put more and more logics in the effect, it is very easily end up with a long dependency list because of the eslint exhaustive-deps rule.

We provide an `exhaustive-deps` ESLint rule as a part of the `eslint-plugin-react-hooks` package. It warns when dependencies are specified incorrectly and suggests a fix.

For example, the original goal of the effect is to execute it when the A prop is changed. However, because we end up with other props in deps list like func1 prop and obj1 prop, the effect triggering logic became either A, func1…

useEffect is the most widely used hook in React. It is handy and looks easy to use, but you must experience infinite loops or some unexpected result when using useEffect. In this article, I try to give you some tips to avoid those typical pitfalls when using it.

Tip #1 understand the mind concept of useEffect

The definition of useEffect is below:

function useEffect(effect: EffectCallback, deps?: DependencyList): void
type EffectCallback = () => void | (() => void | undefined)
type DependencyList = any[]

There are three factors in useEffect, effect, cleanup, and deps. The key point is effect. We all know useEffect is to wrap side effects…

Graphql becomes more and more mainstream, and Graphql schemas first is becoming the recommended practice when starting a new project. It’s critical important to design a solid Graphql Schema which can be stable when facing future changes.

When I saw there is an egghead course called Designing Graphql Schemas, I joined. After watching all episodes in an afternoon, I learned a lot how to design robust schema. Thanks Nik Graf.

In this article I share what I learned, but I still encourage you to watch the whole cause by yourself.

Tip #1: Mock resolvers before implementations

Supposing we are using Apollo Server, it has built-in mock…

Stranger Problem I met with unique index

I use nodejs to develop a simple app talking to `sql server` like below:

import Knex from ‘knex’
const knex = Knex(…)// create the table
knex.schema.createTable(‘People’, function(t) {
 t.string(‘name’).notNullable()
 t.string(‘title’)
 t.unique([‘name’, ‘title’])
})

What the above did is create a table called `People` and create a unique index on `name` and `title`. Then I insert two records with different value. It is fine.

// insert two records with different values, it is fine
knex(‘People’).insert({name: ‘ron’, title: ‘Mr.’})
knex(‘People’).insert({name: ‘aaron’, title: ‘Dr.’})

Next try is to insert two records with same values, I will expect to see exception would happen…