Big Little Lies,
Big Little Types

Making React More Type Safe With Type-Tagging in Scala.js

Type-Tagging

Tag a type with another type
Augment the Slinky/React API
Use that other type to enforce rules at compile time
Make illegal states and values unrepresentable
Enforce order of function calls

A Bit About Me

Jason Pickens ( @steinybot )
Father of 4 (2 human)
Graduate at Orion Health in 2010
First intro to FP and Scala in 2013
Did a stint at Lightbend
Went to dinner with the Scala team
Now at Goodcover
Writing Scala professionally for ~7 years

Teaser

Apple
Banana
Cherries * 5

This is a little teaser of the React app we will
be fixing up today.

This is the TypeScript version.

It renders an unordered list with list items, one
of which has an amount.

React

1) Elements
2) Component and Props

Untyped Children

Apple

Banana

Cherries * 5

1) The type of children is ReactElement,
   i.e. untyped.
2) Pass in any HTML element
3) Get semantically invalid HTML

Scala.js

Scala for the web

Now a built-in target for the Scala compiler
Outputs .sjsir and .class files
Scala.js linker produces .js files
Same semantics as JVM (mostly)
Very good JavaScript interoperability
Generate Scala.js facades from TypeScript (ScalablyTyped)

1) Enough about Typescript let's move on to
   Scala.js

2)
3)
4)
5)

6) JVM semantics with JS interop?
- 2 different type hierarchies (Any and js.Any)
- 3 different implementations:
  - 1) Scala types - not visible to JS
  - 2) JS native types -
       JS types implemented in JS with Scala.js
       facade
  - 3) Scala.js non-native types -
       JS types implemented in Scala.js

7) ScalablyTyped

Slinky

Slinky is a Scala.js library for writing React
apps.

The API tries to match as close as possible to the
JS API.

Slinky

1) Here I'm highlighting the HTML elements or
   "tags".
2) And these are the components and their props.
3) NOTE: It looks pretty close the TS + JSX

Slinky

The previous slide showed the components
implemented as just functions which have some
limitations.

React doesn't see these as component and so they
can't use hooks (we will see hooks a bit later).

Here they are FunctionalComponents with case
classes for props.

Case classes are essentially record types.

That @react annotation is a macro which reduces
some boilerplate.

Typed Children

1)
Back to the problem!

We have a RedList component which takes any
ReactElement.

2) If we pass in a paragraph then it compiles.

3)
What we really want is one that only takes list
items,

like with this hypothetical API where the children
are TypedReactElements of list item tags.

Let's see how we might make this TypedReactElement.

Value Class

1)
Let's try something simple, a value class.

A value class is a wrapper around an existing
value.

It extends AnyVal.

It is just like other value types such as Int,
Double, Boolean.

It might end up being boxed and unboxed.

NOTE: How this has the Result type parameter.

2)
We don't want to have to manually wrap
ReactElements so we create an implicit conversion
from a tag to a TypedReactElement.

The type of tag, WithAttrs already has the result
so we pass that along.

3) We also want to automatically unwrap it.

4)
Here it is in action.

NOTE: We are going from a WithAttrs to a
TypedReactElement automatically and the Result
type stays.

-------------

Now if we look back at our example we get what we
wanted.

There is no implicit conversion from
WithAttrs[paragraph] to
TypedReactElement[list item]

Unexpected Allocation

The downside is that if we look at the byte code
we see there is a new instance being created.

What About WithAttrs?

You might have picked up that if WithAttrs
already has the Result type then why not just
use that?

As you can see here this also fails to compile
which is what we want.

Remember KeyAddingStage?

1)
Here I've updated the example to add keys to each
of the list items.

The QuantifiedListItem is just a function
which is going to return a WithAttrs.

WithAttrs already has all its attributes and so
where does the key go?

2)
We can try and make QuatifiedListItem a
FunctionalComponent.

Remember what we get from applying props to a
FunctionalComponent?

It is a KeyAddingStage. That has a withKey method.

3)
But that ain't going to work.

KeyAddingStage doesn't know about our Result type.

withKey returns an untyped ReactElement not our
TypedReactElement.

TypedKeyAddingStage?

1)
So we need the KeyAddingStage to retain the
Result type too.

How about creating a TypedKeyAddingStage?

2)
If we try the same thing with a value class then
we get this compilation error.

Ok that isn't going to work. Now what?

Type Alias

1)
We can try something else.

Scala has a simple feature called a type alias.

We can take whatever types we like (real or not)
and give them a new name.

In this case we take the untyped KeyAddingStage
and create an intersection with a new trait
called Tag.

2)
Next we create a function call unsafe which can
take an untyped KeyAddingStage and tag it with
the Result type.

This is named unsafe because there is nothing
restricting what Result can be.

3) So far so good.

4)

5) Now we run it...

6)
And get a runtime exception.

So the cast really is unsafe.

Structural Refinement

1)
Now for the real trick.

We take the previous type alias...

2)
And add this funny looking thing called Base.

Base is a type alias but the right hand side has
this weird block looking thing.

This is called a Structural Refinement.

In this case it is refining the Any type (no
identifier before the opening bracket) and it has
another nested type alias with some arbitrary name.

3) Now this runs without blowing up at runtime.

Avoiding Allocation

What is really going on?

Here I'm showing a diff of the byte code before
and after adding the refinement type.

