DEV Community: Christian Gill

Recap of the state management history in React

Christian Gill — Thu, 01 Sep 2022 10:25:02 +0000

This post was originally a note on my Digital Garden 🌱

Disclaimer: this is wildly inaccurate, I’m just writing it down from memory as a recap of where we came from to better understand where we are at today and what could come next.

Wild West

When React was first introduced it was advertised as the V in MVC. For those that don’t know, MVC stands for Model-View-Controller, in other words, React’s initial concern was only about the view.

These were the days of createClass. See React Without ES6 if you have no idea what I’m talking about.

People were using React as the view layer on top of other frameworks like Backbone or even Angular.js 🤪 My guess is even Facebook had no idea what to do about state in React those days.

Two way data binding and DOM mutations were the way people managed state updates at the time.

Flux

Then came Flux.

Application Architecture for Building User Interfaces

Yay we were saved! There was finally a way to manage state for React applications that made sense.

The problem with Flux is at the moment it was only an architecture pattern, there was no library. You had to build your own. I remember using bloody-flux for an small side project. Which turns out is still up an running on GitHub Pages: http://gillchristian.github.io/patriarchs-timeline.

Time travel 🚀

Then Dan Abramov introduced Redux on react-Europe 2015 🤯

Redux took some really cool ideas and brought them to React. And together came the possibility of fancy tooling. I remember the first time I tried time travel debugging, it was so cool! Your Angular.js application couldn’t do that!

Around the same time some other state management alternatives, like MobX, started to show up.

Redux itself became a whole thing, it inspired other frameworks like Vue and Angular to adopt similar patterns.

Since it was a relatively low level tool, just like React, that gave a lot of freedom to the user to find different ways to make it work for them. In particular when it came to async operations Redux itself gave no official solution. The most popular options are redux-thunk, redux-observable, and redux-saga. There were probably a dozen more options out there.

The problem with Redux was how verbose it could get to have all your state in there. And messing up the performance of the application was relatively easy as well.

GraphQL as state management?

Then another technology from Facebook showed up and became popular. The hype was real, GraphQL would save us! From the perfectly fine and working RESTful approach to developing APIs that is.

With the GraphQL revolution people realized that for plenty of applications data fetching is so coupled with state management that it was probably a good idea to marry the two into a single ~~abomination~~ solution. And thus Apollo and Relay showed up.

GraphQL never seemed like a great thing to me, probably because I never faced the problems it’s meant to solve. And so I never got into Apollo or Relay, so that’s all I can say. ¯\_(ツ)_/¯

Hook me up, would ya?

Up until this point people would swear by the separation between presentational and container components, also called dumb and smart components.

The idea was that some components should care only about the presentation and others about the logic. Presentational components would not have any kind of logic or state and concern not with the model of the application, after all they were truly dumb. Container components, on the other hand, were the smart ones, all the state, interactions with the model, subscription to Redux, etc. would happen there and they would just render a single presentational component.

In other words, separation of concerns. Problem was people took it very seriously, I’ve had PR rejected and blocked because a component that was rendering a piece of UI also had some local state in it, say a toggle, that had no effect in the rest of the application. As you can see I’m still salty about it 😂

At this point hooks showed up and the line started to blur, a lot, to the point there was no line anymore. Hooks made it super easy to reuse logic and any component that needed that logic could use it. There’s still a need for highly reusable presentational components, of course, but nobody talks about containers anymore.

With the introduction of hooks and the PTSD people suffered from how verbose Redux can become devs started to write more and more local state.

There was no need to convert a functional component to a class to add state, that, I think, is what made the whole difference. There was no friction, only a useState away from it.

However local state is not a silver bullet. Nothing is, besides actual silver bullets, those used to kill a werewolf or witch.

The problem with local state, whether it is with hooks or not, is that whenever another part of the application that isn’t down the three where the state is defined needs that piece of state it forces the state to be moved up to a common parent.

It is not possible for X to access the state defined in A.

Instead we have to move the state up to a common parent.

Do this process several times and you are suddenly longing for Redux again.

Context does solve this problem, but just like Flux, it’s a very low level solution and defining context by hand tends to be messy and verbose. Ain’t nobody got time for that!

Going Atomic

This is when solutions like Recoil and Jotai come into play. The elevator pitch is: imagine if useState was global.

By defining this atom data structure one is able to share state between different parts of the component three without the need to lift state up to the common parent.

Boom 💥 any component can access the same state!

If I’m not mistaken these ideas of atoms come from Clojure.

State is a job for the feds fetching

Remember coupling the state management and data fetching layers together? Turns out that we don’t need GraphQL for that.

Libraries like react-query and SWR offer a very thin layer around data fetching that is able to manage your state as well. Or at least the state that has to be fetched from some remote location.

This approach can be seen as an inversion of control, instead of having the state management layer take care of the data fetching in some way or another, we now have the data fetching layer taking care of the state.

By leveraging caching strategies, like state-while-revalidate (that’s where SWR name comes from), this libraries can return (stale) data quickly and swap it for the fresh one once the new request resolves.

From SWR docs:

With SWR, components will get a stream of data updates constantly and automatically. And the UI will be always fast and reactive.

From react-query docs:

Fetch, cache and update data in your React and React Native applications all without touching any "global state".

React Query […] in more technical terms, it makes fetching, caching, synchronizing and updating server state in your React applications a breeze.

What’s next?

I don’t know what interesting, revolutionary, and wheel-reinventing pattern will become popular next. But all we can do is wait and be ready to rewrite our applications when that happens.

Or, maybe, come up with another pattern ourselves to speed up the process 😎

Generic discriminated union narrowing

Christian Gill — Wed, 31 Aug 2022 08:33:43 +0000

This post was originally a note on my Digital Garden 🌱

When working with discriminated unions, also known as tagged unions, in TypeScript one often has to narrow down a value of the union, to the type of one of the members.

type Creditcard = {tag: 'Creditcard'; last4: string}

type PayPal = {tag: 'Paypal'; email: string}

type PaymentMethod = Creditcard | PayPal

Given the above type, we would want to either check that a value is of PayPal type to show the user's email or Creditcard type to show the last 4 digits.

This can be do simply but checking the discriminant property, in this case tag. Since each of the two members of the PaymentMethod type have different types for the tag property, TypeScript is able to, well, discriminate between them to narrow down the type. Thus the tagged union name.

declare const getPaymentMethod: () => PaymentMethod

const x = getPaymentMethod()

if (x.tag === 'Paypal') {
  console.log("PayPal email:", x.email)
}

if (x.tag === 'Creditcard') {
  console.log("Creditcard last 4 digits:", x.last4)
}

To avoid this explicit check of the tag property you might define type predicates, or guards.

const isPaypal = (x: PaymentMethod): x is PayPal =>
  x.tag === 'Paypal'

const x = getPaymentMethod()

if (isPayPal(x)) {
  console.log("PayPal email:", x.email)
}

