DEV Community: WJH

User-defined Ternary Operator

WJH — Sun, 11 Jul 2021 04:38:21 +0000

Introduction

Ternary operator is a very useful syntactical notation
for condensing meaning. Basically it takes three
arguments, and syntactically speaking it's identifier is
split into two parts.

For example:

Javascript conditionals a ? b : c
Math range check a < b < c
SQL joins a JOIN b ON c

This is similar to why we
prefer infix binary operators (IBO), because they can be
chained together easily (or so called
associativity).

For example, most if not all of us will think that A is easier to read and understand than B:

A	B
`a + b + c`	`(+ (+ a b) c)`

Because IBO are so important,
most functional programming (FP) languages like Haskell
allow users to define custom IBO.

For example:

-- pipe forward operator
(|>) :: a -> (a -> b) -> b
a |> f = f a

-- example usage
main = [1, 2, 3] 
  |> map (+2) 
  |> filter (>3) 
  |> print 
  |> putStrLn -- [4, 5]

See more at Haskell Infix Operator.

Emulating with binary operator

However, when it comes to user-defined ternary operator,
none of the programming languages provide the mechanism.

Although ternary operator can be emulated using double
IBO, it is not without its own caveats.

Take this example from Haskell:

data Cond a = a :? a

infixl 0 ?
infixl 1 :?

(?) :: Bool -> Cond a -> a
True  ? (x :? _) = x
False ? (_ :? y) = y

test = 1 < 2 ? "Yes" :? "No"

The caveat of such emulation is that partial usage is
not only syntactically valid, but also
semantically valid.

For example, we can omit that :?
part, and the compiler will not complain.

x = 1 < 2 ? "Yes"

From the user experience (UX) perspective, this is very bad,
because we intended users to always use ? together with
?:.

Emulating using mixfix operators

Other than using IBO, we can also emulate ternary operators using mixfix operators.

For example, in Agda:

