Boxed: bringing algebraic types to TypeScript

Transcript

1. Boxed
2. Matthias Le Brun @bloodyowl lead engineering manager chief shitpost office the easiest way to provide banking features (accounts, payments, cards…) we're hiring! @
7. PREVIOUSLY ON Matthias tries to convert people to FP
8. Algebraic Data Types yay
9. type State = { data?: Data; error?: Error; };
10. type State = { data?: Data; error?: Error; }; type Result<Data> = | Ok<Data> | Error<Error>; error data ERROR NULL NULL DATA NULL NULL ERROR DATA
11. { data: null; error: null; };
12. type Result<Data> = | Ok<Data> | Error<Error>;
13. type State = { data?: Data; error?: Error; }; type Result<Data> = | Ok<Data> | Error<Error>; state ERROR DATA
14. API response API response
15. API response API response
16. type State = { data?: Data; error?: Error; }; type Result<Data> = | Ok<Data> | Error<Error>; 2 2 1 1 4 2 x = + =
17. Algebra it's just basic math™
18. + x
19. quiz 157 x 8341 = ?
20. quiz 999 + 1 = ?
21. union types
22. monads functors
23. functor
24. monad
25. [1, 2, 3].map(x => x * 2) // [2, 4, 6] [1, 2, 3].flatMap(x => [x, x * 2]) // [1, 2, 2, 4, 3, 6]
26. map: <A, B>(T<A>, (a: A) => B) => T<B>: flatMap: <A, B>(T<A>, (a: A) => T<B>) => T<B>;
28. null & undefined are bad
29. errors aren't always exceptions
30. promises were made the wrong way in JS
31. promises were made the wrong way in JS
32. promises were made the wrong way in JS
33. promises were made the wrong way in JS
34. THAT WAS Matthias tries to convert people to FP NOW LET'S TALK ABOUT BOXED
35. ✨ new job ✨ 2022
36. «we use TypeScript»
38. let's look at the ecosystem™
39. fp-ts
40. pipe( token, TaskEither.bindW("user", getTokenFromUser), TaskEither.bindW("project", getProject), TaskEither.chainW(getMembership), ) no autocomplete on current value
41. pipe( token, TaskEither.bindW("user", getTokenFromUser), TaskEither.bindW("project", getProject), TaskEither.chainW(getMembership), x => {} ) need to inspect argument for type
42. pipe( token, TaskEither.bindW("user", getTokenFromUser), TaskEither.bindW("project", getProject), TaskEither.chainW(getMembership), x => {} ) need to inspect argument for type not a good DX
43. export declare const chainFirstTaskK: <A, B>(f: (a: A) = > T.Task<B>) = > <E>(first: TaskEither<E, A>) = > TaskEither<E, A> ah just what I was looking for
44. we've looked at the ecosystem™
45. «let's try to make these types work with a good DX in a structurally typed language» — me, allegedly drunk
46. structural typing
47. class Some<A> {} class None {} const value: Some<string> = new None();
48. what we need → good DX → interop with ts-pattern → fast
49. what we needed → chaining API → autocomplete → less imports
50. 1st iteration: naive wanted the types to be opaque but safe
51. 1st iteration: naive discriminator in TS (aka poor man's nominal types)
52. 1st iteration: naive and we're storing the state in the class instance
54. 1st iteration: naive wanted the types to be opaque but safe
55. 1st iteration: naive wanted the types to be opaque but safe
56. 2nd iteration: anger
57. 2nd iteration: anger
58. 2nd iteration: anger
59. 2nd iteration: anger
60. 3rd iteration: make it fast
61. initial release
62. initial release
63. type Option<A> = Some<A> | None;
64. type Result<A, E> = Ok<A> | Error<E>;
65. type AsyncData<A> = | NotAsked | Loading | Done<A>;
66. Future<A>; better promises™ cancellable monadic leaves error state to Result
67. const parsed = input != null ? parseInput(input) : undefined; const transformed = parsed != null ? transform(parsed) : undefined; const printed = transformed != null ? print(transformed) : undefined; const value = printed != null ? prettify(printed) : "fallback"; input .map(parseInput) .flatMap(transform) .map(print) .map(prettify) .getWithDefault("fallback");
68. user-testing
70. insights people need human-written docs → we doubled down on examples & added search
71. insights don't try to replicate another language → give good defaults for TS
72. Result< Data, ServerError > Result< A, ServerError | FinalizeError >
73. insights people are familiar with just a few data types → reduce confusion
74. insights people can be docs-first or type-first → experience needs to be good for both
75. insights readability matters → chaining API was the way to go
76. insights mapping on existing JS knowledge helps → if it exists, name it the same way
77. insights pipe() syntax had impact on the runtime → expressiveness is important
78. 4th iteration implement the feedback rename some methods update some defaults
79. 5th iteration: what the actual fu
80. 5th iteration: what the actual fu
81. recently fix the errors
82. recently improved perf by 2x to 10x
83. recently improved perf by 2x to 10x blazing fast certi fi ed™ ⚡
84. Boxed → github.com/swan-io/boxed → swan-io.github.io/boxed
86. $ yarn add @swan-io/boxed
87. Matthias Le Brun @bloodyowl we're still hiring thank you! 🙏