The problem with such guards is they have to be defined for each member of each discriminated union type in your application. Or do they?

If you are like me you probably wonder how to do this generically for all union types. Could this be even possible with some TypeScript type level black magic?

The short answer is yes.

const isMemberOfType = <
  Tag extends string,
  Union extends {tag: Tag},
  T extends Union['tag'],
  U extends Union & {tag: T}
>(
  tag: T,
  a: Union
): a is U => a.tag === tag

The proper response is, what the ~~f*ck~~ ~~heck~~ hack?

Ok, let me explain.

We need four generic types, in practice the caller will not need to pass these, they are there with the purpose of allowing TypeScript to do its type inference business.

Notice that for all of them we are not allowing any type but instead using extends to inform TypeScript that those generic types should meet certain conditions.

Tag is the union of all the tags of Union, it should extend the base type of our tag, in this case string
Union is our tagged union type, it has to be an object with a tag property of type Tag
T is the specific tag we want to narrow down with, and thus it should extend the Tag type
And U is the specific member of Union we want to narrow down to, it should extend the Union and its tag should be T, the specific one we want

Tag and Union are there to define the union type we want to narrow down from and T and U, for the ~~lack~~ laziness of finding better names, are where the magic happens since they are the narrowed down types we expect to get to.

const x = getPaymentMethod()

if (isMemberOfType('Creditcard', x)) {
  console.log('Creditcard last 4 digits:', x.last4)
}

if (isMemberOfType('Paypal', x)) {
  console.log('PayPal email:', x.email)
}

Et voilà, it works!

And this is how TypeScript fills in the holes of the generics.

There's a variation of isMemberOfType that I like to use which works as a sort of getter instead of type predicate.

const getMemberOfType = <
  Tag extends string,
  Union extends {tag: Tag},
  T extends Union['tag'],
  U extends Union & {tag: T}
>(
  tag: T,
  a: Union
): U | undefined =>
  isMemberOfType<Tag, Union, T, U>(tag, a) ? a : undefined

The usage is similar, but it requires a null check, of course.

const cc = getMemberOfType('Creditcard', getPaymentMethod())

if (cc) {
  console.log('Creditcard last 4 digits:', cc.last4)
}

const pp = getMemberOfType('Paypal', getPaymentMethod())

if (pp) {
  console.log('PayPal email:', pp.email)
}

There’s a little problem, the inferred type it returns is not so nice, since it's based on our definition of the generic (U extends Union & {tag: T}).

In practice this is not a problem, but since we got this far, we can keep going, right?

Enter Extract, one of TypeScript's type utilities:

Constructs a type by extracting from Type all union members that are assignable to Union.

For example, in the following case T0 will be of type 'a':

type T0 = Extract<'a' | 'b' | 'c', 'a' | 'f'>

The definition is simple:

// Extract from Type those types that are assignable to Union
type Extract<Type, Union> = Type extends Union ? Type : never

With our current definition of isMemberOfType and getMemberOfType, the returned type extends union: U extends Union & {tag: T}.

In the case of PayPal it would be PayPal & { tag: 'PayPal' }. By adding Extract to the returned type we can get PayPal instead.

const isMemberOfType = <
  Tag extends string,
  Union extends {tag: Tag},
  T extends Union['tag'],
  U extends Union & {tag: T}
>(
  tag: T,
  a: Union
): a is Extract<Union, U> => a.tag === tag

const getMemberOfType = <
  Tag extends string,
  Union extends {tag: Tag},
  T extends Union['tag'],
  U extends Union & {tag: T}
>(
  tag: T,
  a: Union
): Extract<Union, U> | undefined =>
  isMemberOfType<Tag, Union, T, U>(tag, a) ? a : undefined

Much cleaner this way! Now I can sleep in peace …

In conclusion, we went from simple discriminant property check to a monstrosity of generics and type inference that achieves the same thing. Should you use these utilities in production? ~~Of course! Even more so if it will confuse our colleagues.~~ Maybe not, but it was fun to discover some of the cool stuff we can achieve with TypeScript.

Here's the final version of the examples in the TypeScript Playground.

Code Reviews Comments Convention

Christian Gill — Tue, 14 Jul 2020 07:22:49 +0000

A convention to clarify the intention of a comment in a Pull Request (PR) review using prefixes.

Mandatory xkcd

Although it is possible to express the intent in the way the comment is written, it is easier to do so with a simple prefix. Not only it requires less words but it is also easier to take a quick look at the comments and understand what is the intention/meaning of each one.

My rule of thumb is, only reviews that include [req] and/or [q] should Reject the PR. In other cases just make the review a Comment or Approve.

Prefixes

[req] (requested change)

Reviewer believes something should be changed.

[nth] (nice to have)

Reviewer suggests something better/more thorough/common pattern etc.

[pp] (personal preference of the reviewer)

