Introducing Simple Remote Data (SRD), a Static Land compliant TypeScript library for managing state from remote sources.
SRD’s top features are:
Only 549 bytes minified and gzipped, that is ridiculously small! Built with Higher Kinded Types (HKT’s) to allow Typescript to infer these complex disjoint union types. Static Land compliant! Made for React or any other JS based frontend framework. What is a Remote Data type? A Remote Data type is a kind of discriminate union type in functional programming for managing the state of some data that is retrieved remotely and asynchronously, such as http response data, websockets, server sent events, reading a file, or any other async IO.
You may have heard of Algebraic Data Types (ADT’s) before but didn’t understand how they can be applied to everyday code - so this article will provide some examples and explanations of why you should start using them.
Before we get into ADT’s, let’s go over the foundation of what ADT’s are made of.
I have been working on a personal project of mine for the last couple of months that has the frontend written in Elm. So far everything is going great and the project is around 10k lines of code.
I have noticed a few reoccurring patterns of mine that I have learned so far and want to share, so here are 5 things I have learned:
- Decoding Empty Lists & Strings When I first started the project, I had a lot of types with fields declared like this:
Pratica is now written completely in Typescript!
What is Pratica? Pratica is a super tiny 720B monadic library, comparable to Crocks or Monet JS.
Often in web development there is this recurring pattern of having to fetch some data from some server through a rest api, and then show it someway in the UI.
This often includes storing this data somewhere on the client side, either in a store or just a variable you can reference, and this is where the Remote Data type can help.
Usually saving the data would look something like this in JS:
I have recently been exploring creating web apps in Elm and found it to be a breath of fresh air compared to the usual React/Redux projects I have worked on in the past.
*Disclaimer: I still think React/Redux is great and viable for large teams if done correctly. This article will just explain my pain points with it while working on large teams at various companies, and why I think Elm can be a better alternative in some cases.