We can see that the result of the unsafe method is
a java/lang/Object not a scala/scalajs/js/Array.

It was a js.Array because that is the type of an
unboxed KeyAddingStage.

Now the compiler has given up trying to check
that our cast was safe. Yus!

Extension Methods

1)
Now if we remind ourselves of the example, we have
the TypedKeyAddingStage but withKey is still going
to return an untyped ReactElement.

2)

3)
We need to add a new method to our
TypedKeyAddingStage.

It can't go on Tag because remember at runtime it
is being treated as just an Object and the real
type is actually a js.Array.

We can use an extension method on our Tag type.

I couldn't find a way to have it override the
existing withKey method so it's named withKeyTyped.

Normally extension methods go on a value class but
we already tried that so we use the inline hint.

4)
5)

6)
Now we are getting close but we still have this
manual call to unsafe.

TypedFunctionalComponent

1)
Here is the definition for Slinky's
FunctionalComponent.

It's not exact but close enough.

2)
We want to create an alias that has both a Props
and a Result type.

The Props are handled the same.

3)
The only other difference is that we say that the
result of our TypedFunctionalComponent is a
TypedKeyAddingStage[Result]

4)

5)
Here is the apply method for Slinky's
FunctionalComponent.

6)
We create the same thing but replace all the
untyped bits with our typed ones.

7)
Result of the render function must be a
TypedReactElement.

8)
Specify the Result type of the
TypedFunctionalComponent.

9)
Call the untyped FunctionalComponent apply method
and cast the result.

10)

11)
Make our QuantifiedListItem a
TypedFunctionalComponent that returns a li.tag.

12) And finally we can drop that call to unsafe.
13) Now we have got a fully typed API.

Refined Types

1)
Something that sucks with the types of our props
is that they are not very precise.

2)
We can use Refined types from the Refined Scala
library to tag types with predicates such as an
Int that must be positive and a String that is
trimmed and non-empty.

Now these nonsense values will not compile.

3) Valid values will compile.

Inside Refined

1)
For the curious among you, you can see that
Refined is a value class.

2)
It does some crazy macro shenanigans to validate
the value at compile time.

3)
Validations are just predicate functions, a
description, and a value of the tag.

Unsafe Hooks

1) One last example.
   Here we have a FunctionalComponent that uses
   hooks to access its state and run effects.

2) It has state for some messages.

3) State for some query parameters.

4) It uses an effect hook with a callback.

5) The callback appends a loading message.

6) Sends a fake request to load data and add a
   loaded message when it is done.

7) It has some cleanup to remove the timeout if
   the component is unmounted.

8) Lastly it renders the messages in a textarea.

9) If we run this...

10) We get an infinite render loop.

Safer Hooks

Loading data with params: Params(,10)
Data loaded.

1)
What you ought to do is not call setState from
within an effect but if you do...

2)
Ensure to provide some dependencies.

React will only run the effect if the dependencies
change.

3) This time...

4) It renders the messages as expected.

Safe...err Hooks

1) What if we want to modify the params in the
   render function?

2) We could set the text to foo if it is empty.

3) Now...

4)
Infinite render again... Huh!?

React uses Object.is to compare the dependencies.

copy creates a new instance so Object.is will
return false.

5) The solution is to memoise the result.

6) Now it is fine but what a foot gun!

Stable Tag

Type-tagging to the rescue!

Here is our good old newtype boilerplate again
but for a type called Stable.

Something is considered stable if it is safe to
use with Object.is and as a dependency to a hook.

BTW: There is a library that has a macro which
expands to this but it has some subtle differences.

Safety Hooks

1)
Now we replace all the hooks with safe versions.

This is the same useEffect hooks we saw before but
it requires Stable dependencies.

2) The one we want returns a cleanup callback.

3)
useState should also return a stable value.

The real implementation of this is far more
complicated but this shows the general idea.

4) And lastly, useMemo is the other way to obtain
a stable value.

Safest Hooks

1)
If we use these new hooks, this example no longer
compiles since it is not stable.

Copying a stable value is not stable which is what
we want.

2) Memoising the copy and it compiles

Type-Tagging

Tag a type with another type
Use that other type to enforce rules at compile time
Augment an existing API
Make illegal states and values unrepresentable
Enforce order of function calls
Fewer bugs
More maintainable code

Type-Tagging

Approaches shown:
- Value Class (Scala 2+)
- Based on Newtype (estatico/scala-newtype)
Other variations:
- Shapeless' @@ (milessabin/shapeless)
- Scalaz's @@ (scalaz/scalaz)
- Opaque Types (Scala 3)

Thanks!

Slides and code: steinybot/big-little-types

Libraries coming soon...

Big Little Lies, Big Little Types

Making React More Type Safe With Type-Tagging in Scala.js

Type-Tagging

A Bit About Me

Teaser

React

Untyped Children

Scala.js

Scala for the web

Slinky

Slinky

Slinky

Typed Children

Value Class

Unexpected Allocation

What About WithAttrs?

Remember KeyAddingStage?

TypedKeyAddingStage?

Type Alias

Structural Refinement

Avoiding Allocation

Extension Methods

TypedFunctionalComponent

Refined Types

Inside Refined

Unsafe Hooks

Safer Hooks

Safe...err Hooks

Stable Tag

Safety Hooks

Safest Hooks

Type-Tagging

Type-Tagging

Thanks!

Big Little Lies,
Big Little Types