This shows own opinion on style/unification etc. Might influence the author to apply some changes, but does not provide any benefits (it's not for optimization/better interfaces etc.)

[q] (question)

Reviewer would like to get some explanation on topic.

[fixed]

Author fixed/changed based on the comment.

[wont-fix]

Author declines the request. It should be first discussed with reviewer and explained in comment.

Credits

To whoever came up with this convention 😅

If you know let me know, so I can credit & thank them! 🙏

Happy and safe coding ✌️

Composing predicates

Christian Gill — Wed, 08 Jul 2020 21:44:02 +0000

A few days ago I was writing some validation functions that were basically a composition of several other predicates.

Which would look something like this:

predA :: a -> Bool

predB :: a -> Bool

predC :: a -> Bool

predABC :: a -> Bool
predABC a = predA a && predB a && predC a

A Haskeller would be bothered by having to manually pass a to all the predicates. A true Haskeller would not, probably. But I'm far from that level of enlightenment. So I decided to find a way to compose predicates.

Note that by compose I mean not function composition but to combine two predicates together to get a new one. Either by conjunction (&&) or disjunction (||).

Monoids

Since Monoids let us combine things, they were bound to show up in my search.

As we said, booleans (and predicates) can be combined in more than one way, so there isn't a default Monoid instance for Bool.

Data.Monoid defines:

All for conjunction.
Any for disjunction.

λ> getAll (All True <> All False)
False
λ> getAll (All True <> All True)
True

λ> getAny (Any True <> Any False)
True
λ> getAny (Any False <> Any False)
False

Since the goal is to compose not booleans but predicates, we need to some mapping and folding to achieve that.

predABC :: a -> Bool
predABC = getAll . foldMap (All .) [predA, predB, predC]

λ> predABC a
True
λ> predABC b
True
λ> predABC z
False

Success? Well, it works and we can add as many predicates as we like with very low effort. But to compose just three predicates I'm not sure if it's worth.

Applicative

If there are two ways to do this, there has to be a third.

From #100DaysOfFP Day 33

Applicative instance of (->) functions allows to apply an argument (x) to two unary functions (f & g) and then apply the result of each to a third function (h) to produce the result (y).

That's exactly what I want!

(&&&) :: (a -> Bool) -> (a -> Bool) -> a -> Bool
f &&& g = (&&) <$> f <*> g

(|||) :: (a -> Bool) -> (a -> Bool) -> a -> Bool
f ||| g = (||) <$> f <*> g

Composing the predicates is way simpler now

predABC :: a -> Bool
predABC = predA &&& predB &&& predC

And is possible to use both combinators. Which was not possible with Monoids (most probably is possible but not as straightforward).

predAandBorC :: a -> Bool
predAandBorC = predA &&& predB ||| predC

Yup, I'm going to stick with those for combining my predicates 😏

One more thing, I declared the types of (&&&) and (|||) specified for the function instance of applicative. But they could work with any applicative.

(&&&) :: Applicative f => f Bool -> f Bool -> f Bool
f &&& g = (&&) <$> f <*> g

(|||) :: Applicative f => f Bool -> f Bool -> f Bool
f ||| g = (||) <$> f <*> g

λ> (Just True) &&& (Just False)
Just False
λ> (Just True) &&& (Just True)
Just True
λ> (Just False) &&& (Just False)
Just False

Yet another thing. liftA2 could make the implementations even shorter.

(&&&) :: Applicative f => f Bool -> f Bool -> f Bool
(&&&) = liftA2 (&&)

(|||) :: Applicative f => f Bool -> f Bool -> f Bool
(|||) = liftA2 (||)

Happy and safe coding 🦄

ZuricHac 2020

Christian Gill — Mon, 22 Jun 2020 11:44:39 +0000

Last weekend I participated in ZuricHac. It was an awesome event. Well organized 👏🙇 and full of interesting people!

ZuriHac is the biggest Haskell Hackathon in the world: a completely free, three-day grassroots coding festival organized by Zürich Friends of Haskell. It features fantastic keynotes, interesting tracks, and of course lots of hacking and socializing!

This year, due to Corona 🦠😷 the event took place online. Everything revolved around a Discord server. There were channels for particular projects people were hacking on, channels for the different tracks (beginner, intermediate and expert) and common channels to discuss the talks, hang out and share pictures of coffee ☕

Here's a small recap of the things I did and learned.

did

Joined 3 talks
- Languages all the way down by @rob_rix
- (Programming Languages) in Agda = Programming (Languages in Agda) by Philip Wadler
- Effects for Less by @lexi_lambda 🤯
Joined one live coding session on GHC language extensions. Write a GHC extension in 30 minutes by @RaeHaskell.
Joined one spontaneous call about lazy IO pintfalls when working with files by @me_coot.
Found some fellow Spanish speakers #lakeside-spanish (Spain, Argentina, Mexico, Guatemala, probably more!) 🇬🇹🇲🇽🇪🇸🇦🇷
Collaborated on tsearch.io and even got a contributor!!! 🤩
Participated in different conversations and reacted with tons of emoji 🥳

learned

Lazy evaluation / lazy IO one of Haskell main features. As much as it enables some good stuff it can also cause some problems. When reading files (readFile :: String -> IO String), the files are open but not read until the evaluation is forced which might result in too many open files issues. Since files are closed as soon as the content is read the solution is to force the evaluation. 🤕
Effect systems are all about abstraction of effects and being able to represent those effects in different ways.
Effect systems have performance penalties due to polymorphism.
The compiler (GHC) does a mind-blowing job optimizing code. 🤯
To there's some much the compiler can do. So is up to the developers to find ways to produce more optimized code.
Is important to know how and why the compiler optimizes (or not) certain code.
TypeScript is harder than Haskell. Being able to type JavaScript programs makes for a very complex type system.
Formal proof languages like Agda are less scary than they seem! 🤓

And a huge thanks to the organizers and everyone who made the event possible!

I look forward to participate next year in person.

TypeScript Short links

Christian Gill — Mon, 22 Jun 2020 11:20:16 +0000

If you know or use TypeScript you ought to be familiar with its Playground. It is an awesome tool, being able to play around with TypeScript on the browser, try things out. Is also great for collaboration, since the editor's state (code and config) is kept serialized in the URL, all it take is ctrl + s (or Cmd if you are in need Mac) and the link is on the clipboard and ready to be shared.

But then you paste the link on Slack and it is looonger than the yarn.lock of a React application 😰

A fairly short snippet results in something like this:

https://www.typescriptlang.org/play/index.html#code/PTAEBUE8AcFMGUDGAnAltALqayD2A3VAE1gGdQBHAV1UQGsBaAM1QA9RlZFcBbH2AHZEAhhlS4B5JrmQBYAFAhQ3PhNDDEiYoIykANKAwALWJFCkjuAO6gq0UKgGhIuKslCwiqDDNAAjYVJPBSU1ThV+IVFxSQA6BRCwADFfWFZhHmgAG1gIGAQUdCxEYSccAm1KGnpmNjJE0Gl3DBhcckdnV2b80gAuBPluSSxYKhzkUgA5Kh4-WHcAXlAAJliAdgBGAA5lre3dgBYFUfGpmbnkWJ94DGRSgHMACgBKAG4G0E+v74A9AH0AYCfqAGOZYDlEFhjKhyD4wbljLksqh7kYsH4aFkiANEFlAuQAKLpTI5ADCeNI5AA3gpPvxjLgiC9QDT5N9oaRYgJcBgACJcPGcIigJYbAAM7zZoAAvgppUA

That's a big nope from your coworkers who hate long links polluting the Slack history. And if you are anything like me you don't even like to be the one sharing long links either.

What if ... ?

What if those long links looked like this instead?

tsplay.dev/vwj58W

tsplay.dev/hello

Yet another link shortener

Yes there are already a ton of link shorteners out there. But it is great to have a dedicate one. It creates identity. When you see tsplay.dev you know it'll be some TypeScript code.

🛡️ It is also about security. You never know where tinyurl.com or bit.ly short-links could redirect to.

In the making

For now short links can only be created on tsplay.dev.

But we are working on a playground plugin to create short links right there in the playground. Which should be available when the new version of the TypeScript website is fully released.

By Nahuel 🎨 Joni 💻 & myself 💻

Apply me both lists

Christian Gill — Mon, 13 Jan 2020 22:22:17 +0000

As we saw in the previous one, Applicative allows to apply n-ary functions in a context. The context might be a parser, values that are potentially be errors, a list or a tree, optional values, IO actions, etc.

In my short learning experience so far, I've used it in practice for two things mostly.

Constructing values with data constructors that take several values. For example, those values would come from sequential parsers when working with parser combinators (like Parsec).

data User = User String String Int

-- "John Doe 26" -> User "John" "Doe" 26
parseUser :: Parser User
parseUser =
  User <$> (parseWord <* whitespace)
       <*> (parseWord <* whitespace)
       <*> parseAge

parseWord :: Parser String
parseAge :: Parser Int

whitespace :: Parser () -- consumes as much whitespace as possible

-- Defined in Control.Applicative
(<*) :: Applicative f => f a -> f b -> f a

(<*) is the lifted version of const, here is something I wrote about that. As we can guess from the signature, in this case it applies both parses (ie. both consume input) but returns the first one, ignoring the second.

And the other use case, applying n-ary functions to values that might not be there. In other words, when the context is Either or Maybe.

add <$> (Just 1) <*> (Just 2) -- Just 3
add <$> Nothing  <*> (Just 2) -- Nothing
add <$> (Just 1) <*> Nothing  -- Nothing
add <$> Nothing  <*> Nothing  -- Nothing

add <$> (Right 1)      <*> (Right 2)      -- Right 3
add <$> (Left "err 1") <*> (Right 2)      -- Left "err 1"
add <$> (Right 1)      <*> (Left "err 2") -- Left "err 2"
add <$> (Left "err 1") <*> (Left "err 2") -- Left "err 1"

Lists

Until last week I hadn't found a use case for Applicative when working with lists. I knew how it works but never had ~~an excuse~~ a reason to use it.

Let's take a look at the instance and some examples first.

(<*>) :: Applicative f => f (a -> b) -> f a -> f b

-- With [] applied to f (using TypeApplications extension)
(<*>) @[] :: [a -> b] -> [a] -> [b]

(+) <$> [1, 2, 3] <*> [1, 2, 3]
-- [2,3,4,3,4,5,4,5,6]

(,) <$> [1, 2, 3] <*> [1, 2, 3]
-- [(1,1),(1,2),(1,3),(2,1),(2,2),(2,3),(3,1),(3,2),(3,3)]

[(++ "!"), (++ "?")] <*> ["Hola", "Mundo"]
-- ["Hola!","Mundo!","Hola?","Mundo?"]

As we can see, it takes a list of functions ([a -> b]) and a list values ([a]) and applies all the functions from the first list to all the values from the second one, this results in a larger list (duh!). If list sizes are n and m, respectively, the size of the returned list is n * m.

That's not a use case that I find very often. Most of the time I have one function (a -> b) that I want to apply to a list of values ([a]). That's Functor's fmap (as well as (<$>)). Or I have a list of functions to apply to a single value. For example, it could be list of predicates and I want to check if all or some are True for a particular value.

allPass :: [a -> Bool] -> a -> Bool

anyPass :: [a -> Bool] -> a -> Bool

By the way, there are similar functions defined in Base:

and :: [Bool] -> Bool -- True when all are True

or :: [Bool] -> Bool  -- True when at least one is True

In the case of lists, what applicative does is apply all the functions too all the values.

Last week, playing around on small side project, till. I was trying to add the option to match several patterns against the same value and I found a use case for List's Applicative.

There's a match function that checks if a pattern matches a single line of the output.

match :: Pattern -> Line -> Bool

The output consists of a list of lines. When working with a single pattern, the solution is easy. Use any (from Base).

any :: Foldable t => (a -> Bool) -> t a -> Bool

any @[] :: (a -> Bool) -> [a] -> Bool

matchPattern :: Pattern -> [Line] -> Bool
matchPattern p lns = any (match p) lns

What about matching several patterns against the output?

matchAll :: [Pattern] -> [Line] -> Bool
matchAll ps lns = undefined -- ???

Applicative to the rescue 🎉

matchAll :: [Pattern] -> [Line] -> Bool
matchAll ps lns = or (match <$> ps <*> lns)

Let's dissect that 🔍

-- So we don't forget ;)
(<$>) @[] :: (a -> b) -> [a] -> [b]

(<*>) @[] :: [a -> b] -> [a] -> [b]

-- ^ notice the difference between <$> & <*> ;)

