leveraging (algebraic data) types to make your UI rock @ jsheroes

As we always want to push the envelope and manage more and more on the front-end, our UI code code grew in complexity in the last few years. All of our modern application deal with three big challenges: optionality (is my data there or not?), fallibility (did my operation succeed?) and asynchronicity (when do I have my data?). Inspired by how typed functional languages treat those, we’ll see how we can leverage TypeScript to deal with them and make a whole category of issues disappear, so that we can focus on the essential parts: making great, accessible interfaces.

Transcript

1. leveraging types to make your UI rock solid algebraic data
2. leveraging types to make your UI rock solid algebraic data
3. Matthias Le Brun @bloodyowl lead front-end manager @ banking API as a service (accounts, payments, cards…) we're hiring!
4. but first, let's talk about quantum physics
5. it's weird™
6. physicists when this kind of stuff was observed
7. PhysicsHeroes
8. «meh» — Erwin Schrödinger (source: Wikipedia)
9. Schrödinger's cat* * artist's impression
10. quantum event → poison → dead dude i swear to god, you put me in that box again and I quit no quantum event → no poison → no dead
11. what does this have to do with UI development?
12. boxes will make sense in a few slides
13. dealing with possible states
17. 3 kind of states in almost every app
18. 1. presence 2. success 3. completion
19. 1. presence 2. success 3. completion
21. «let's add a snarky banner to remind the user to wear their watch and do some workout if they missed any day on the previous week» — the product team
22. type Day = { calories: number; workoutDuration: number; standUpHours: number; }; type LastWeekActivity = Array<Day | undefined>; tracked untracked
23. const getSarcasticMessage = (matchingDay: Day | undefined) => matchingDay === undefined ? "Your watch must look fantastic on its charger" : "This week must've been exhausting";
24. lastWeekActivity .find(item => item === undefined || item.workoutDuration === 0 ); untracked tracked
25. interface Array<T> { find( predicate: (value: T) => boolean ): T | undefined; }
26. interface Array<Day | undefined> { find( predicate: (value: Day | undefined) => boolean ): Day | undefined | undefined; }
27. interface Array<Day | undefined> { find( predicate: (value: Day | undefined) => boolean ): Day | undefined | undefined; }
28. null & undefined replace the value that's not there
29. const index = last30daysActivity.findIndex(item => item == undefined || item.calories < 50 ); if (index == -1) { // not found } else { const item = last30daysActivity[index]; if (item == undefined) { // found day without recorded activity } else { // found day with low activity } } the correct way leaks implementation details
32. type Option<A> = Some<A> | None;
33. type LastWeekActivity = Array<Option<Day >> ;
34. Array.find(lastWeekActivity, (item) => match(item) .with(None, () => true) .with(Some({ workoutDuration: 0 }), () => true) .otherwise(() => false) );
35. const find: <T>( array: T[], func: (item: T) => boolean ) => Option<T>;
36. const find: <Option<Day >> ( array: Option<Day>[], func: (item: Option<Day>) => boolean ) => Option<Option<Day >> ;
37. Option<Option<Day >>
38. option wraps the potential value
39. None Some<None> Some<Some<Day >> found nothing found untracked found tracked
40. Array .find( ... ) .map(getSarcasticMessage); const index = last30daysActivity .findIndex( ... ); const message = index > -1 ? getSarcasticMessage( last30daysActivity[index] ) : undefined;
41. our code represents the domain, not the implementation details
42. 1. presence 2. success 3. completion
43. // BE CAREFUL !!! // The following function can throw function doStuff(input: string) { ... }
44. getGreetingMessage getCurrentUser calls getUserById calls returns returns
45. throws getGreetingMessage getCurrentUser calls getUserById calls getUserById
46. throws getGreetingMessage getCurrentUser calls getUserById calls getUserById
47. exceptions are the worst way of dealing with errors in JS at least
48. you don't know where/if an exception is handled in the call stack
49. throw 1; throw { id: "foo" }; throw fetch("/api"); ¯\_(ツ)_/¯
50. try { something() } catch(err) { // `err` is any } can't type this
51. Promise<T>; promise.catch(err => { // `err` is any }) can't type rejection type where 😢
52. type Result<A, E> = Ok<A> | Error<E>;
53. const f: () => Result<Ok, Error>;
54. const parseInt: (value: string) => Result< number, SyntaxError | IntOverflowError >;
55. match(parsed) .with(Ok(P.select()), (value) => doSomething(value)) .with(Error(P.instanceOf(SyntaxError)), () => showToast("Invalid input") ) .with(Error(P.instanceOf(IntOverflowError)), () => showToast("Number is too big") ) .exhaustive(); handles exhaustivity just a value
56. explicit error handling, at type level
57. 1. presence 2. success 3. completion
59. type State = { isLoading: boolean; error?: Error; data?: Data; };
60. <div> <div> {state.data?.jobs.length ?? 0} jobs in this workflow < / div> {state.isLoading && <Loader /> } </ div> wrong assumption allowed by the data structure
61. isLoading error data FALSE NULL NULL TRUE NULL NULL FALSE ERROR NULL FALSE NULL DATA TRUE TRUE NULL TRUE FALSE DATA FALSE TRUE DATA TRUE TRUE DATA NotAsked Loading Done<Ok> Done<Error> we don't want that legit
62. type State = { isLoading: true | false; error: Error | undefined; data: Data | undefined; }; 2 2 2 ⨉ ⨉ = 8
63. type AsyncData<A> = | NotAsked | Loading | Done<A>;
64. useEffect(() => { setUser(AsyncData.Loading()); const cancel = queryUser({ userId }, user => { setUser(AsyncData.Done(user)); }); return cancel; }, [userId]); start loading receive a result
65. type AsyncData<A> = | NotAsked | Loading | Done<A>; 1 1 1 + + = 3
66. and that's the "algebraic" bit
67. sum & product types
68. possible state count: sum types: A + B + C product types: A * B * C
69. type A = "One" | "Two"; type B = [A, A]; type C = { a: A; b: A }; sum product
70. type State = AsyncData<Result<Ok, Error >> ; types are composable
71. type AsyncData<A> = | NotAsked | Loading | Done<Ok<A >> | Done<Error<E >> ; 1 1 1 + + = 4 + 1
72. initial user error user
73. { isLoading: boolean; data?: User; error?: number; }; AsyncData< Result< Option<User>, number > >; vs
74. <> {user.isLoading || (user.data == null && user.error == null) ? null : user.error != null ? ( "An error occurred" ) : user.data != null ? ( <UserCard user={user.data} /> ) : ( "No result was received" )} </> ; never reached fig. 1: debugging the code 6 months from now
75. initial user error user
76. match(user) .with(NotAsked, Loading, () => null) .with(Done(Error(P.any)), () => "An error occurred") .with(Done(Ok(None)), () => "No result was received") .with(Done(Ok(Some(P.select()))), (user) => <UserCard user={user} /> ) .exhaustive();
77. github.com/bloodyowl/jsheroes2023 want to play with it?
78. how can I have this in TypeScript? (or plain JS with a worse DX?)
79. Boxed → github.com/swan-io/boxed → swan-io.github.io/boxed how convenient!
80. import { AsyncData, Option, Result, } from "@swan-io/boxed";
81. import { AsyncData, Option, Result, } from "@swan-io/boxed";
82. acc as Result< { [K in keyof Results]: Results[K] extends Result<infer T, any> ? T : never; }, { [K in keyof Results]: Results[K] extends Result<any, infer T> ? T : never; }[number] >;
83. const UserCard = ({user}: {user: AsyncData<User>}) => { return user.match({ NotAsked: () => null, Loading: () => `Loading`, Done: (user) => { const name = user.name.getWithDefault("anonymous"); return `Hello ${name}!`; }, }); };
85. $ yarn add @swan-io/boxed
86. avoid avoidable mistakes stets
87. accidental complexity ↘ business complexity ↗
88. Matthias Le Brun @bloodyowl we're still hiring thank you! 🙏