-- Example function name _if_else_ 
-- (emulating Python's conditional operator)
_if_else_ : {A : Set} -> Bool -> A -> A -> A
x if true else y = x
x if false else y = y

The caveat of such approach is that users will be
required to lookup the syntax before they can even parse
a piece of code that is filled with mixfix operators.

Because, for example, the above _if_else_ operators can also be defined as:

if_then_else_ : {A : Set} -> Bool -> A -> A -> A
if x then true else y = x
if x then false else y = y

In this case, the user will not be able to parse the following code correctly without knowing the syntax of if or/and else:

x = a if b else c -- is this correct?
y = if a then b else c -- or this?

The Question

Due to the aforementioned caveats of emulating ternary
operators, I am on a quest for searching a mechanism to allow
user-definer ternary operators that is:

Unambiguous (parsable by both machine and human)
Universal (can be applied to all kinds of ternary operators)

Inspiration

I have been contemplating this question for a while, but
still there is no significant progress, until I read the
book The Relational Model of Database
Management
by the inventor of Relational Algebra, Edgar. F. Codd.

His notation for denoting theta-joins is ingenious.

For example,

SQL	Edgar's notation
`X join Y on A join Z on B`	`X [A] Y [B] Z`

The ingenious part about this is that he treats ternary
operator as decorated binary operators!

In the above example, the binary operator [], is
decorated/tainted with A, giving it a different
meaning.

This actually also relates to the mathematical notation of theta-join:

In this case, thetha symbol is decorating the join
symbol, turning it into a ternary operator that still
behave as a binary operator.

The advantage of this approach is that ternary
operators behave like binary operators, which means
that they can be chained together naturally.

The Potential Answer

By expanding on the idea where ternary operator are just
decorated/tainted binary operators, I first have this idea:

Ternary operators can be defined using the following syntax:

a X[ b ]Y c

Where a, b and c are the arguments, and X[ and
]Y are together the name of the ternary operators.

For example, let's define range-check:

-- Definition
a <[ b ]< c = a < b && b < c

-- Usage
print (1 <[2]< 3) -- true
print (1 <[3]< 2) -- false

Assuming [ ] is not used anywhere in the syntax of
the language, such ternary operators usage can be parsed
easily. Because whenever the user or machine sees [ or
], then they can anticipate a ternary operator.

However, the above syntax is obviously too noisy, so to
reduce the noise, we can swap the square brackets [
], with one of the most invisible ASCII operator, the backtick.

With this modification, the above range-check can be rewritten as follows:

-- Definition
a <` b `< c = a < b && b < c

-- Usage
print (1 <` 2 `< 3) -- true
print (1 <` 3 `< 2) -- true

Thus, the best mechanism that I can think of so far to define ternary operator is as follows:

a X` b `Y c

-- Where a, b and c are the arguments
-- while X` and `Y together is the name of the ternary operator

Also regarding precedence, ternary operators should have
lower precedence than binary operators, for example:

(a <` b + c `< d) MEANS (a <` (b + c) `< d)

Regarding, associativity, I will prefer
right-associativity over left-associativity, since it is
more common in most cases.

Therefore:

a X` b `Y c X` d `Y e = a X` b `Y (c X` d `Y e)

For example, the conditional ternary operator:

true then` b `else c = b
false then` b `else c = c

Where:

a then` b `else c then` d `else e

Should conventionally mean (right-associative):

a then` b `else (c then` d `else e)

Rather than (left-associative):

(a then` b `else c) then` d `else e

Conclusion

Hopefully this article has provided you some inspiration
on the mechanism of user-defined ternary operators.

Thanks for reading.

GraphQL Design Pattern (1): Pagination & Summary

WJH — Tue, 29 Jun 2021 06:35:41 +0000

So I designed a schema for a common feature,
basically frontend needs to display two things:

Summary of items
The items

Suppose the page is about showing a list of
animals, and we want to show them the summary of
each type of animals.

FILTERS
[ ] Mammal (200)
[x] Birds (110)
[ ] Fish (200)

ITEMS
- Eagle
- Pigeon
- Stork
- ...

Initial Design

Initially, the schema I designed is as follows:

query {
  displayAnimals(animalTypes: [AnimalType!]!): DisplayAnimalsResult!
}

enum AnimalType {
  MAMMAL
  BIRD
  FISH
}

type DisplayAnimalsResult {
  summary: DisplayAnimalsResultSummary!
  animals: FilteredAnimals!
}

type DisplayAnimalsResultSummary {
  mammal: Int!
  bird: Int!
  fish: Int!
}

type FilteredAnimals {
  totalCount: Int!  
  paginate(pagingOptions: PagingOptions!): [Animal!]!
}

type PagingOptions {
  currentPage: Int!
  itemsPerPage: Int!
}

type Animal {
  name: String!
}

And the frontend query:

query DisplayAnimal(
  $animalTypes: [AnimalType!]!
  $pagingOptions: PagingOptions!
) {
  displayAnimals(animalTypes: $animalTypes) {
    summary {
      mammal
      bird
      fish
    }
    animals {
      totalCount
      paginate(pagingOptions: $pagingOptions) {
        name
      }
    } 
  }
}

The Problem

The summary is hardcorded. If frontend needed a new kind of summary, the schema has to change.
The summary property feels like a boilerplate to implement.

A Better Design

After seeing this pattern over and over and getting
frustrated, I suddenly realised that the summary
property is actually not needed!

Let's see the new schema (note that DisplayAnimalsResult and DisplayAnimalsResultSummary are gone):

query {
  displayAnimals(animalTypes: [AnimalType!]!): FilteredAnimals!
}

enum AnimalType {
  MAMMAL
  BIRD
  FISH
}

type FilteredAnimals {
  totalCount: Int!  
  paginate(pagingOptions: PagingOptions!): [Animal!]!
}

type PagingOptions {
  currentPage: Int!
  itemsPerPage: Int!
}

type Animal {
  name: String!
}

And the frontend query (here's the magic, using
GraphQL Property Alias):

query DisplayAnimal(
  $animalTypes: [AnimalType!]!
  $pagingOptions: PagingOptions!
) {
  mammal: displayAnimals(animalTypes: [MAMMAL]) {
    totalCount
  }
  bird: displayAnimals(animalTypes: [BIRD]) {
    totalCount
  }
  fish: displayAnimals(animalTypes: [FISH]) {
    totalCount
  }
  displayAnimals(animalTypes: $animalTypes) {
    animals {
      totalCount
      paginate(pagingOptions: $pagingOptions) {
        name
      }
    } 
  }
}

How is this better?

No need to implement summary resolver on backend, leading to lesser code.
The summary is no longer hardcoded, e.g. you can query total count of birds and fishes.
Smaller schema, less noise.

Conclusion

GraphQL Alias is a powerful feature, thus remember to incorporate it when designing the schema.

P/S

Actually I wrote this for my workplace team. I decided to post it here because maybe others might find it helpful.

How to test server in vanilla Deno?

WJH — Wed, 24 Jun 2020 06:33:40 +0000

DISCLAIMER: the method provided in this article uses unstable API of Deno.

Overview

In this article, we will discuss how to test a server in Deno without using any 3rd party library, just vanilla Deno.

Prerequisite

Make sure you are using Deno v1.1.1.

Server

Suppose we have a file named server.ts with the following content:

import { serve } from "https://deno.land/std@v0.57.0/http/server.ts";

const server = serve({ port: 8000 });
console.log("Server listing on http://localhost:8000/");
for await (const request of server) {
  if(request.url === '/404') {
    request.respond({ 
      body: new TextEncoder().encode("Oops")
    });
  }
  else {
    request.respond({ 
      body: new TextEncoder().encode("Hello world!")
    });
  }
}

This file describe a very simple server, which will return "Hello world!" for any request, regardless of the method or URL, but will return "Oops" when that URL is "404".

You can try out this server by running:

deno run --allow-net server.ts

Then visit http://localhost:8000 and http://localhost:8000/404 in your browser, you should see Hello world! and Oops respectively.

Testing

To write the test, we will use:

Deno.test for creating test cases
assertEquals to make assertions
Worker to spawn our server (note that Worker is unstable as of Deno@v1.1.1).
fetch to make request

For our server, mainly we want to test out two things:

GET /404 should return "Oops"
GET any other URL should return "Hello world!"

Below is the code for testing, which should be stored in a file named server.test.ts:

import { assertEquals } from "https://deno.land/std@0.57.0/testing/asserts.ts";


const serverPath = new URL("./server.ts", import.meta.url).href;

// Spawn the server in a worker thread
const worker = new Worker(serverPath, { type: "module", deno: true })

// Wait for a moment to let the server start (this is a little hacky actually) 
await new Promise((resolve) => setTimeout(resolve, 3000));

// Write our test cases, note that we store them in a variable
// This is necessary such that we can keep track of how many test are there
// And so we can terminate the server properly after every test finished
const tests: {
  name: string;
  fn: () => Promise<void>;
}[] = [
    {
      name: 'GET /* should return "Hello world!"',
      fn: async () => {

        const response = await fetch("http://localhost:8000/");
        assertEquals(await response.text(), "Hello world!");
      }
    },
    {
      name: 'GET /404 should return "Oops"',
      fn: async () => {

        const response = await fetch("http://localhost:8000/404");
        assertEquals(await response.text(), "Oops");
      }
    }
  ]

// Utility function to keep track of number of ran tests
let numberOfRanTest = 0;
const done = () => {
  numberOfRanTest++;
  if (numberOfRanTest === tests.length) {
    worker.terminate();
  }
};

// Run the test
tests.forEach((test) => {
  Deno.test({
    name: test.name,

    // Note that we invoke `done` when the test fn finished
    fn: () => test.fn().then(done),

    // We need to set these options to false such that the test can exit with status 0
    sanitizeOps: false,
    sanitizeResources: false,
  });
});

To run the test:

deno test --unstable --allow-net --allow-read server.test.ts

You should see the following output after running the test:

Compile file:///Users/wongjiahau/repos/levo/core/.deno.test.ts
Server listing on http://localhost:8000/
running 2 tests
test GET /* should return "Hello world!" ... ok (13ms)
test GET /404 should return "Oops" ... ok (5ms)

test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out (18ms)

Conclusion

The method I presented here might be a little hacky, but it will be great if you're looking to test server without using any 3rd party libraries or framework.
If you have any questions feel free to post in comments. Thanks for reading! :D

How to use custom JSX in Deno?

WJH — Tue, 16 Jun 2020 03:07:09 +0000

This article is meant for Deno authors who wanted to create a frontend library in Deno that utilises JSX without using React.

Before you start, please make sure you're using Deno v1.1.0.

deno upgrade --version=1.1.0

Basically, to create your own JSX types in Deno, you just need to complete the following steps:

1) Think of a name for your framework. For demonstration, I'll use the name Spongebob.

2) Create a tsconfig.json file with the default Deno tsconfig.

3) Update the value of "jsxFactory" in the tsconfig.json to "Spongebob.createElement".

4) Create a file named jsx.ts with the following content:

export namespace Spongebob {
  export const createElement = (tag: string | Function, props: object, ...children: any[]) => {
    if(typeof tag === 'function') {
      return tag({...props, children})
    }
    else {
      return [tag, props, children]
    }
  }
}
declare global {
  namespace JSX {
    interface IntrinsicElements {
      div: {
        id?: string
        style?: { }
      }
    }
  }
}

5) To try out the JSX types, create a file named client.tsx.

import { Spongebob } from "./jsx.ts";

const EntryComponent = () => {
  return (
    <div id="patrick">
      <MySubComponent drugs={["rick", "morty"]} />
    </div>
  );
};

const MySubComponent = (props: { drugs: string[] }) => {
  return (
    <div>
      {props.drugs.map((drug) => <div>{drug}</div>)}
    </div>
  );
};

console.log(JSON.stringify(<EntryComponent />, null, 2));

6) Run this command to test out.

deno run --config tsconfig.json client.tsx

By the way, if you are lazy but you want to try out, you can refer to this repository.
Thank you for reading!

Why deps.ts and mod.ts is BAD in Deno

WJH — Tue, 09 Jun 2020 02:10:00 +0000

If you read the official Deno manual, you'll notice that the author advices you to contain all dependecies into one file.

Similarly, if you're creating a library, the de-facto standard is to export all modules in a single mod.ts file.

Somehow, this convention is suppose to make the development experiences better.

But instead, let me tell you why this convention is doing the opposite, which is making the development experience worse by increasing compile time (around 200% based on my simple benchmark).

If you want to look at benchmarks, check it out at this repository.

Imagine we have a deps.ts:

export {A} from 'https://deno.land/x/a/mod.ts'
export {B} from 'https://deno.land/x/b/mod.ts'

And a main.ts file:

import {A} from './deps.ts'

By running deno run main.ts, Deno will actually also resolve dependencies of B and typecheck thems even if main.ts don't really need them, imagine B also imports from its own deps.ts, and so on and so forth.

Ultimately, most of the compile time is wasted on compiling unused imports.

Moreover, if you try to bundle it by doing deno bundle main.ts, you'll notice that the bundle output also contain B and its dependencies because Deno do not support tree shaking.

So how can this problem be solved? Easy, just use direct URL imports! By doing so, you will have improved compile time and improved bundle size.

// main.ts
import {A} from 'https://deno.land/x/a/mod.ts'

These are all the problems we have when we are using npm.

You can find Ryan Dhal, the creator of Deno talking about this problem here.
Do you remember that when you tries to import a Lodash function into your code and suddenly the bundle size got so huge?

So how the Lodash community solves this? They do it by publishing a package for each function.

Therefore if we want to avoid:

unnecessary long compile time
unnecessary huge bundle size
Deno packages collapsing into a black hole.

The whole Deno community needs to stop placing all dependencies/export into one deps.ts/mod.ts file.

If we continue to use deps.ts and mod.ts, we will hinder the development experience of Deno developers by wasting their precious time waiting to compile unused dependencies.

Here's what I propose for managing dependancies, so instead of putting every dependencies in single deps.ts like this

// deps.ts
export {A} from 'https://deno.land/x/a/mod.ts'
export {B} from 'https://deno.land/x/b/mod.ts'

Export each of them as separate files under the deps folder.

// deps/a.ts
export {A} from 'https://deno.land/x/a/mod.ts'

// deps/b.ts
export {B} from 'https://deno.land/x/b/mod.ts'

Ok, without mod.ts how do we allow library users to discover API easily?
Simple, instead of placing all export into a single mod.ts, split them into separate files under the mod folder.

For example, instead of having:

// mod.ts
export {A} from './a.ts'
export {B} from './b.ts'

Do:

// mod/a.ts
export {A} from '../src/a.ts'

// mod/b.ts
export {B} from '../src/b.ts'

Last but not least, if the whole Deno community ditch this deps.ts/mod.ts practice, Deno by itself might not even need to implement tree-shaking and skip-unused-import features (which is tremendously difficult to implement).

It's like how social distancing prevented the spread of Corona virus instead of relying on vaccine.

Please if you think this article make sense, and for the greater good of Deno's future, please share it with your fellow Deno developers.

How to reuse 100% stateless React components?

WJH — Thu, 11 Jul 2019 15:33:12 +0000

NOTE: This post is not complete yet.

This post is inspired by the Elm architecture

Before continue reading, please allow me to clarify some assumptions:
(1) Performance does not matter
(2) There are only 2 kinds of props, namely view props and action props.
(3) We also have a bunch of actions and reducer.

The following is an example on how can we reduce duplicated code and boilerplates when dealing with purely stateless component that needs to be reusable.

Basically, this is how I do it:
(1) Declare the view props of the component as an interface
(2) Declare an initialize function for the view props
(3) Declare the action props of the component as an interface (NOTE: each action should return the respective view)
(4) Declare the initialize function for the action props

Example 1: SignUpDialog

Imagine we want to build a sign up dialog that will be reused by a lot of pages.

export interface SignUpDialogView {
  username: string,
  password: string,
  open: boolean
}

export const initSignUpDialogView = (): SignUpDialogView => ({
  username: '',
  password: '',
  open: false
})

export interface SignUpDialogActions {
  onUsernameChange:    (e: React.ChangeEvent<HTMLInputElement>) => SignUpDialogView,
  onPasswordChange:    (e: React.ChangeEvent<HTMLInputElement>) => SignUpDialogView,
  onSignUpButtonClick: () => SignUpDialogView,
  onCancelButtonClick: () => SignUpDialogView
}

export const initSignUpDialogActions = (
  view: SignUpDialogView, 
  update: (view: SignUpDialogView) => void 
) => ({
  onUsernameChange:    e  => update({...view, username: e.target.value}),
  onPasswordChange:    e  => update({...view, password: e.target.value}),
  onSignUpButtonClick: () => update({...view, open: false}),
  onCancelButtonClick: () => update({...view, open: false})
})


export const SignUpDialog: React.FC<{
  view: SignUpDialogView,
  actions: SignUpDialogActions,
}> = (props) => {
  const {view, actions} = props
  return (view.open &&
    <div>
      Username: 
      <input value={view.username} onChange={actions.onUsernameChange}/>
      Password: 
      <input value={view.password} onChange={actions.onPasswordChange}/>
      <button onClick={actions.onSignUpButtonClick}>Sign Up</button>
      <button onClick={actions.onCancelButtonClick}>Cancel</button>
    </div>
  )
}

Let say we want to use the SignUpDialog in BuyPage (which is stateful):

export class BuyPage extends React.Component<{}, {
  signUpDialogView: SignUpDialogView
}> {
  constructor(props) {
    super(props)
    this.state = {
      signUpDialogView: initSignUpDialogView()
    }
  }
  render() {
    const {signUpDialogView} = this.state
    return (
      <div>
       Buy something
       <SignUpDialog 
         views={signUpDialogView}
         actions={initSignUpDialogActions(
           signUpDialogView, 
           signUpDialogView => this.setState({signUpDialogView})
         )}
         />
      </div>
    )
  }

}

By doing so, you will have 100% customisability, which is not possible to achieve using stateful components.

How? We can achieve customisability using the spread operator.

Suppose we want to capitalise the username:

<SignUpDialog 
  views={{
      ...signUpDialogView,
      username: signUpDialogView.username.toUpperCase()
  }}
  actions={initSignUpDialogActions(
    signUpDialogView, 
    signUpDialogView => this.setState({signUpDialogView})
  )}
/>

Example 2: DatePicker

Now, let's look at another more realistic example, suppose we want to create a DatePicker that can be used by others.

This time, I will leave out the implementation details, because I wanted to highlight the concept only.

Similarly, we will follow the 4 steps.

// Declare view props
export interface DatePickerView {
  currentDay: number,
  currentMonth: number,
  currentYear: number
}

// Declare action props
export interface DatePickerActions {
  chooseDate: (date: Date) => DatePickerView
  changeMonth: (month: number) => DatePickerView
}

// Declare init view function
export const initDatePickerView = (): DatePickerView => ({
  // implementation . . .
})

// Declare init action props
export interface initDatePickerActions = (
  view: DatePickerView,
  update: (view: DatePickerView) => void
): DatePickerActions => ({
  // implementation . . .
})

Now, here's the component:

export const DatePickerDialog: React.FC<{
  view: DatePickerView,
  actions: DatePickerActions,
  update: (view: DatePickerView) => void
}> = (props) => {
  // implementation detail
}

Then, when you want to use it in XXXCompnent:

export class XXXComponent extends React.Component<{}, {
  datePickerView: DatePickerDialogView
}> {
   constructor(props) {
     super(props)
     this.state = {
       datePickerView: initDatePickerView()
     }
   }
   public render() {
     const {datePickerView} = this.state
     return (
       <DatePicker
         view={datePickerView}
         actions={initDatePickerActions(
           datePickerView,
           datePickerView => this.setState({datePickerView})
         )}
         />
     )
   }
}

With this approach, the user of DatePicker can even customise the the navigating experience of the calendar, suppose we don't want to allow user to access to the month of July:

export class XXXComponent extends React.Component<{}, {
  datePickerView: DatePickerDialogView
}> {
   constructor(props) {
     super(props)
     this.state = {
       datePickerView: initDatePickerView()
     }
   }
   public render() {
     const {datePickerView} = this.state
     const datePickerActions = initDatePickerActions(
       datePickerView,
       datePickerView => this.setState({datePickerView})
     )
     return (
       <DatePicker
         view={datePickerView}
         actions={{
           ...datePickerActions,
           changeMonth: month => 
             // If's its July, we make it to August
             datePickerActions.changeMonth(month === 7 ? 8 : month)

         }}
         />
     )
   }
}