or :: [Bool] -> Bool

match :: Pattern -> Line -> Bool

-- the input
ps :: [Pattern]

lns :: [Line]

-- mapping first to partially apply the patterns to match
match <$> ps :: [Line -> Bool]

-- applying the lines
match <$> ps <*> lns :: [Bool]

-- reducing that to get our result
or (match <$> ps <*> lns) :: Bool

I like how elegant this looks thanks to Functor and Applicative 🎩

NOTE: I'm sure there are other ways to solve the problem, with better performance. Although in my use case both lists should be relatively short, usually between one and three patterns and around 100 or probably less lines of output.

Happy and safe coding 🦄

Why Applicative?

Christian Gill — Wed, 08 Jan 2020 23:34:52 +0000

When learning about the different type classes in Haskell the one I struggled the most with was, by far, Applicative.

Functor

Functor is, at least to some extent, straightforward. We take any unary functions and make them work on some (functor) context.

fmap :: Functor f => (a -> b) -> f a -> f b

-- or the infix version
(<$>) :: Functor f => (a -> b) -> f a -> f b

Say we have an increment function that works on Ints.

inc :: Int -> Int

λ> inc 1
2

By using fmap we can map any functor that contains an Int.

λ> fmap inc [1, 2, 3]
[2, 3, 4]
λ> fmap inc (Just 1)
Just 2
λ> fmap inc (Right 1)
Right 2

That becomes very clear when we align fmap with the function application operator.

($) ::                (a -> b) ->   a ->   b
(<$>) :: Functor f => (a -> b) -> f a -> f b

inc  $   1       --  2
inc <$> [1]      -- [2]
inc <$> (Just 1) -- Just 2

fmap is just function application inside a context.

By the way, we'll use the infix version from now.

Applicative

In the case of applicative it's not clear. Or at least it took longer to click for me.

(<*>) :: Applicative f => f (a -> b) -> f a -> f b

Comparing with ($) doesn't really help. Why would I want to also have the function in the context?

($) ::                      (a -> b) ->   a ->   b
(<*>) :: Applicative f => f (a -> b) -> f a -> f b

We said functors allow to apply a unary function in a context. But what happens if I want to apply a function with a higher arity?

add :: Int -> Int -> Int

add <$> (Just 1) -- ??

What does the repl says? 🦊

λ> :t add <$> (Just 1)
add <$> (Just 1) :: Maybe (Int -> Int)

Maybe (Int -> Int)? Yes, we saw that already in the (<*>) signature.

add <$> (Just 1) <*> (Just 2) -- Just 3

Let's dissect that 🔍

-- refresh these ones first :)
(<$>) :: Functor f => (a -> b) -> f a -> f b
(<*>) :: Applicative f => f (a -> b) -> f a -> f b

-- With Maybe applied (using TypeApplications extension)

(<$>) @Maybe :: (a -> b) -> Maybe a -> Maybe b

add :: Int -> Int -> Int

-- With Int applied in place of 'a'
(<$>) @Maybe @Int :: (Int -> b) -> Maybe Int -> Maybe b

-- With (Int -> Int) applied in place of 'b'
(<$>) @Maybe @Int @(Int -> Int)
--   (a   -> b)          -> Maybe a   -> Maybe b
  :: (Int -> Int -> Int) -> Maybe Int -> Maybe (Int -> Int)

add <$> (Just 1) :: Maybe (Int -> Int)

Here we see the first interesting thing. Since our add function takes two arguments (or to be more accurate one at a time). But we only provide one (the Int from Maybe Int), so it gets partially applied and returns a function (Int -> Int). So b is Int -> Int.

--     a  ->   b 
add :: Int -> (Int -> Int)

Note that parens aren't actually needed since the arrow (->) is right associative.

That was the first part of the expression. We are missing the applicative.

(<*>) @Maybe :: Maybe (c -> d) -> Maybe c -> Maybe d

-- With Int in place of 'c'
(<*>) @Maybe @Int :: Maybe (Int -> b) -> Maybe Int -> Maybe b

-- And also Int in place of 'd'
(<*>) @Maybe @Int @Int
  :: Maybe (Int -> Int) -> Maybe Int -> Maybe Int

Et voilà

add :: Int -> Int -> Int
add <$> (Just 1) :: Maybe (Int -> Int)
add <$> (Just 1) <*> (Just 2) :: Maybe  Int

Functor: apply unary functions in a context.

Applicative: apply n-ary functions in a context.

This is referred as lift in Haskell.

And the whole point of applying functions in such contexts is the semantics associated with them. It might be for validation, optional values (without null 😏), lists or trees of items, running IO actions, parsers.

When the context is Maybe:

λ> add <$> (Just 1) <*> (Just 2)
Just 3
λ> add <$> Nothing <*> (Just 2)
Nothing
λ> add <$> (Just 1) <*> Nothing
Nothing
λ> add <$> Nothing <*> Nothing
Nothing

When the context is Either:

λ> add <$> (Right 1) <*> (Right 2)
Right 3
λ> add <$> (Left "err 1") <*> (Right 2)
Left "err 1"
λ> add <$> (Right 1) <*> (Left "err 2")
Left "err 2"
λ> add <$> (Left "err 1") <*> (Left "err 2")
Left "err 1"

When the context is List:

λ> add <$> [1, 2, 3] <*> [1, 2, 3]
[2,3,4,3,4,5,4,5,6]
λ> (,) <$> [1, 2, 3] <*> [1, 2, 3]
[(1,1),(1,2),(1,3),(2,1),(2,2),(2,3),(3,1),(3,2),(3,3)]

☝️ More on that on the next one.

Conclusion

When learning functional programming all these type classes might seem scary. Developing a basic intuition of their purpose and usages is a big part of the process of getting comfortable using (and understanding) them.

I know there are more implications around Functor and Applicative that I have yet to discover. But as any learning process, it takes time. I'm sure more things will become clear and start sink in as I keep going.

But that's all for today.

Happy and safe coding 🎉

Progress tracking #100DaysOfFP

Christian Gill — Fri, 27 Dec 2019 08:46:36 +0000

// Detect dark theme var iframe = document.getElementById('tweet-1080944985715998720-763'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1080944985715998720&theme=dark" }

Going through a Twitter thread with +100 tweets is not handy at all. So here's the compilation of all the tweets for each day (so far).

Table of Content

01-10
11-20
21-30
...

01-10

Go to contents

// Detect dark theme var iframe = document.getElementById('tweet-1080979563700727808-324'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1080979563700727808&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1081220094838083585-637'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1081220094838083585&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1082757942171090945-549'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1082757942171090945&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1082759921274363910-269'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1082759921274363910&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1083128345490087937-332'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1083128345490087937&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1083128860911247360-617'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1083128860911247360&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1083642141509894144-882'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1083642141509894144&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1083643173505826817-388'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1083643173505826817&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1084936038215233536-116'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1084936038215233536&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1085304388749533185-7'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1085304388749533185&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1085655569380257793-914'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1085655569380257793&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1091263037674274818-501'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1091263037674274818&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1094569910062272512-813'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1094569910062272512&theme=dark" }

11-20

Go to contents

// Detect dark theme var iframe = document.getElementById('tweet-1097645845145628672-211'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1097645845145628672&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1100166083091288065-274'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1100166083091288065&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1106350004359307264-663'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1106350004359307264&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1110670777173594113-321'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1110670777173594113&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1115502145489514496-305'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1115502145489514496&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1128403336263344128-673'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1128403336263344128&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1128770065346830336-805'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1128770065346830336&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1136397217240158208-166'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1136397217240158208&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1161386789120237571-613'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1161386789120237571&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1161387596020375556-406'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1161387596020375556&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1173326782700953601-561'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1173326782700953601&theme=dark" }

21-30

Go to contents

// Detect dark theme var iframe = document.getElementById('tweet-1174067442592702465-188'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1174067442592702465&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1174067967434416128-977'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1174067967434416128&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1174436961110700032-762'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1174436961110700032&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1175878924926095360-668'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1175878924926095360&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1176272661346996236-831'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1176272661346996236&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1196176593326096384-617'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1196176593326096384&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1201142344000651264-918'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1201142344000651264&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1201574482017734657-581'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1201574482017734657&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1201614760724303874-27'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1201614760724303874&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1203789851528761346-24'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1203789851528761346&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1207675483313319936-448'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1207675483313319936&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1212090287595696128-747'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1212090287595696128&theme=dark" }

31-40

Go to contents

// Detect dark theme var iframe = document.getElementById('tweet-1215054708508962816-436'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1215054708508962816&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1216848419714715648-489'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1216848419714715648&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1229705223419105281-492'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1229705223419105281&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1236773673568215047-924'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1236773673568215047&theme=dark" }

...

41-50

Go to contents

...

51-60

Go to contents

...

61-70

Go to contents

...

71-80

Go to contents

...

81-90

Go to contents

...

91-100 🎉

Go to contents

...

Enough fp-ts to work with io-ts

Christian Gill — Thu, 19 Dec 2019 14:44:39 +0000

This is a small tutorial of what one needs to know about fp-ts to work with io-ts. In other words:

Just enough fp-ts to ~~to work with io-ts~~ be dangerous

what-ts now ?

Let's start by introducing these two libraries and what they are.

fp-ts

Typed functional programming in TypeScript

... a library containing implementations of common algebraic types in TypeScript

That seems to be clear. Ok, maybe not the algebraic types but that's not super important in practice.

io-ts

Runtime type system for IO decoding/encoding

Urhg, what?!

io-ts provides safe encoding/decoding. We can say is the proper way to do JSON.parse with types in mind. Check the library docs to learn more about it.

But why?

io-ts is part of the ecosystem of typed functional programming (FP) in TypeScript, fp-ts being the main library. So naturally io-ts does good use of fp-ts.

If you are familiar with (typed) FP, then why are you still reading? Or maybe you can finish and suggest some improvements to this post 😅

On the other hand, if you aren't familiar with (typed) FP and see the fp-ts website it might seem scary and feel like a lot of information to process. Specially the weird words. Well it is a bit scary, I agree with you. But for working with io-ts we need just a really ~~small~~ smol fraction of the library. Besides that, my advice is to approach it as you would approach any other API of a library you learning to use. I'm not gonna go full advocate of FP mode, just say that it's really worth to learn and a pleasure to work with.

Either it's right or left

When decoding a type with io-ts the ~~weird~~ new thing we see is, it returns a value of type Either<t.Errors, T> (where T is the type we want to decode to).

import * as t from 'io-ts'

const result: Either<t.Errors, number> = t.number.decode(123)

Either is an algebraic type, in particular a discriminated union with two branches, Right and Left. The first is usually used to denote success and the later to denote failure. In our example t.Errors is the type wrapped by Left and number is wrapped by Right. Either is a sum type (another term for discriminated unions) because it can be either (pun intended) Left or Right, but not both.

The purpose of Either, as you probably guessed, is to work with operations that can fail or succeed. And it provides some nice features to work with it.

`fold`ing 📂

Although one could access the internals of an Either value to get it's contents, that's not how it's intended to work.

To get a value out of it, fp-ts provides fold:

declare function fold<E, A, B>(
  onLeft: (e: E) => B,
  onRight: (a: A) => B,
): (e: Either<E, A>) => B

As the type definition implies, it expects us to handle both cases.

There are some similarities between fold and Array.reduce, which is also a way to transform a wrapped type (Array<A>) into a single value (B).

declare function reduce<A, B>(
  f: (acc: B, current: A) => B,
  initialValue: B,
): (arr: Array<A>) => B

NOTE: I changed the signature of Array.reduce to match the signature of Either's fold.

We are going to use fold mostly as the way to consume an Either. Eg. after decoding an API response with io-ts you'll either dispatch a success action (onRight) or a failure one and report to Honeybadger the error (onLeft).

You'll see that most (if not all) of the algebraic types that fp-ts defines have their own version of fold 🔍

`map`ing 🗺

Once we have fold in our toolbelt we might be tempted to extract values out of Either every time we want to work with them.

What if I told you, you don't have to?

Just like Array.map, there's also map defined for Either.

// Array's map
declare function map<A, B>(f: (a: A) => B): (arr: Array<A>) => Array<B>

// Either's map
declare function map<A, B>(f: (a: A) => B): <E>(e: Either<E, A>) => Either<E, B>

NOTE: I changed the signature of Array.map to match Either's one.

As we can see, it allows us to transform the Right value of an Either by applying a function to its contents. If our value happens to be a Left, it won't be changed. And we can keep working happily with our wrapped value, no folding required.

What about transforming the Left value you ask? mapLeft to the rescue, and this time the unchanged one is the Right.

declare function mapLeft<E, G>(
  f: (e: E) => G,
): <A>(fa: Either<E, A>) => Either<G, A>

Constructing Eithers 👷‍♀

The last thing we need to know about Either is how to construct values.

import {left, right, Either} from 'fp-ts/lib/Either'

declare function left<E = never, A = never>(e: E): Either<E, A>

declare function right<E = never, A = never>(a: A): Either<E, A>

const aRight: Either<never, number> = right(123)

const aLeft: Either<string, never> = left('some error message')

Go Through The Pipes

Although strictly that's all we need from fp-ts to work with io-ts, we are also going to be using a few utilities it provides to work with functions. It's a FP library after all, right?

pipe 🚿

This is one of the ways to do function composition in fp-ts. It let's us pipe a value through a list of functions, where the next function is called with the result of the previous one.

Take this case for example:

export const decodeWith = <A>(decoder: Decoder<unknown, A>) => (
  response: unknown,
) =>
  mapLeft((errors) => ({tag: 'decoding', errors} as const))(
    humanizeErrors(decoder.decode(response)),
  )

We decode a response, humanize the potential errors and then map the left to another type.

With pipe it would look like this:

import { pipe } from 'fp-ts/lib/pipeable';

export const decodeWith = <A>(decoder: Decoder<unknown, A>) => (
  response: unknown,
) =>
  pipe(
    response,
    decoder.decode,
    humanizeErrors,
    mapLeft((errors) => ({tag: 'decoding', errors} as const)),
  )

Now the code reads just like the description:

decode a response, humanize the potential errors and then map the left to another type.

One good thing about pipe is, it's ready for when the pipeline operator proposal lands in JS. Sadly, judging by the pace TC39 works at, that might take years.

-import { pipe } from 'fp-ts/lib/pipeable';
-
 export const decodeWith = <A>(decoder: Decoder<unknown, A>) => (
   response: unknown,
 ) =>
-  pipe(
-    response,
-    decoder.decode,
-    humanizeErrors,
-    mapLeft((errors) => ({tag: 'decoding', errors} as const)),
-  )
+  response
+    |> decoder.decode
+    |> humanizeErrors
+    |> mapLeft(errors => ({ tag: 'decoding', errors } as const))

flow ✉️

flow is right to left function composition. Very similar to pipe, but doesn't take the value as first argument but instead returns a function.

-import { pipe } from 'fp-ts/lib/pipeable';
+import { flow } from 'fp-ts/lib/function';

-export const decodeWith = <A>(decoder: Decoder<unknown, A>) => (
-  response: unknown,
-) =>
-  pipe(
+export const decodeWith = <A>(decoder: Decoder<unknown, A>) =>
+  flow(
-    response,
     decoder.decode,
     humanizeErrors,
     mapLeft((errors) => ({tag: 'decoding', errors} as const)),
   )

That's it but there's more

As far as using io-ts, that's all we need to know about fp-ts (for now at least). If you are already bored, no need to keep on reading.

Although we could use fp-ts (and it's ecosystem) for many other things, this is a great start. By decoding all IO stuff (a.k.a. API responses) we make sure to remove unexpected runtime behavior and errors because we promised the compiler a JSON.parse returns something when in reality it doesn't.

If you see the value on it and want to learn more about (typed) FP check out the Core Concepts and Learning Resources sections in the fp-ts docs. And more importantly make sure to ask questions and look for other people that are in the path of learning about (typed) FP as well.

No M word? 🌯

Somehow I managed to write about FP without using the word monad (well, now I did). That is because there was no need to do so. Even though Either is a monad, we didn't use any of it's monadic properties. We did use it as a Functor. A functor is an algebraic type that has map defined to it, which has to abide some laws to make sure every functor instance is consistent. You wouldn't want Either's map behaving differently than Array's map. Oh and yeah, Array is also a Functor.

Once again, learning these terms (monad, functor, applicative, foldable, et al) is not necessary. But, if you are interested, it can be really useful. For example, if you know that Array has map defined because it's a functor. And then discover a new algebraic type (like Either) that is also a functor you'll already know how to work with the map for that type.

Ok, now that's it.

Happy and safe coding 🤓

Matching your way to consistent states

Christian Gill — Thu, 03 Oct 2019 10:32:19 +0000

In the frontend team at HousingAnywhere, we've been writing our React and Node codebases with TypeScript since the end of 2017. We have React powered applications and a few Node services for server-side rendering and dynamic content routing. As our codebase was growing, and more and more code was reused across different pages and modules, we decided we could benefit from a compiler that would guide us. Since then, we've been migrating one file or module at a time. Most of our new code is written in TypeScript, and most of the codebase has been migrated as well.

Since then, we've been looking for ways to leverage the type system to help us make sure our code is correct.

One of the things we realized is that we aren't writing JavaScript anymore. TypeScript is a different language. Yes, most of the semantics of the language are the same, as is the syntax (excluding the types). This is the goal, after all, to build a superset of JavaScript. But it also has a compiler that can guide and helps us write correct code (or at least attempt to do so), which means we can now model many of our problems using types.

This realization wasn't an “Aha” moment, but more of a series of changes we went through and patterns we adopted that enabled us to benefit more from the type system. I want to share one of those patterns with you in this blog.

Time for Modeling States

When coding, it’s very often the case that we have to handle several variants as part of the control flow of our applications. Sometimes it's the status of a request, the state of a component and what needs to be rendered, or the items that need to be displayed from which a user may choose.

In this article, I’ll explain how you can model the status of a request and decide what outcome you want to show to the user as a result. The patterns discussed here can be applied to any other case where only one boolean isn't enough. I’ll walk you through different ways to approach this — from the more traditional imperative style, to a more declarative one that leverages the type system which makes it safer.

In our status, we have four potential scenarios, which we call LoadingStatus: an initial one, before any request is made. There’s also a loading one, while we are waiting for the request to be fulfilled. And lastly, there are success or error cases.

One approach we can take is to use a combination of boolean properties to distinguish between them. This is a very common approach to modeling such statuses and is often the default approach people use. Our first version of LoadingState looks like this:

interface LoadingState<T> {
  isLoading: boolean;
  isLoaded: boolean;
  error?: string;
  data?: T;
}

As I mentioned before, there are several valid combinations possible.

const notAsked = {
  isLoading: false,
  isLoaded: false,
  error: undefined,
  data: undefined,
};

Before any request is made.

const loading = {
  isLoading: true,
  isLoaded: false,
  error: undefined,
  data: undefined,
};

While the request is pending.

const success = {
  isLoading: false,
  isLoaded: true,
  error: undefined,
  data: someData,
};

A successful resolution 🎉

const failure = {
  isLoading: false,
  isLoaded: true,
  error: "Fetch error",
  data: undefined,
};

A failed resolution 😞

We can use that loading state in a React component to show the status and data to the user.

const MyComponent = ({loadingState}) => {
  if (loadingState.isLoading) {
    return <Spinner />;
  }

  if (loadingState.error) {
    return <Alert type="danger">There was an error</Alert>;
  }

  if (loadingState.isLoaded) {
    return <Content data={loadingState.data} />;
  }

  return <EmptyContent />;
};

This works well for all the valid states. Now, what if our state looks like this? What should be displayed to the user?

const what = {
  isLoading: true,
  isLoaded: true,
  error: "Fetch error",
  data: someData,
};

Something clearly went wrong for us to get into this state. An option could be to accept that "this is how it is: data can be inconsistent" and write tests to prevent our code from getting to this inconsistent state. Another approach would be to assume that an inconsistent state is another kind of error and write code that checks the state for inconsistencies, and show an error to the user when this happens.

But wait a minute. Since our code is now statically typed, is there something that could be done to solve this problem?

I’ll go through a series of improvements showing the potential and more generic ones for you to consider, and end with the version I would actually recommend using. Disclaimer: these patterns are not very common and could require some effort to get your team on board. That said, I believe you’ll find that they’ll be worth the extra effort (in my opinion, it’s not that much extra effort, anyway).

Here we go:

Matching cases: One property to decide them all

For the first, case we’ll start with the most generic pattern. Since all the cases are mutually exclusive (e.g. there shouldn’t be data and an error at the same time), one step in the right direction would be to define all the cases as a union type.

type Status =
  | "not_asked"
  | "loading"
  | "success"
  | "failure";

interface LoadingState<T> {
  status: Status;
  data?: T;
  error?: string;
}

Now that we have one value as the source of truth of our status, we can update our component.

const MyComponent = ({loadingState}) => {
  if (loadingState.status === "not_asked") {
    return <EmptyContent />;
  }

  if (loadingState.status === "loading") {
    return <Spinner />;
  }

  if (loadingState.status === "failure") {
    return (
      <Alert type="danger">
        {loadingState.error || "There was an error"}
      </Alert>
    );
  }

  if (laodingState.status === "success") {
    return loadingState.data ? (
      <Content data={loadingState.data} />
    ) : null;
  }
};

It’s much better already. We (almost) solved the inconsistency problem, as our status is defined by only one value now. Before we get into why I say we almost solved the problem, let’s tidy things up a bit. One of the goals I mentioned at the beginning was to make our code more declarative. However, if statements are by definition imperative. If we take a step back and consider what we’re doing, we’re trying to match each variant in a way so it can handle that specific case. This can be translated into a very short and simple, yet powerful utility function.

type Matcher<Keys extends string, R> = {
  [K in Keys]: (k: K) => R;
};

const match = <Keys extends string, R = void>(
  m: Matcher<Keys, R>,
) => (k: Keys) => m[k](k);

If we remove the types, we’re left with a function that takes an object and returns a function that takes a string, and uses that string to lookup a property of the object and call it with the string. Yeah, it’s even longer in English than it is in code.

const match = (m) => (k) => m[t](k);

match({foo: () => "bar"})("foo"); // => 'bar'

The implementation is simple and doesn’t say much, so let’s take a look at the types. We’re providing the keys of the object as a type parameter. It has to extend the string, meaning it can be an enum or a union type of strings. This guarantees that the object must have all the keys defined, providing an exhaustiveness check (i.e. the compiler gives an error if one of the properties is missing).

Now, we can update our code once more.

const MyComponent = ({loadingState}) => (
  match < Status,
  React.ReactNode >
    {
      not_asked: () => <EmptyContent />,
      loading: () => <Spinner />,
      success: () =>
        loadingState.data ? (
          <Content data={loadingState.data} />
        ) : null,
      failure: () => (
        <Alert type="danger">
          {loadingState.error || "There was an error"}
        </Alert>
      ),
    }(loadingState.status)
);

This makes things more declarative. Much better! The compiler will remind us if we forget to handle one of the cases, which is very convenient.

Besides making our code more declarative by expressing what each case should return instead of explicitly defining how each case should be determined, we’re also making the code easier to update in the future. As we add more cases to your union type, we don't have to search all over the place for code that needs updating. The compiler will simply inform us, and we can be sure that every case is covered.

At HousingAnywhere, we like this pattern a lot and not only use it for React components, but basically everywhere in our code (reducers, thunks, services, etc). Even though it is a simple and short module, we’ve made it available as a package: @housinganywhere/match.

Fine Tuning: One last match

We’ve already made big improvements compared to the initial approach, and it scales very well thanks to the exhaustiveness check.

But as you might have seen in the previous examples, we still have to check the success and failure cases for undefined values. Why do we want to avoid this? Because we still have the chance to end up with inconsistent states that make no sense.

const leWhat = {
  status: "not_asked",
  data: someData,
  error: "Oops this makes no sense!",
};

const queEsEsto = {
  status: "success",
  data: undefined,
  error: undefined,
};

What we really want is for the compiler to guarantee us that we can only have consistent states. As mentioned in the beginning, when we consume the LoadingState, we’re basically matching each of the cases to handle them. We should, somehow, not only match the status but instead the whole shape of our state.

Enter discriminated unions (also known as tagged unions or algebraic data types).

A discriminated union consist of a union of all of the cases, where each case should have a common, singleton type property, the discriminant or tag. By checking that discriminant in our code with type guards, the compiler is able to understand which case we are matching.

Let’s define our LoadingState once more, as a discriminated union this time.

type LoadingState<T> =
  | {status: "not_asked"}
  | {status: "loading"}
  | {status: "success"; data: T}
  | {status: "failure"; error: string};

Now we can implement a version of match that is tailored specifically for this version of LoadingState.

type LoadingStateMatcher<Data, R> = {
  not_asked: () => R;
  loading: () => R;
  success: (data: Data) => R;
  failure: (err: string) => R;
};

const match = <Data, R = void>(
  m: LoadingStateMatcher<Data, R>,
) => (ls: LoadingState<Data>) => {
  if (ls.status === "not_asked") {
    return m.not_asked();
  }

  if (ls.status === "loading") {
    return m.loading();
  }

  if (ls.status === "success") {
    return m.success(ls.data);
  }

  return m.failure(ls.error);
};

Again, we define a matcher object with methods for each of the cases of the status. But this time, each method has a different signature and will be called with the data or error when it should. Checking the discriminant (status property) allows the compiler to understand the case we are in.

The compiler knows data is defined when status is 'success

We will update the usage one more time with the final version of our match utility.

const MyComponent = ({loadingState}) =>
  match<SomeData, React.ReactNode>({
    not_asked: () => <EmptyContent />,
    loading: () => <Spinner />,
    success: (data) => <Content data={data} />,
    failure: (err) => <Alert type="danger">{err}</Alert>,
  })(loadingState.status);

Not only have we made our handling of the status more declarative and concise, but it’s also much safer, as we can’t get into those weird inconsistent states without the compiler ~~screaming~~ gently telling us we did something wrong.

Although these benefits may not seem like a big deal, they are quite significant. The whole point of a type system is not to have yet another source of errors to look at when we make a mistake in our code. Instead, its function is to help us write safer code, by modeling the code in such a way that we can identify that it’s correct at compile time.

Lifting const

Christian Gill — Mon, 23 Sep 2019 23:05:21 +0000

Yesterday I shared this gist:

// Detect dark theme var iframe = document.getElementById('tweet-1175878924926095360-488'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1175878924926095360&theme=dark" }

And I planned to expand on it today based on some assumptions I had.

// Detect dark theme var iframe = document.getElementById('tweet-1176126201234169860-865'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1176126201234169860&theme=dark" }

By playing around in GHCi I found out that my assumption was wrong.

So I did a bit of digging, by digging I mean Hoogling the functions and checking their sources in Hackage, to understand why.

I found some interesting things.

Let's check again how the operator (<*) works.

(<*) :: Applicative f => f a -> f b -> f a

As it is always the case in Haskell, the signature says a lot. It looks like it takes two applicatives and returns the first one.

Just 1 <* Just 2 -- Just 1

And yes, that's right. But there's more...

It does not only return the first one discarting the second. Instead it "runs" both and returns the first one. How do we know it "runs" both? Because the semantic of such applicative (in this case Maybe) are respected:

Nothing <* Just 1  -- Nothing
Just 1  <* Nothing -- Nothing

And that is the difference with const.

Just 1  `const` Just 2  -- Just 1
Just 1  `const` Nothing -- Just 1
Nothing `const` Just 1  -- Nothing

When I said that (<*) is the "lifted" version of const I didn't mean lifted in the Haskell sence, I meant lifted as in the function was used in the context of an applicative. Well I guess that's kind of what lifted means, so let's try again. What I meant is that the signature was "the same" but in the applicative context (same semantics, always returning the first argument and discarting the second).

Turns out, (<*) is actually the "lifted" version of const (in the Haskell sense). Oh, and that's exactly the implementation in base.

class Functor f => Applicative f where
    -- ...

    -- | Sequence actions, discarding the value of the second argument.
    (<*) :: f a -> f b -> f a
    (<*) = liftA2 const

See source in Hackage

So what I was wrong about? 🤔

I assumed that if you lifted const it would still behave as the good ol' const.

constA = liftA2 const

Just 1  `constA` Just 2  -- Just 1
Just 1  `constA` Nothing -- Just 1
Nothing `constA` Just 1  -- Nothing

Well, as we saw already, it doesn't. As I said it respects the semantics of the applicative.

constA = liftA2 const

Just 1  `constA` Just 2  -- Just 1
Just 1  `constA` Nothing -- Nothing
Nothing `constA` Just 1  -- Nothing

Because that is the whole point of liftA2.

* to be continued (whit a deeper look into liftA2).

P.S. Yeah I used a "lifting" 🏋️ picture in a post about lifting. Sorry.

DEV Community: Christian Gill

Recap of the state management history in React

Wild West

Flux

Time travel 🚀

GraphQL as state management?

Hook me up, would ya?

Going Atomic

State is a job for the feds fetching

What’s next?

Generic discriminated union narrowing

Code Reviews Comments Convention

Prefixes

Credits

Composing predicates

Monoids

Applicative

ZuricHac 2020

did

learned

TypeScript Short links

What if ... ?

Yet another link shortener

In the making

Apply me both lists

Lists

Why Applicative?

Functor

Applicative

Conclusion

Progress tracking #100DaysOfFP

Table of Content

01-10

11-20

21-30

31-40

41-50

51-60

61-70

71-80

81-90

91-100 🎉

Enough fp-ts to work with io-ts

what-ts now ?

But why?

Either it's right or left

folding 📂

maping 🗺

Constructing Eithers 👷‍♀

Go Through The Pipes

pipe 🚿

flow ✉️

That's it but there's more

No M word? 🌯

Matching your way to consistent states

Time for Modeling States

Matching cases: One property to decide them all

Fine Tuning: One last match

Further reading

Lifting const

`fold`ing 📂

`map`ing 🗺