Jason's Blog

2025 Year in Review

Wed, 31 Dec 2025 09:35:00 +0000

This is the 4th edition of my annual review post!

Overall, 2025 was a great year. The first half of the year I was still working on making game development easier for indie developers at Void - Unfortunately Void shut down at the end of May due to funding, but it was one of my favourite jobs I ever had, and I will miss the exciting work we were doing on creating our game engine, editor, and SDKs.

My role at Void was specifically around SDK’s and designing the TypeScript SDK for interacting with our new Rust ECS game engine - it involved a lot of work around the TypeScript Compiler API to achieve an SDK that was enjoyable to use. Most of the work I was doing is now open source and available on Github here. I also created many prototypes with Rust interop in our SDK’s with other languages such as a Python SDK that leveraged Cython to compile Python directly to C, a C# SDK that compiled natively using AOT, and a pure C SDK.

Along with creating SDK’s, I also worked on some unique projects at Void, such as integrating the Deno JS runtime into our Rust game engine so that our engine can execute and communicate with the game developer’s code - this was challenging but I learned a lot about the inner workings of the V8 engine.

After Void, I took some time off while searching for my next role. A few interviews later and I landed at Zapier in the AI Orchestration zone working on Agents 🎉. AI is clearly changing the way the world works, so I’m excited to contribute to making AI Agents better and more useful for everyone.

Aside from work-related topics, I’m happy that during my time off this year I got to play a lot of golf and even broke 100 for the first time. I look forward to golfing more next summer!

For 2026, I’m looking forward to improving AI Agents at Zapier by helping make them more deterministic and more reliable. I want to continue playing golf, padel, magic the gathering, and hopefully reach 50 donations of plasma at HemaQuebec.

Cheers 🥂

2024 Year in Review

Tue, 31 Dec 2024 17:43:46 +0000

This is my 3rd annual yearly review post!

2024 was a somewhat uneventful year - not much to highlight, but also nothing to complain about either.

In 2023, one of my goals was to finally give a talk at a tech conference, and I managed to do it! I gave a talk at Future Frontend in Finland about some of my observations concerning frontend, and how it can be improved. The talk went great and I’m super happy with the result!

My other big goal from last year was to move the needle in the game development space. That goal is still a work-in-progress but making great strides at the company I’ve been working at since last January - Void. Hopefully in 2025 we will unveil all the hard work we’ve been putting into making game dev a more enjoyable experience.

For 2025, my goals stay pretty much the same, with the addition of strengthening my online security and privacy. I already have a very strong online security practice (details in my november post - project encrypt) - but I want to go even further by setting up redundancy and exploring more ways to stay secure online and offline.

Project Encrypt

Wed, 27 Nov 2024 00:00:00 +0000

Project encrypt is an ongoing personal hobby of mine to fully encrypt every activity I do online. This post will cover almost everything I do to secure my privacy and data online.

I will go over everything in detail but the summary is that this project includes:

Passkeys for passwordless login and 2FA.
Email aliases for every account.
Encrypting email, storage, calendar, passwords & more.
Generating credit card number cvv’s for every purchase.
Secure messaging & contact key verification.
App permissions
Emergency sheets & backups.

If you follow this project, or any individual steps, your online data will definitely be safer and more secure than before.

Passkeys, Security Keys & 2FA/MFA

If you’re not aware of what passkeys are yet, then let this be the one important takeaway from this article.

Passkeys are a way to log in to your accounts without having to remember a password, and sometimes in the case of passwordless then you don’t even need to remember your username. The passkey is generated and stored securely on your device or inside your password manager and can’t be accessed easily without device access.

Passkeys are not only more secure but also more convenient than passwords because they can be accessed via biometrics (FaceID/TouchID) or a master password.

To start using them, navigate to the security settings for any product you use and check if they support them. This is what the Google security settings look like for passkey registration:

When registering a passkey, you can choose where to save it, either in a password manager or using a physical security key like a Yubi key.

For some more information on passkeys and security keys, here are some recommended links:

One other great advantage of passkeys is that they can be used for two-factor authentication (2FA), so not needing to copy/paste codes from an authenticator app or email/text message is a huge convenience with no security downside.

Not every product or service supports 2FA or passkeys, and the ones that do will support it to varying degrees. For example, some sites may have 2FA but only for text message codes and email codes (looking at you Banks and Government services…), which is less secure than things like an Authenticator app or passkeys.

Whenever creating a new account for any product or service, I always enable 2FA and register multiple devices. My preferences are (in order):

Passkeys with physical security keys - (Yubi Key / Titan Key)
Passkeys saved in a password manager
Authenticator App
Email
Text Message / Phone Call

I usually register two security keys and one passkey in my password manager. Prefer to use passkeys if supported, if you’re in the Apple ecosystem then their built-in password manager has support for them already. Ditto for Android. If passkeys are still confusing, then opt to use an authenticator app (How authenticator apps work) like Ente for 2FA codes. The app shows codes rotating over time, and you must copy/paste them into the app during login.

Text message 2FA is by far the weakest form of 2FA, below is a good video about how easy it is for bad actors to intercept phone calls and text messages without you knowing it.

Email Aliases

The idea of email aliases is to have a different email address for every online account.

This means having one email for something like Twitter and a different email for Instagram. There are many advantages to doing this, one benefit is spam management - if you start receiving spam to one email then you can just deactivate it.

It also allows you to centralize the forwarding process, so if one day you are forwarding all emails to a master address like name@domain.com and you would like to switch all your 150 accounts to a different address, then it’s as easy as switching in one place instead of inside all 150 accounts.

Apple supports aliases with their “Hide my email” feature in iCloud to generate email addresses easily or with “Sign in with Apple”.

I used Apple’s for a while and now use SimpleLogin for aliases.

Another benefit of aliases is that it keeps your master email unknown to anybody. This allows you to easily control who has access to contacting you. Nobody will know your real email, only your aliases, and you can easily deactivate an alias if someone uses it without permission.

Secure aliases like Apple’s or Proton’s are different than ones that services like Gmail provide with the + trick. The + trick does not hide your original email, and anyone who knows that will have access to messaging you directly to your original email.

Encrypted email, storage, calendar & passwords.

This section is dedicated to Proton - proton is a product suite that provides encryption for various tools and has replacements for things like email, storage (like Google Drive), calendars, VPN’s, wallets, and passwords, but all private and end-to-end encrypted (E2EE).

I have all my email aliases forwarded into my Proton mail account, I use Proton Storage for storing encrypted files, Proton Calendar for my calendar needs, and Proton Pass for my password manager which includes authenticator codes, passkeys, and email aliases. This suite replaces my need for similar Google products that are not encrypted.

If you’re interested in trying out Proton, I highly recommend it, and I have a referral code: https://pr.tn/ref/MQ4N9PEJTH10

If you would like to send me an E2EE email, please check out my contact page for my public PGP encryption key.

Credit Cards

As often as possible I will use Apple Pay to pay with my credit card as Apple automatically generates new CVV’s with every purchase, masking your real CVV - this prevents vendors from stealing your full credit card information, as the generated number is only valid for that one time purchase.

Also, I use Wise to generate virtual prepaid credit cards when I really don’t trust the company I’m purchasing from. This protects my real CC number and if the prepaid card number is stolen then there will be no funds on it besides what I originally needed it for.

Messaging & Contact Key Verification

Messaging with friends and family is usually done via iMessage, and sometimes with Signal when my contacts have it installed. Signal is a true end-to-end encrypted chat - it has no ads, no tracking and doesn’t gather metadata like other encrypted chats such as WhatsApp.

Preferably I would use Signal all the time, but not everyone understands the benefits yet - it is up to us to spread the word about Signal to friends who have not heard about it yet.

For iMessage I have enabled and set up Contact Key Verification with a few contacts to verify devices, this provides some extra security around account takeovers and you will be warned if a message is coming from an unverified device. But, it is a slow and manual process to verify each individual contact, and trying to explain to everyone the benefits of contact key verification is really difficult.

Details about Contact Key Verification from Apple Security Engineering

This is my public verification code:

APKTIDxRWrX5TLPlHGKpt7vDntZ832yLS0hNee8bVc3Fk0MDWjnw

iMessage is not perfect, but it seems to be the lesser of evils compared to services like WhatsApp, FB Messenger or Telegram which claim to be E2EE but are tracking a lot of extra metadata about you.

App Permissions

On the iPhone’s AppStore, there is a little known section at the bottom of every app that lists all the data the app has access to and links to you. I always try to avoid apps that grant themselves access to too much information.

Check out this comparison between what TikTok has access to, vs the Standard Notes app.

Emergency Sheet & Backups

When using password managers, email aliases, and authenticator codes, it is important to have a solid strategy for doing periodic backups of this data because if you lose access to it one day, it will cause endless problems.

I have two methods of backups, and both are encrypted in different ways.

My primary backup method is using my personal server and database that I have hosted in an undisclosed data center. I have created a personal app that takes any data I want and encrypts it using a provided encryption key. The encrypted data is stored in my database and no encryption keys are stored with the server or database. This ensures that even if there’s a data breach, all the data would be encrypted without possibility to decrypt.

The second method is using Google Drive to store encrypted backups from Proton Pass. I store the encryption keys on my emergency sheet.

Finally, I created an emergency sheet. This is a physical paper sheet I keep in my house with master passwords, encryption keys, and recovery codes in case I lose access to anything very important. This is a worst-case scenario sheet, but it’s always good to have just in case.

Miscellaneous

There are a lot of other small things I do that don’t warrant their own section so I’ll just list them here quickly:

Turn on Advanced Data Protection for iCloud storage, which encrypts iCloud data, which is off by default. (Everybody should do this one, it’s easy and important)
Turn off location services on iPhone.
Reject any prompts for Data Tracking on apps.
Use VPN’s as often as possible to mask IP addresses.
Avoid products and services from Google and large tech companies.
Avoid using or downloading apps such as TikTok, Facebook, Instagram or Twitter.
Use DuckDuckGo instead of Google Search.
Avoid any “always listening” smart-home products like Google Home, Amazon Alexa, or Siri.
Use Firefox instead of Chrome.
Use Standard Notes for note taking.

I’m continuously improving my online security strategy so I may update this article periodically to add or remove items. I hope this article has exposed you to something new and I hope it encourages you to start improving your online security as well.

JS Proxies for array indices getters & setters

Wed, 18 Sep 2024 00:00:00 +0000

This post will cover a technique for implementing getters and setters for every item in an array, using Proxies.

A common issue with getters and setters is that they are not recursive for nested objects or arrays. This can cause confusion when accessing an object via a getter and attempting to mutate a field on the returned object and not seeing the changes take effect.

Here is an example of the issue. If we have a class that stores its data in an ArrayBuffer instead of just plain variables, then the issue becomes easier to understand.

This example just stores an RGBa color in the buffer as 4 u8’s.

class Foo {
 view = new DataView(new ArrayBuffer(4))

 get color() {
 return [
 this.view.getUint8(0), // red
 this.view.getUint8(1), // green
 this.view.getUint8(2), // blue
 this.view.getUint8(3), // alpha
 ]
 }

 set color(value) {
 this.view.setUint8(0, value[0])
 this.view.setUint8(1, value[1])
 this.view.setUint8(2, value[2])
 this.view.setUint8(3, value[3])
 }
}

Accessing and setting the entire color will always work as expected:

const foo = new Foo()

foo.color = [1, 6, 8, 4]

console.log(foo.color) // [1, 6, 8, 4] - it works!

So we see that assigning and getting the entire array works as expected, the issue comes when trying to access and then mutate individual items in the array:

const foo = new Foo()

foo.color = [1, 6, 8, 4]

foo.color[0] = 100

console.log(foo.color) // [1, 6, 8, 4] - Wrong! not updated correctly

We see above that when logging the color again we don’t see the first element in the array being 100 which is unexpected - it should’ve been mutated.

Why does this happen?

When attempting to set an indexed item in an array returned from a getter like this foo.color[0] = 100 what is happening is that foo.color calls the getter which returns a new array with the correct values, [1, 6, 8, 4], and mutating that array works, so it becomes [100, 6, 8, 4], but the changes do not get propagated to the underlying array buffer because the array indices are not connected via getters or setters!

So when logging out the underlying data again using the getter, we still only see the old data in the buffer…

How do we fix this?

For nested objects, in most cases, we can use nested getters and setters to allow the mutations on a per-field basis. But for arrays, it is more difficult to define getters and setters on a per-index basis, and using tools like Object.defineProperty(...) can get messy and hard to extend to Typescript.

So how do we solve this for arrays returned from getters?

In comes Proxy! Proxies are a way to intercept actions performed on objects or arrays - they can see when something tries to get or set a field and change either the return value, or how the data is set completely.

To fix our example, we can modify the color getter to return a Proxied array instead of a normal array, so we intercept mutations on individual items and set them accordingly.

class Foo {
 view = new DataView(new ArrayBuffer(4))

 get color() {
 const self = this

 return new Proxy([
 this.view.getUint8(0),
 this.view.getUint8(1),
 this.view.getUint8(2),
 this.view.getUint8(3)
 ], {
 set(_, prop, value) {
 self.view.setUint8(parseInt(prop), value)
 return true
 }
 })
 }

 set color(value) {
 this.view.setUint8(0, value[0])
 this.view.setUint8(1, value[1])
 this.view.setUint8(2, value[2])
 this.view.setUint8(3, value[3])
 }
}

Now let’s try mutating individual items again.

const foo = new Foo()

foo.color = [1, 6, 8, 4]

foo.color[0] = 100

console.log(foo.color) // [100, 6, 8, 4] - it works!!

Now consumers of this API can safely mutate the data received from the getters with no issues.

Drawbacks

One drawback to returning a Proxied object from a getter is when logging the entire object to the console, the type of the object is wrapped in the Proxy instance.

So a normal console log of an unproxied array would be printed like this:

console.log(foo.color)
// [1, 6, 8, 4]

but if it’s proxied it would print like:

console.log(foo.color)
// firefox
// { <target>: [1, 6, 8, 4], <handler>: {...} }

// chrome
// { [[Target]]: [1, 6, 8, 4], [[Handler]]: {...}, [[IsRevoked]]: false }

This may confuse users, but it will behave exactly like a normal array.

I hope this post was helpful in understanding how to allow mutations on an array returned from a getter. Go forth and Proxy!

Reliable I/O with the TypeScript Compiler API (Video)

Mon, 01 Jul 2024 13:04:43 +0000

On June 13th, 2024, I gave a talk about code generation at the Future Frontend conference in Helsinki, Finland. The title of the talk was “Reliable I/O with the TypeScript Compiler API” where I spoke about the brief history of I/O in frontend applications and how we can make I/O more reliable in the future.

2023 Year in Review

Mon, 18 Dec 2023 15:11:43 +0000

This is the 2nd annual yearly-review post that I have written. Last year was the first and can be viewed here, and a list of all reviews can be found here.

Last year’s post was split into 4 sections, professional review and goals and personal review and goals - this year everything will just be split into 2 sections, review of the year and goals for next year.

Review

Some of my notable events this year were:

Wrote a Book

Something that wasn’t planned from last year, but I successfully wrote and self-published my own ebook about The Typescript Compiler API. This was a topic I found very interesting and had a vast amount of experience and knowledge around, so it made sense to write about it and obtain some passive income from the sales.

Quit My Job

I left my job at Unity in June. I worked there for just over 3 years and I wanted to take some extended time off to learn about new topics and build my own multiplayer games. It was a difficult decision at the time, but in hindsight, it was a great decision.

Created 2 Indie Games

During my 6 months off, I learned a lot about 3D modeling in Blender and I successfully created 2 multiplayer games in the Godot engine that I always wanted to build.

The first was a multiplayer 2v2 3rd-person shooter named Neon Blitz (not publicly released). The objective of the game was for teams to plant bombs around a map and have the other team attempt to defuse the bomb or kill all the members of the opposing team. The game was heavily based on the rules of “Search & Destroy” from Call of Duty. All assets were created by me from scratch in Blender.

Fun time play-testing tonight with @EhLouisEh @VeeMerk @Cryo_Pun. Found some more bugs and got great feedback for things to improve #GodotEngine #IndieGameDev pic.twitter.com/sI6NmTLyYl
— Jason (@Rametta) August 11, 2023

The second game was a multiplayer card game named Pali, similar to something like Pokemon or Magic the Gathering. The objective of the card game was to build the best 5 card hand possible using the same deck as your opponent sitting at the table. The game rules were inspired by the Star Trek card game. I open-sourced the entire codebase for the game here so it can be used as a reference for anyone else who wants to build similar games. Some assets were created by me, and some were premade or generated.

Been working on a small 3D card game idea. Added in multiplayer this week. #GodotEngine #IndieGameDev
Room assets by @KayLousberg pic.twitter.com/t8iY3fWgAz
— Jason (@Rametta) November 27, 2023

10-Day Meditation Retreat

In early March, I accomplished one of my previous years goals which was to attend a 10-day meditation retreat. This one was in Montebello, Quebec, and taught by S.N Goenka. It was a lot of work - long days starting at 4 am with around 10 hours of meditation per day, with no talking or contact with anyone. Overall though, it was a great experience, and look forward to attending again in the future.

Conference Talk Planned

Another goal from last year was to give a conference talk this year. I didn’t get a chance to achieve that yet but I do have it planned for next year as I will be speaking at Future Frontend 2024 in 🇫🇮 Helsinki!

Goals

Last year, I had a lot of smaller-sized goals for the year, this year I only have 1 real big goal for 2024 and that is to move the needle on game development.

Game development needs a change and I have big plans, but I can’t share any details yet. Hopefully, by next year’s review, I will have some great announcements related to game development!

WebAuthN in Remix - FaceID, YubiKey, and more!

Wed, 06 Dec 2023 00:00:00 +0000

This article covers how to add “passwordless” authentication to any Remix application using WebAuthN. This allows users to authenticate using their iPhones FaceID, TouchID, a physical security key like a YubiKey, or a virtual Passkey that can be stored in password managers like LastPass/Bitwarden/OnePassword etc..

“Passkeys are like passwords but better. They’re better because they aren’t created insecurely by humans and because they use public key cryptography to create much more secure experiences.”

- https://passkey.org

Why integrate with WebAuthN? (ELI5)

WebAuthN is a more secure and usually a better UX for users to authenticate with your application. Instead of typing a password, or opening a password manager and finding your login credentials, one can just use their phone’s native bio authentication mechanisms like FaceID or fingerprints to authenticate.

This involves creating a pair of private and public keys and storing the private keys on a local device, and sharing the public keys with a server’s database. This process is facilitated by WebAuthN standards.

“Although there are many ways to do MFA, security keys are a highly secure and convenient option. Login codes sent via text message can be intercepted, and authentication apps require that your phone be charged and available.”

- https://www.yubico.com

Even if the database’s data is compromised and data is leaked, it will not matter because the public key does not have any important information - it is only useful when paired with the private key.

Adding this feature to your application allows extra security by enforcing it after a normal login for an MFA flow, or just to replace the password altogether. It can also be considered a faster MFA implementation because it does not require waiting for a text message or email with a code to copy/paste, or an Authenticator app to copy/paste 6-digit codes from.

How to integrate WebAuthN into Remix

The process involves two steps. First step is to have users register some credentials, the second step is to use the credentials when the user tries to login in the future and verify their identity.

This process can be achieved completely “natively” by using the Browsers navigator.credentials API for creating a getting keys on the client side, but it can be more tedious overall since it is more low level.

So this article will use the great library SimpleWebAuthN from Matthew Miller, which provides packages for the server side, client side, and typescript types, that make everything easier.

Registering Credentials

For both registration and authentication of credentials, the flow is similar. For registration it goes like this:

The client indicates to the server that it wants to register some new credentials.
The server generates some options that it will pass back to the client, which includes a secret challenge. This is done in the library with webauthn.generateRegistrationOptions(...). The secret challenge is stored in a readonly http session cookie.
The client takes the options and passes it to the WebAuthN facilitator, such as SimpleWebAuthN library to do webauthn.startRegistration(options) - the client will be prompted by the browser or native OS to choose a format, such as FaceID or passkey.
The client then takes the result of the registration and passes it back to the server.
The server validates and verifies the results with something like webauthn.verifyRegistrationResponse(results) which includes the secret challenge from the session.
If the verification passes, the publicKey is stored in the database, along with the corresponding credentialID, the transports and a counter. The transports just indicate the type of device that was used, such as a USB key or other means, and the counter is used to ensure the same device is not used too many times. This data will be fetched and used when the user tries to login later.

Side note: When generating the options on the server - the server can include already existing keys for that user in the options response to prevent the client from trying to register the same credential twice.

Overall, there are a few back-and-forth requests between server and client, and in Remix this can be handled in a few different ways, either using native Forms or by using Remix’s useFetcher hooks, or just with normal http ajax requests like Fetch, Axios or the O.G XMLHTTPRequest.

Session cookies are stored using Remix’s createCookieSessionStorage().

Authenticating

After the credentials are created and stored on the user’s device and the public key is stored in the app’s database, we can now use them to authenticate the user.

The flow is as follows (for passwordless):

The user indicates to the server that they would like to login.
The server generates some options that it will pass back to the client, which includes a secret challenge. This is done in the library with webauthn.generateAuthenticationOptions(...). The secret challenge is stored in a readonly http session cookie.
The client takes the options and passes them to webauthn.startAuthentication(options) - the client will be prompted by the browser or native OS to choose a format, such as FaceID or passkey.
The client then takes the result of the registration and passes it back to the server.
The server validates and verifies the results with webauthn.verifyAuthenticationResponse(results) which includes the secret challenge from the session.
If the verification passes, the user is considered valid and another session cookie is set, such as isLoggedIn and is set to true, with an expiry date for however long you want the user to be authenticated without having to re-authenticate. The server can redirect the user to an authenticated page with the new session cookie so they can use the app freely, and authenticated.

Recovery

Overall WebAuthN is a great solution for stellar UX and strong security in applications - but a drawback can be if the user loses their security device, or loses their phone which holds their private keys. This would mean they lose access to any application that requires their private key for authentication on the client side.

That’s why it is important to also provide a recovery mechanism for lost devices. Most applications provide a series of “codes” that the user should store somewhere else, in case they lose access to their primary device, they can add a new device using the recovery codes.

Conclusion

That’s it! It is pretty simple to integrate WebAuthN into Remix applications, and it provides great UX and great security for users.

For further information about WebAuthN, check out their official site webauthn.io!

Follow me on twitter (@Rametta) to hear about new articles.

Godot Data Validation with Zodot

Tue, 17 Oct 2023 00:00:00 +0000

Zodot is a new data validation library for Godot, with an API that was inspired by the popular Typescript/Javascript npm package Zod.

Data validation is an important concept in many programming environments, including Godot. It is the process of taking unknown data and confirming that it matches the shape that is expected. If the data does not match the expected shape, then gracefully handle the error.

Features

Some of Zodot’s convenient features include:

Typed dictionaries in GDScript
Typed Unions
Support for nullables
Automatic data coercing with str_to_var()

More details on these features below.

When to use Zodot

Oftentimes in game development, or any development - developers will store or retrieve data externally from their codebase, either from a database, an API rest endpoint, a file, or just an external package. Such data can be things like a player’s inventory system, their statistics, lobby information, friends lists, or more.

No matter how you retrieve some external data, the important step is to validate that the data you received matches the shape that you are expecting, otherwise you may start accessing the data when assuming its shape, but results in a runtime crash when the data has changed unexpectedly.

How to use Zodot

Using Zodot is super easy. The first thing to do is define a schema, and then use the schema to parse the data that you want to validate.

Example of defining a player schema with 3 fields:

var PlayerSchema = Z.schema({
 "user_id": Z.string(),
 "avatar_color": Z.color(),
 "position": Z.vector3()
})

This schema defined an object with 3 typed fields. Now we can take some data and pass it to the schema to be validated against:

func parse_player(data: Variant):
 var result = PlayerSchema.parse(data)

 if not result.ok():
 print("The data does not match the expected shape")
 print(result.error)
 return

 # Do things with the valid data now
 print(result.data)

In the above example, we see the data comes in as a Variant type, which just means it could be anything, then we pass that to our schema. If our result from the parse is not ok, then we have access to a detailed error message as result.error. If it does match the schema, then we have access to the typed data in result.data.

Data Coercing

One of the best features of Zodot is its ability to corece data before validating. This is popular when complex data is stored as strings and then needs to be deserialized back into its real type after retrieval. Let’s look at an example:

var schema = Z.schema({
 "color": Z.color().coerce(),
 "position": Z.vector2().coerce()
})

We use the .coerce() extension for each field we want to deserialize because we are expecting to receive that field as a string that was previously serialized using Godot’s var_to_str method.

Now if we have serialized data such as:

# notice the values are wrapped in strings
var data = {
 "color": "Color(1,2,3,.5)",
 "position": "Vector3(4,2,5)"
}

We can parse it and receive the actual types after successful validation:

var result = schema.parse(data)
print(result.data.color) # Color(1,2,3,.5) - real type, not wrapped in strings

Typed Dictionaries

Zodot provides some powerful features that are not even available in GDScript, such as typed dictionaries. Take a look at a dictionary example:

var schema = Z.schema({
 "other_field": Z.float(),
 "my_dict": Z.dictionary(Z.color())
})

Since GDScript can’t define the type for the dictionary values, we can use Zodot’s dictionary validator to ensure that all the values in the dictionary are of a certain type - like this example, all values in the dictionary must be a Color type.

Typed Unions

Another powerful validator from Zodot is called z.union() which is another feature that GDScript does not provide. This validator allows fields to be more than one type.

Z.schema({
 "user_id": Z.union([Z.string(), Z.integer()])
})

In this example, the user_id is defined to accept a string or even an integer as a valid type! This is similar to other languages like Typescript which would be defined as: type UserId = string | number

Nullables

One last feature of Zodot is its ability to allow any field to be null just by adding .nullable() to the end of the field validator.

var nullable_color_field = z.color().nullable()

This makes it much more clear than the basic GDScript type definitions since GDScript has no real way of defining that relationship.

Try it out

Zodot is available on the Godot Asset Store here, and it can also just be downloaded directly from Github here.

Follow me on Twitter to hear more about interesting Godot projects!

My New Book! The Typescript Compiler API

Fri, 02 Jun 2023 00:00:00 +0000

I am proud to announce that my new book about The Typescript Compiler API is now available at https://typescriptcompilerapi.com!

This book is a culmination of years of work as a software engineer working on metaprogramming - the art of generating code, reading code automatically, and extending language feature sets. Typescript is quickly taking over the world as the most popular compile-to-javascript language and this book will explain the magic behind metaprogramming with Typescript. If you’re a software developer, I guarantee you will learn something new and useful by reading this book, and apply it to your own work to automate tasks, even if not using Typescript.

Cheers! 🍻

2022 Year in Review

Sat, 31 Dec 2022 15:11:43 +0000

This is the first time that I do this type of year-end review post, and I hope to continue this tradition for some time.

I would like to summarize the things that I am proud of achieving throughout the year. This is for three reasons:

I would like to look back and celebrate everything I have done over the year.
I would like to review this post next year and see if I achieved my goals that I specified.
As I continue this tradition in the future I may forget when and what I have learned over the years and I can come back and track my wins over the years by revisiting these posts.

I will split the review into two sections: Personal review and goals, and Professional review and goals.

Personal

This personal section are things that I have learned and started doing in 2022 that are non-work related, and that I am proud of discovering and trying, and plan to continue doing in the new year.

Personal 2022 Review

Cold Showers

I started taking cold showers. I found them to be helpful for me in reducing inflammation in my sinuses, making me feel better in the mornings, and improving my sleep and metabolism. Sometimes I’ll just end a hot shower with a few minutes of cold water, and sometimes I’ll start the cold from the beginning.

Hot Yoga

Hot Yoga has been an amazing discovery for me, initially it was an idea for staying active during the winter months when I can’t play tennis outdoors, but it evolved into being one of my favourite activities and I try to go two or three times per week. I find it helps with my flexibility, cardiovascular health, mood and general well-being.

Wim Hof Breathing

If you don’t know Wim Hof, check him out, he is an incredible person that advocates cold water therapy and has a special breathing technique for improving the immune system. I found his breathing method to help improve my sinus health and it puts me in a calm mood.

Meditation

I discovered Sam Harris’s meditation app called Waking Up and have really enjoyed learning about meditation and mindfulness, along with practising the techniques that he discusses in his lessons. Although I find it very difficult, I have begun to see and understand the benefits of being more mindful.

Fasting

I started both intermittent fasting and prolonged fasting this year. Near the end of the year in December I finished my first 3 day water fast and loved it even more than intermittent fasting. There are just so many health benefits to fasting such as Autophagy, improved insulin sensitivity, and decreases in inflammation.

Biology

I have been learning a lot about biology because my interest keeps growing in this field. Topics such as the nervous system, the endocrine system and the cardiovascular system were all at the top of my personal studies throughout the year. I learned a lot but only touched the tip of the iceberg.

Sauna

After a trip to Finland in September to attend a conference for work, I rediscovered saunas and their benefits, especially when paired with cold water therapy. Cardiovascular health improvements are just a small slice of benefits that come from saunas.

Walking & Podcasts

I often went on walks before 2022, but in 2022 I increased that and went at least once per day, sometimes twice, and found that podcasts are a great way to learn new things while walking. Some of my favourite podcasts I found this year:

Huberman Lab (Dr. Andrew Huberman)
The Peter Attia Drive (Dr. Peter Attia)
FoundMyFitness (Dr. Ronda Patrick)
Lifespan - (Dr. David Sinclair)
Lex Friedman Podcast
All In Podcast
Making Sense - Sam Harris
The Tim Ferriss Show
The Ben Shapiro Show
Wellness Unpacked - Ella Mills
Ear Biscuits - Rhett & Link

Mycology

A new hobby of mycology has emerged for me, learning about different species of mushrooms, how mycelium works, growing my own mushrooms and learning how to clone and grow mushrooms from scratch in petri dishes. This hobby has also led me to eat more medicinal mushrooms such as Lion’s Mane, Reishi and Turkey Tail, and encouraged me to go for more walks in forests to try and identify wild mushrooms.

Adaptogens

Related to medicinal mushrooms, I started learning more about the benefits of vitamins and other supplements such as adaptogens, mushroom supplements and the importance of Omega-3 fatty acids, Vitamin D and the Vitamin B’s.

Carbohydrates

I always knew about carbs but this year I did a deep dive on how they work and how they affect blood glucose, ketone production, metabolism, and how they can also affect mental disorders. The more I learn about carbs, the more I want to reduce my consumption of them.

Buddhism

I am not a Buddhist but I have been learning about their ideologies and disciplines, especially in regards to meditation and mindfulness. I read some books about Buddhism and plan to continue this research as I find it interesting.

Drinking

Alcohol has always been known to me to be bad for both physical and mental health. I have not eliminated it completely from my life but drastically reduced my consumption and have noticed great benefits already, especially in regards to weight loss, mood improvements, sleep improvements and general health improvements.

Books

I’ve read a handful of books this year, some better than others, but my two favourite books of the year are:

The China Study - Dr. T. Colin Campbell
Brain Energy - Dr. Chris M. Palmer (Reading in progress but very good so far)

Personal 2023 Goals

Retreat

I would like to attend a 7-10 day vipassana meditation retreat to gain a better understanding of meditation and mindfulness.

Fasting

I would like to do a 3 to 5 day fast every few months. At least 3 times in the new year.

Mushroom Identification Certificate

I would like to continue to study more mycology and take some exams for obtaining a mushroom identification certificate for indentifying wild mushrooms.

Monitor Ketones and Blood Glucose

To better understand how my body reacts to different foods and exercises, I would like to obtain a Continuous Glucose Monitor (CGM) to be able to always track my blood glucose levels. Even though I am not a diabetic I still find these tools insightful. I would also like a ketone monitor to be able to measure the amount of ketones that are being produced in my system, which will give me a better understanding on where the source of my energy is originating (food or personal fat reserves).

Politics

I have always considered myself left-of-center leaning, if not completely left, but as I learn new things about conservative and liberal policies I realize that I know very little and I would like to learn more from both sides to better be able to understand our political climate and be more informed.

Philosophy

I would like to learn more about different philosophical topics such as stoicism, hedonism and epicureanism.

Read at least 25 books

I would like to read at least 25 books and have a breakdown by subject that will help achieve my other goals, so I would like to read at least:

2 books about politics, 1 for conservatism, 1 for liberalism, and maybe an extra about libertarianism.
2 books about Buddhism or mindfulness.
3 books about philosophy (stoicism, hedonism, epicureanism).
Books about mycology and adaptogens.
Books about metabolism, immune systems, autophagy, and general physiology.

Professional

Professional 2022 Review

Open Source Work

In 2022 I have some notable accomplishments with the open source libraries I have created.

Pratica library that I created now has around 350 github stars!
All my github libraries and tools have surpassed 500 stars combined.
Created my most useful library yet called Rapini that is a code generator that combines OpenAPI, React, React Query, Typescript, and Axios.
I started sponsoring someone on github because they work on open source projects than I rely upon.
Contributed to my favourite haskell open source project called IHP.

Unity

I have surpassed my 2.5 year point at Unity. I have worked on a lot of great projects there, including Unity Reflect, Game Growth, Unity Dashboard, and User Generated Content. I have given internal presentations on topics that I find interesting and that are useful for others and I mentor lower level engineers on how to write systems and grow as a software engineer.

Hugo Mini Course Income

My mini course that I created about the Hugo static site generator has now started providing some passive income through ad revenue.

Professional 2023 Goals

Kubernetes Certificate

I’ve been using Kubernetes for years at work to build large scale microservices but never completed my understanding of all it’s concepts, I would like to finish that by getting a certificate such as CKAD

Conference Presentation

In 2023 I would like to give my first public conference talk about a topic of my choosing. Most likely codegen and the typescript compiler API, as it is my specialty. This talk should ideally be in Montreal.

AI & Tensorflow

I would like to start learning Tensorflow for handling the processing of data with AI models. I would also like to deep dive into Stable Diffusion, Dreambooth, and OpenAI’s ChatGPT.

Multiplayer

As I work at a gaming company, I would like to gain a better understanding of the different multiplayer aspects of large scale multiplayer games. Right now I work on multiplayer concepts such as UGC but I have knowledge gaps in networking concepts such as jitter buffers, state synchronization, priority accumulators, NAT punch-through, and visual smoothing. I would like to increase knowledge in these areas to be able to build better tools for unity developers.

Big Data Processing

When working with large scale microservice systems, we inevitably have large amounts of data to sift through. I know a few techniques for processing data that leverage Google’s BigQuery but I would like to learn how to set up full ETL systems with tools such as Apache Airflow, or other similar tools.

Open Source

I would like to become a maintainer for an open source library that I have not created, but rely upon. I hope to become a maintainer for an F# library called SwaggerProvider

React Query Codegen from OpenAPI

Thu, 09 Jun 2022 00:00:00 +0000

Rapini is a new tool that can generate custom React Query hooks using OpenAPI (Swagger) files.

The Command Line Interface (CLI) tool will take a path to an Open API file and generate a package that includes react hooks, typescript types and axios http requests - and this package is conveniently bundled in a way that it can be published to NPM or any other package registry of your choosing.

No need to manually write axios request functions and react query code to start using your backend endpoints, just generate and import your code to ship features faster.

How to generate react hooks from Open API files

Using the rapini CLI, here is an example to generate your react query hooks, axios requests and typescript types from Open API.

# Install the CLI tool globally (need npm)
npm i -g rapini

# Pass the path to your Open API file to rapini
rapini -p path/to/openapi.yaml

And that’s it! 1 command to install the CLI globally and 1 command to generate everything you will ever need.

The generated code will be outputted to rapini-generated-package folder in your current directory, but that could be changed with a CLI option --output-dir, like this: rapini -p path/to/openapi.yaml --output-dir /my-custom-package.

There are many CLI options to customize the generated code, including options for:

specifying the name and package version for the generated package’s package.json file
specifying a base url for every request since it may not be included in the OpenAPI files
specifying replacers to customize the route used in the requests incase you may need to modify what’s in the OpenAPI file without actually changing the OpenAPI file

All the options can be found on the rapini readme.

Why codegen React-Query with OpenAPI?

Code generation or codegen is a popular way to increase productivity, reduce bugs, and lower the amount of time it takes to ship features quickly.

OpenAPI already provides all the necessary information for writing code automatically, so we don’t need to write the code manually anymore. We no longer need to manually write out the Typescript types for every requests payload and response, because they are already specified in the OpenAPI file. No longer do we need to write axios functions for every request, or react query hooks for every axios call.

Every GET request will get it’s own React Query custom Query hook, and every non-GET, such as POST/PUT/PATCH/DELETE will get their own custom React Query Mutation hook.

Why codegen Axios requests with OpenAPI?

Rapini uses axios as it’s main http client because of it’s flexibility for request and response interceptors and global configs. Rapini takes an axios instance when initializing and uses that instance for all react query hooks under the hood.

React Query OpenAPI Codegen Example

Once you generate the custom npm package using rapini, you can start to import all the react query hooks, types, requests and query keys from the package. Let’s say you generated your package with output name of my-package, like this: rapini -p path/to/openapi.yaml --output-dir /my-package then you can start importing like this:

import { initialize } from "my-package";
import type { Pet } from "my-package";
import { axiosInstance } from "./your-custom-axios-instance";

const rapini = initialize(axiosInstance);

const { queries, mutations, queryIds, requests } = rapini;

const MyComponent = () => {
 const { data, isLoading, isError } = queries.usePets();

 return (
 <ul>
 {data.pets.map((pet) => (
 <li key={pet.id}>{pet.name}</li>
 ))}
 </ul>
 );
};

Rapini uses the OpenAPI operationId to name all the hooks and requests in the code, so if you have a request with operationId like createPet, then an axios request will be made called createPet and react query mutation hook will be created called useCreatePet and a query key will be created called createPet, and all relevant request payload will be taken into account.

I hope you enjoy rapini and start deleting old code to replace with new generated code!

Traversing the C# syntax tree with F#

Thu, 09 Dec 2021 00:00:00 +0000

This article will go over the basics of the .NET compiler platform feature for analyzing the C# syntax tree, using F#.

.NET provides a Syntax API that can read any C# or Visual Basic source file and provide the corresponding Syntax Tree for that code.

Why

Why would someone need to traverse the C# syntax tree?

Well, it can be for a number of reasons, maybe you want to gather statistics about how many classes, namespaces and methods you have, maybe you want generate code based on what is already written, maybe you want to create new tools like a new linter or a tool like Swagger. All these things can be done by analyzing the syntax tree.

Recently I found myself using the Syntax API for finding Attributes above certain methods and classes, and based on the name and arguments of the Attributes, I generated various other files that were used elsewhere.

using System.Collections;
using System.Linq;
using System.Text;

namespace FunWithSyntaxTrees
{
 class Program
 {
 static void Main(string[] args)
 {
 // ...
 }
 }
}

The snippet above shows a small program. We will use this snippet as our input for analyzing the syntax tree.

How

Assuming you have an F# environment setup. You can begin by installing the nuget package Microsoft.CodeAnalysis.CSharp and importing that into your project.

open Microsoft.CodeAnalysis
open Microsoft.CodeAnalysis.CSharp
open Microsoft.CodeAnalysis.CSharp.Syntax

module Main =

 [<EntryPoint>]
 let main argv =
 0

After you install the package and add your open directives, we will hardcode the C# source code from above into the file, above the main entrypoint function.

// ... open directives

let code = """
using System.Collections;
using System.Linq;
using System.Text;

namespace FunWithSyntaxTrees
{
 class Program
 {
 static void Main(string[] args)
 {
 // ...
 }
 }
}
"""

module Main =

 [<EntryPoint>]
 let main argv =
 0

When you write a real program that uses the Syntax API, you will most likely be reading the C# source from files, like this let code = File.ReadAllText "/path/to/file", instead of hardcoding the string like we did, but for this tutorial it is fine for demonstration.

So we will begin by passing the string of C# source code to the Syntax API to be parsed, in return we will get the Syntax Tree that we can begin analyzing.

[<EntryPoint>]
let main argv =
 let syntaxTree: SyntaxTree = CSharpSyntaxTree.ParseText code

 0

Note: I will write out the Type’s of all the variables, but it is unnecessary most of the time since F#’s type inference is very capable of inferring the type itself. Just like in C# when you use the var keyword, it is capable of knowing the underlying type, in F# this inference is even more powerful and applies to arguments, functions and everything in-between.

Now that the Syntax API has returned our needed Syntax Tree, we can begin travering it and exploring what it offers as data.

First let us get all the using directives in the file. We start by getting the root node of the file, then we iterate over all the child nodes inside the root node and find the ones that are the correct UsingDirective type.

[<EntryPoint>]
let main argv =
 let syntaxTree: SyntaxTree = CSharpSyntaxTree.ParseText code

 let rootNode: CompilationUnitSyntax = syntaxTree.GetCompilationUnitRoot()
 let rootNodeChildren: SyntaxNode seq = rootNode.ChildNodes()

 0

The rootNodeChildren variable holds all the child SyntaxNode’s of the root node. The root node is basically the first node of the SyntaxTree which holds everything, and a SyntaxNode is the most general type of node.

We now need to iterate over these children to find the correct SyntaxNode for using directives since that is what we are looking for. We will declare a small helper function to help find them.

let usingDirectiveNode (node: SyntaxNode): UsingDirectiveSyntax option =
 match node with
 | :? UsingDirectiveSyntax as usingDirective -> Some usingDirective
 | _ -> None

[<EntryPoint>]
let main argv =
 let syntaxTree: SyntaxTree = CSharpSyntaxTree.ParseText code
 let rootNode: CompilationUnitSyntax = syntaxTree.GetCompilationUnitRoot()
 let rootNodeChildren: SyntaxNode seq = rootNode.ChildNodes()

 let usingDirectives: UsingDirectiveSyntax seq =
 Seq.choose usingDirectiveNode rootNodeChildren

 0

The new helper function usingDirectiveNode takes a generic SyntaxNode and checks if it is of the UsingDirectiveSyntax variety, if it is, it returns an F# Option type containing the using directive node.

Note: An F# Option type is a way to represent a “nullable” value, since there are no real null values in F#, nullable values are representated as Algebraic Data Types, such as the Option type.

We use the new helper function by mapping over every node and passing it to the function. We use Seq.choose to filter out any None types and keep all the Some types. It also unwraps the Some types so we can keep using them without Option mapping.

So Seq.choose is just a fancy way of doing Seq.map and then Seq.filter specifically with Option types since the type signature is ('T -> 'U option) -> seq<'T> -> seq<'U>.

Moving along, so now that we have a sequence of using directives in a variable, we can get the specific properties of a using directive. For now we wil just print them out as proof.

let usingDirectiveNode (node: SyntaxNode): UsingDirectiveSyntax option =
 match node with
 | :? UsingDirectiveSyntax as usingDirective -> Some usingDirective
 | _ -> None

[<EntryPoint>]
let main argv =
 let syntaxTree: SyntaxTree = CSharpSyntaxTree.ParseText code
 let rootNode: CompilationUnitSyntax = syntaxTree.GetCompilationUnitRoot()
 let rootNodeChildren: SyntaxNode seq = rootNode.ChildNodes()
 let usingDirectives: UsingDirectiveSyntax seq =
 Seq.choose usingDirectiveNode rootNodeChildren

 usingDirectives
 |> List.ofSeq
 |> List.map (fun u -> printfn $"{u.ToString()}")
 |> ignore

 0

The output of running our program would be:

using System.Collections;
using System.Linq;
using System.Text;

Pretty cool right? We analyzed our C# code and found our using directives and printed them out.

We can use that strategy to find anything in our code, including methods, method arguments, types, classes, interfaces, enums, comments, attributes, etc, everything!

If you found this useful, feel free to follow me on twitter at @rametta

Simple Remote Data in Typescript

Thu, 05 Nov 2020 00:00:00 +0000

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.

Remote Data greatly simplifies the 4 states of any IO operation - initial state, loading state, failure state or success state, by combining them into one pure union so none of these states can overlap and cause impossible states.

Why would I use a Remote Data?

To simplify your state model and prevent impossible states! SRD allows us to perform safe and pure computations on our data without redundant null checks.

It also allows us to cleanly represent our state in our UI applications by providing functions such as match which is our pattern matcher utility.

How would I use a Remote Data?

Here is a popular use case in any React application - fetching data from somewhere and displaying it on screen, while also displaying loading states and error states if the fetch fails.

import React, { useState, useEffect } from 'react'
import { SRD, notAsked, loading, failure, success } from 'srd'

const App = () => {
 const [rd, setRd] = useState(notAsked())

 useEffect(() => {
 setRd(loading())
 fetch('...')
 .then((data) => setRd(success(data)))
 .catch((err) => setRd(failure(err)))
 }, [])

 return SRD.match({
 notAsked: () => <div>Empty</div>,
 loading: () => <div>Loading...</div>,
 failure: (err) => <div>{err}</div>,
 success: (data) => <div>{data}</div>,
 }, rd)
}

Without SRD, we would need to manually manage states for errors, loading and initial states separately - with SRD the code is a lot smaller, easier to follow and most importantly, safer.

What else?

SRD also provides a lot of great functions for accessing and modifying the data inside the Remote Data.

If we needed to modify the data inside a success we can use the popular map function to do so, it will allow us to run a function on the inside data without worrying if it’s a success or not.

Here is a TypeScript React example for updating an object:

const [rdPerson, setPerson] = useState<RD<string, Person>>(notAsked())

useEffect(() => {
 setPerson(loading())
 fetch('...')
 .then((person) => setPerson(success(person)))
 .catch((err) => setPerson(failure(err.msg)))
}, [])

const doubleAge = (person: Person): Person =>
 ({ ...person, age: person.age * 2 })

const handleClick = () => {
 setPerson(rd => SRD.map(doubleAge, rd))
}

return <>
 {
 SRD.match({
 notAsked: () => 'Empty',
 loading: () => 'Please wait...',
 failure: (msg) => `There was a problem: ${msg}`,
 success: person => `My age is ${person.age}`
 }, rdPerson)
 }
 <button onClick={handleClick}>
 click to double my age
 </button>
</>

And map is not the only thing we can do, SRD provides over a dozen more utilities for managing your SRD state!

I hope this article clarified the advantages of using a Remote Data type and how to use SRD, I encourage you to try it out! If you do, feel free to “Star” 🌟 the repo on github!

5 reasons why Hugo is better than Gatsby

Sun, 16 Aug 2020 00:00:00 +0000

Hugo is an amazingly underrated static site generator and this post is aimed to provide some examples on why it may be a better choice than Gatsby for your next static site!

TLDR;

Hugo builds are way faster than Gatsby
Hugo’s template system is simple
Hugo’s built-in features are better than Gatsby’s plugin features
Hugo doesn’t require any JS to be used, but supports JS with ESBuild
Hugo has a small learning curve

1. Build Times

Gatsby

Gatsby is notorious for having long build times that depend on which plugins you use and amount of data you have in each page.

It is not unusual for Gatsby builds to take more than 20+ minutes to build a production site that only has a couple hundred pages. If you use popular plugins like gatsby-image, then expect your build times to skyrocket even higher.

If you use Gatsby’s internal GraphQL implementation for saving and querying data nodes inside your pages, then expect longer build times as well.

Gatsby will promote their new incremental builds and cloud build capabilities, but they are marginally faster, buggy, and cause serious vendor lock-in to their Gatsby Cloud CI service.

Hugo

Hugo on the other hand, is known for it’s extremely fast builds.

On average every page can be generated in less than 1ms, so a site with 10,000 pages can take just 10 seconds to build, whereas a Gatsby site with 10,000 pages, with the same amount of data, would take 30+ minutes or even hours to build.

Hugo also has native image processing similar to gatsby-image but is way faster and would marginally increase build time.

2. Templates

Gatsby

Gatsby is built on top of React, and therefore uses JSX as it’s template system.

JSX is transformed into HTML at build time for the first page load and then re-rendered so Javascript can take control of all document nodes at runtime. Using React and JSX for static sites, that don’t necessarily need complex interactions and logic, means that you ship large JS bundles (that include the React library, Gatsby library, plugins, 3rd party npm libraries, polyfills and more) with every page - whereas the equivalent vanilla JS would most likely be a fraction of the size.

Computers or phones with low processing power or memory can struggle to display sites with large JS bundles and can feel laggy and unresponsive.

Hugo

Hugo uses the Go Template language for it’s templates which has simple, easy to read syntax that doesn’t require knowledge of JS to be written.

The Go Templates are converted to HTML at build time and if their is optional JS included on the page, it can be minified, inlined, and even compiled using ESBuild which is included in Hugo automatically.

3. Features

Gatsby is marketed to have a large amount of features that other static site generators do not have, largely attributed to it’s plugin system. But even with Gatsby’s plugin system, Hugo has all the important features built-in to it’s core instead of needing to install it separately.

In one of Gatsby’s thousands of marketing pages, they show a breakdown of Gatsby vs Hugo vs Jekyll and they show how Gatsby wins or ties in every category, but most of these comparisons don’t make any sense or are completely false.

For example, Gatsby shows that Hugo has no modern javascript syntax even though Hugo has ESBuild which is orders of magnitudes faster than Gatsby’s webpack implementation for compiling modern javascript syntax.

Another example is that Gatsby claims that Hugo does not have declarative data queries or UI building which is completely false. Hugo has data templates, data queries and components in the form of partials, inside of templates.

Also, Gatsby claims that Hugo doesn’t have pair programming in it’s community, which is false, Hugo has a discourse, and they say that Hugo has no swag store… Does that matter? who cares?

There are more examples in that chart of Gatsby trying to make themselves seem better but are just lying, and it’ll take awhile to dispute all of them, so we will just move on.

4. JavaScript Support

Gatsby is built on top of React so it of course has JS support by using Webpack and Babel to compile down for browser support.

But as mentioned above, Hugo also has JS support by leveraging ESBuild, which is a JS bundler and minifier written in Go and is orders of magnitude faster than the Webpack and Babel combo.

Hugo also makes it way easier to code-split your JS code by just declaring which files you want loaded in each template. You can even include React if needed for more complex components.

Details here in their docs.

5. Learning Curve

Gatsby has an incredibly large learning curve, to get started writing useful Gatsby sites, one must know:

JS / NodeJS
JSX
NPM
React
GraphQL
Gatsby’s complicated build system, transform plugins, source plugins, Gatsby Themes, Gatsby Recipes, and Gatsby’s CLI
HTML
CSS
Markdown - optional

And some of those are very large topics, like React and GraphQL.

To get started with Hugo, one must know:

HTML
CSS
Hugo Template Syntax and Template Lookup order
Markdown - optional

It is a lot easier to get started with Hugo and scale out Hugo for complicated and large sites.

Honorable Mention

Gatsby is a for-profit business and will push their products like Gatsby Cloud on you even if there are better alternatives.

Using TypeScript ADT's to write more reliable React

Tue, 28 Jul 2020 00:00:00 +0000

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.

Basic Types

In Javascript, you can not declare a type that prevents other types from being assigned to it. The below example we see that anything can be assigned to the language variable. We can assign a number or a boolean or an object to it if we later wanted, but that may cause bugs in the future if we were not expecting the variable type to be something other than a string.

let language = 'en'

In Typescript, we get more control over declaring types. See below, now we can only assign a string to the language variable, which is much better. Now when we access this variable in the future, we are pretty certain that the value will be a string and proceed accordingly.

let language: string = 'en'

But we can do better…

Union Types

With Typescript Union Types, we can say something can be more than one type. 😮 In the below example, we see that the language variable can either be a string OR a number.

let language: string | number = 'en'

You might be saying to yourself, “cool, but why would I want two different types in one variable?”

This is a great question, but before we figure out why we would need this, we need to understand that anything can be considered a type in Typescript, including specific string values.

So now we can specify exactly which values can be assigned to the language variable.

let language: 'en' | 'fr' | 'ru' = 'en'

Now we can only assign certain values to language.

The interesting question now is, “how do we know which type is currently stored?”

If we have a variable that can hold two different types, when we access that value, we must check to see what the type is before we do something with it.

let nameOrID: string | number = 'Jason'

if (typeof nameOrID === 'string') {
 // do something with string...
} else if (typeof nameOrID === 'number') {
 // do something with number...
}

This is important, because if we do not check the value type then we do not know which one of the types is currently being used - so we might try to do math with a string, or do a string operation on a number…

Knowing these things, now we can explain Typescript’s Discriminated Union Type.

Discriminated Union Types

Using the things we learned about Union Types, we can construct a special union that obeys some rules.

The rules that should be followed are:

All types in the union, share a common property.
There needs to be a union type declared from the types.
There must be type guards on the common propery.

Here is an example:

type HockeyGame = {
 kind: 'hockey' // Rule 1 - common property 'kind'
 homeScore: number
 awayScore: number
 clock: number
 isDone: boolean
}

type BaseballGame = {
 kind: 'baseball' // Rule 1 - common property 'kind'
 inning: number
 isTop: boolean
 stadium: string
}

// Rule 2 - Union type declared
type Game = HockeyGame | BaseballGame

const gameToString = (game: Game): string => {
 // Rule 3 - Type guard on the common property
 switch (game.kind) {
 case 'hockey':
 return `Hockey game clock: ${game.clock.toString()}`
 case 'baseball':
 const frame = game.isTop ? 'top' : 'bottom'
 return `Baseball game is in the ${frame} of inning ${game.inning}`
 }
}

In the example above, we see that we used what we learned about assigning specific strings to a type with the kind property. The kind property can only ever be hockey or baseball and never anything else.

This common property acts as an ID for the object and allows us to know what other properties are defined and available to be accessed.

Following these rules will allow the Typescript compiler to know which fields are available. So if you have checked the guard and deemed it to be hockey then the compiler will only allow you to access the fields from the HockeyGame type.

This can prevent a lot undefined errors you may get from accessing properties that may or may not be there at different times.

ADT’s with React

Now let’s see how we can take advantage of this pattern in React.

Using the Game types declared above, we can safely render different components based on the common property in the union.

const HockeyGameBox = ({ game }: { game: HockeyGame }) => (
 <div>
 {game.homeScore} - {game.awayScore}
 </div>
)

const BaseballGameBox = ({ game }: { game: BaseballGame }) => (
 <div>
 {game.inning} - {game.stadium}
 </div>
)

const renderGame = (game: Game) => {
 switch (game.kind) {
 case 'hockey':
 return <HockeyGameBox game={game} />
 case 'baseball':
 return <BaseballGameBox game={game} />
 }
}

const GamePage = () => {
 const [games] = useState<Game[]>([
 /* mix of different games */
 ])
 return games.map(renderGame)
}

As you can see, using ADT’s can greatly reduce the amount of runtime bugs you get when using dynamic data. It’s not a silver bullet for preventing bugs, but it’s a step in the right direction.

To learn more about ADT’s, check out my post about it in Elm: Elm’s Remote Data Type in Javascript

Lessons learned from my first 10k LOC in Elm

Thu, 24 Oct 2019 00:00:00 +0000

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:

1. Decoding Empty Lists & Strings

When I first started the project, I had a lot of types with fields declared like this:

type alias Something =
 { name : Maybe String
 , stuff : Maybe (List String)
 }

and the way I was decoding these values from my API was like this:

import Json.Decode as D
import Json.Decode.Pipeline exposing (optional)

D.succeed Something
 |> optional "name" (D.nullable D.string) Nothing
 |> optional "stuff" (D.nullable (D.list D.string)) Nothing

This was fine at first, but I noticed that after awhile I was repeating logic inside my update functions to check if the name field was an empty string, or if the stuff field was an empty list, and if it was, change the value to Nothing instead of Just "" or Just [].

So after awhile, I thought it would be more efficient to check for empty strings and empty lists during the decoding phase, so I came up with two decoder helper functions, decodeNonEmptyString and decodeNonEmptyList:

decodeNonEmptyString : D.Decoder (Maybe String)
decodeNonEmptyString =
 D.andThen (notEmptyString >> D.succeed) D.string

decodeNonEmptyList : D.Decoder a -> D.Decoder (Maybe (List a))
decodeNonEmptyList l =
 D.andThen (notEmptyList >> D.succeed) (D.maybe (D.list l))

notEmptyList : Maybe (List a) -> Maybe (List a)
notEmptyList =
 Maybe.andThen (\l ->
 if List.isEmpty l then
 Nothing
 else
 Just l
 )

notEmptyString : String -> Maybe String
notEmptyString s =
 if String.isEmpty s then
 Nothing
 else
 Just a

So now my original decoders use these new utilities like this:

D.succeed Something
 |> optional "name" decodeNonEmptyString Nothing
 |> optional "stuff" (decodeNonEmptyList D.string) Nothing

And I don’t need to check for emptiness anymore in my update functions 🎉

2. Flatter pattern matching

This one might seem really obvious, but took me awhile to realize that doing this results in flatter pattern matching functions.

If I have a type like RD.WebData (Maybe (List Person)), the way I original matched on it was like this:

case response of
 RD.NotAsked -> div [] [text "Not Asked"]
 RD.Loading -> div [] [text "Loading"]
 RD.Failure e -> div [] [text "Error"]
 RD.Success maybeData ->
 case maybeData of
 Nothing -> div [] [text "No data"]
 Just data -> div [] [text "Data!"]

But I realized that I could flatten this into one case statement instead of 2 separate ones like this:

case response of
 RD.NotAsked -> div [] [text "Not Asked"]
 RD.Loading -> div [] [text "Loading"]
 RD.Failure e -> div [] [text "Error"]
 RD.Success Nothing -> div [] [text "No data"]
 RD.Success (Just data) -> div [] [text "Data!"]

See? Much nicer!

3. Select Wrapper

This is one of the first abstractions I made when I started because I wanted an easy reusable way to use select [] [] and found that the native one in Elm is not as nice as I hoped.

So I wrote a small wrapper called viewSelect:

viewSelect : Bool -> (String -> msg) -> List Option -> Html msg
viewSelect disabled changeMsg options =
 select
 [ onChange changeMsg
 , Html.Styled.Attributes.disabled disabled
 ]
 (List.map
 (\opt ->
 option
 [ value opt.value
 , Html.Styled.Attributes.selected opt.selected
 , Html.Styled.Attributes.disabled opt.disabled
 ]
 [ text opt.text ]
 )
 options
 )

type alias Option =
 { text : String
 , value : String
 , selected : Bool
 , disabled : Bool
 }


onChange : (String -> msg) -> Html.Styled.Attribute msg
onChange tagger =
 on "change" (D.map tagger Html.Styled.Events.targetValue)

Now I use viewSelect instead of the native select and I just need to pass in a list of Option instead. Every time a user changes the select box, the changeMsg fires with the new value.

4. ChangeField Pattern

In my app, I have a lot of forms, and every form needs to modify some field inside my model. The way I originally started doing this was:

type Msg
 = ChangeName String
 | ChangeAge String
 | ChangeHeight String
 | ChangeWeight String

update msg model =
 case msg of
 ChangeName name -> ({ model | name = name }, Cmd.none)
 ChangeAge age -> ({ model | age = age }, Cmd.none)
 ChangeHeight height -> ({ model | height = height }, Cmd.none)
 ChangeWeight weight -> ({ model | weight = weight }, Cmd.none)

This was also fine at first, but my app has A LOT of forms and this was not scaling well. So instead of creating a new Msg type for every field, I created one Msg type for updating any field. And it works like this:

type Msg = ChangeField (String -> Person -> Person) String

update msg model =
 case msg of
 ChangeField setter content -> (setter content model, Cmd.none)

Now every time a field needs to change, instead of calling ChangeName "Jason", I can now call ChangeField setName "Jason" where setName equals:

setName : String -> Person -> Person
setName content person =
 { person | name = content }

This allows me to create individual setter functions for each field and do any data manipulations from String into any type I need.

It simplifies my update function by reducing the amount of Msg types it can match on, and it nicely separates out my data manipulation logic for each field.

5. Posix Wrappers

This one is pretty simple really. I use Elm’s Time.Posix type a lot around my app, so I needed functions to format, manipulate and display Posix in my UI. I came up with a few helpers for this and call it my HumanTime module:

humanDateTime : Zone -> Posix -> String
humanDateTime z p =
 humanDate z p ++ " " ++ humanTime z p

humanTime : Zone -> Posix -> String
humanTime z p =
 humanHour z p ++ ":" ++ humanMinute z p

humanDate : Zone -> Posix -> String
humanDate z p =
 humanMonth z p ++ " " ++ humanDay z p ++ ", " ++ humanYear z p

humanYear : Zone -> Posix -> String
humanYear z =
 toYear z >> String.fromInt

humanDay : Zone -> Posix -> String
humanDay z =
 toDay z >> String.fromInt

humanHour : Zone -> Posix -> String
humanHour z =
 toHour z >> String.fromInt

humanMinute : Zone -> Posix -> String
humanMinute z =
 toMinute z
 >> (\m ->
 if m > 9 then
 String.fromInt m
 else
 "0" ++ String.fromInt m
 )

humanMonth : Zone -> Posix -> String
humanMonth z p =
 case toMonth z p of
 Jan -> "Jan"
 Feb -> "Feb"
 Mar -> "Mar"
 Apr -> "Apr"
 May -> "May"
 Jun -> "Jun"
 Jul -> "Jul"
 Aug -> "Aug"
 Sep -> "Sep"
 Oct -> "Oct"
 Nov -> "Nov"
 Dec -> "Dec"

And that is it so far! I am sure I will learn even more in the next 10k LOC that I write and might even figure out better ways of doing these things that I just mentioned.

Elm is an amazing tool for creating frontends and I can’t ever see myself going back to React or any other non-functional frameworks for personal projects.

Pratica, now fully in Typescript!

Fri, 18 Oct 2019 00:00:00 +0000

Pratica is now written completely in Typescript!

What is Pratica?

Pratica is a super tiny 720B monadic library, comparable to Crocks or Monet JS.

Why would I use Pratica?

If you want to start writing more functional code in Javascript or Typescript, this is a great library for learning some FP fundamentals, while also making your code safer and more resilient to runtime bugs. It’s super tiny size and easy to read dot-chaining syntax makes it easy to get started in any project.

How do I start?

You can install it with: yarn add pratica or npm i pratica. Then you can import the main functions like:

import { nullable } from 'pratica'

Create small, safe and easy to read programs by composing functions together, like:

// Typescript

import { Maybe, nullable, get, parseDate } from 'pratica'

const getPersonAge = (person?: Person): Maybe<number> =>
 nullable(person)
 .chain(get<string>(['birthday']))
 .chain(parseDate)
 .map(birthday => Date.now() - birthday.getTime())
 .chain(parseDate)
 .map(date => Math.abs(date.getUTCFullYear() - 1970))


getPersonAge({ birthday: '1994-06-08' }) // -> Just(25)
getPersonAge({ birthday: 771033600000 }) // -> Just(25)
getPersonAge({ birthday: null }) // -> Nothing
getPersonAge(null) // -> Nothing

Pratica works great with React too! Use it in your JSX for handling cases with missing data.

const viewPersonAge = ({ person }) =>
 getPersonAge(person).cata({
 Just: age => <div>{age}</div>
 Nothing: () => <span>No age available</span>
 })

Try it out

Try it out in an online browser sandbox here!

Elm's Remote Data Type in Javascript

Fri, 26 Jul 2019 00:00:00 +0000

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:

// Javascript

const state = {
 data: null,
 error: null
}

fetch('/api/data')
 .then(res => res.json())
 .then(data => state.data = data)
 .catch(err => state.error = err)

and showing it on screen:

// React

const MyComp = ({ error, data }) => {
 if (error) {
 return <div className="error">{error}</div>
 } else {
 return <div>{data}</div>
 }
}

But there are a few problems with this approach:

What do we show on screen when the data is loading from the server?
What do we show on screen before we even request the data from the server?
Do we properly clear the previous error if the data is a success?
Do we properly clear the previous data if we get an error?

So how can we solve this?

Some might recommend we can add more fields to our state to help represent all the cases, like this:

// Javascript

const state = {
 data: null,
 error: null,
 loading: false,
 isAsked: false
}

and in the UI would be similar to this:

// React

const MyComp = ({ error, data, loading, isAsked }) => {
 if (!isAsked) {
 return <div>Nothing asked yet</div>
 }

 if (loading) {
 return <div>Loading...</div>
 }

 if (error) {
 return <div className="error">{error}</div>
 }

 if (data) {
 return <div>{data}</div>
 }

 return <div>Some default fallback to be safe</div>
}

But the problem with this is that it becomes too easy for our UI to accidently show the wrong case by forgetting to set loading to false after the data comes back as an error, or forgetting to clear the error if a retry returned a success.

Infact, optimistically the structure above can have a cardinality of 2 x 2 x 2 x 2 which is 16 possible different combinations of states we can be in at any given time. That is a lot of cases to represent.

Let’s look at how Elm simplifies this process with needing only 4 cases.

Remote Data in Elm

The Remote Data type can be created manually by writing a custom type like below, or by using a pre-made version from a library like krisajenkins/remotedata:

-- Elm

type RemoteData e a
 = NotAsked
 | Loading
 | Error e
 | Success a

and then using this type as your model:

-- Elm

type alias Model = RemoteData String MyData

-- and set the initial model value as NotAsked

init = NotAsked

What we need to understand is that our state can only be one of these 4 types at any time. We can not both be in a Loading state and in a Success state at the same time, or else our UI will be showing 2 different things. This is why our cardinality is only 4 now instead of 16, because there is no way to represent our state more than that.

Using this model we can now create a UI for each case like this:

-- Elm

view model =
 case model of
 NotAsked -> div [] [ text "Not asked yet" ]

 Loading -> div [] [ text "Loading..." ]

 Error err -> div [] [ text err ]

 Success data -> div [] [ text <| "Here is my data: " ++ data ]

And now whenever we update our state, we never need to worry about clearing previous state or forgetting to flip one field to null - because there is only one field in our model.

This is a great pattern for handling remote data fetching in Elm, but how do we take advantage of this pattern in Javascript? Daggy.

Daggy

There are a few different libraries in Javascript that can help model your application with Algebraic Data Types like we have in Elm with the type keyword. One popular library is Daggy.

To represent remote data in Daggy, we would create a type like this:

// Javascript

import { taggedSum } from 'daggy'

const RemoteData = taggedSum('RemoteData', {
 NotAsked: [],
 Loading: [],
 Error: ['e'],
 Success: ['a']
})

Then once we have our type, the implementation is almost identical to how we would work in Elm.

Our state would only have one field instead of 4, and a cardinality of 4 instead of 16.

// Javascript

const state = {
 data: RemoteData.NotAsked
}

// Fetch some data

state.data = RemoteData.Loading

fetch('/api/data')
 .then(res => res.json())
 .then(data => state.data = RemoteData.Success(data))
 .catch(err => state.data = RemoteData.Error(err))

And in our UI, like React, we would have:

// React

const MyComp = ({ data}) => data.cata({
 NotAsked: () => <div>Not asked yet</div>,
 Loading: () => <div>Loading...</div>,
 Error: err => <div>{err}</div>,
 Success: d => <div>Here is my data: {d}</div>
})

Using this pattern actually helps move a lot of render logic out of your components in React, like checking fields with if (field) {...} and instead moves that responsibility to something like a reducer, which will make it a lot easier to run unit tests on.

If you would like to learn more about Algebraic Data Types in Javascript, check out these links:

If you like this article, be sure to follow me!

Comparing Elm to React/Redux

Thu, 11 Jul 2019 00:00:00 +0000

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.

Pain Points

After awhile many of the React/Redux projects I have worked on become massive, with hundreds of reducers, hundreds of components, mixtures of epics, thunks, reselect selectors, sagas and custom middlewares. Hot module replacement becomes slow, build times become slow, runtime performance gets slow, audit scores get low scores, bundle size gets big and the app gets an increasingly large amount of runtime errors with every push.

I know this is not everyone’s experience, and if you work somewhere that enforces strict rules during development, then you will not have all these problems. But chances are you have experienced a few of these pain points too. (And if you haven’t experienced any of these pains, then good work, it’s a difficult feat)

When I speak of development “rules”, I don’t mean linter rules and prettier. I mean things like not installing too many third party libraries, having proper code splitting for your modules, and performing weekly or monthly lighthouse audits to see where your team can improve.

The Solution

Elm has a beautiful ecosystem meant to prevent a lot of these pains. It comes with its own struggles too for sure, but worth it, in my opinion.

Advantages of Elm:

No runtime exceptions
Everything is immutable
Small bundle sizes
Built-in event emitter and global state store similar to Redux
Built-in router for single page apps
Built-in code formatter (like prettier)
Strong type system
Easy interop with JS
Amazing compiler error messages and fast compile times

These advantages lead to more reliable webapps, better DX, and a better experience for end users.

Comparing the Elm architecture to React/Redux

Learning Elm can seem like a daunting task, especially with all the new syntax and concepts, but this is what this article is aimed to help with and explain that it’s really not that different to React.

Below, I have written the same app in Elm and React/Redux to show their similarities.

State

In Redux there is a global store used for saving application state, Elm has a similar concept called the Model, it is a strongly typed version of a store.

Redux initial state for a reducer

const initialState = {
 count: 0
}

Elm initial model and typings

type alias Model =
 { count : Int }

initialModel =
 { count = 0 }

The type alias in Elm ensures that nothing other than a number will ever be assigned in the count property.

Actions

In Redux, you need to write actions for triggering some state changes or side effects. Elm has Messages which are very similar, but typed!

Redux Actions

// action types
export const INCREMENT = 'INCREMENT'
export const DECREMENT = 'DECREMENT'

// actions
export const increase = () => ({ type: INCREMENT })
export const decrease = () => ({ type: DECREMENT })

Elm Messages

type Msg = Increase | Decrease

Reducers

For every redux action you create, you normally have a corresponding reducer. In Elm it is almost the same except you are forced to always have an update function (reducer) for every message (action).

Redux Reducers

export function myReducer(state = initialState, action) {
 switch (action.type) {
 case INCREMENT:
 return { count: state.count + 1 }

 case DECREMENT:
 return { count: state.count - 1 }

 default:
 return state
 }
}

Elm Update

update msg model =
 case msg of
 Increase ->
 { model | count = model.count + 1 }

 Decrease ->
 { model | count = model.count - 1 }

Everything is immutable in Elm, so to update a record (object) you must use the pipe | and new record syntax to return a new copy of the state with the updated property.

Components

Components in React are what create the view that will be rendered for users to see. Elm does not have components but just a single view function that will render.

React JSX

import React from 'react'
import { connect } from 'react-redux'
import { increase, decrease } from './reducer'

const App = ({ increase, decrease, count }) => (
 <div>
 <button type="button" onClick={increase}>+1</button>
 <div>{count}</div>
 <button type="button" onClick={decrease}>-1</button>
 </div>
)

// Connect to redux
const mapStateToProps = ({ count }) => ({ count })
const mapDispatchToProps = { increase, decrease }

export default connect(
 mapStateToProps,
 mapDispatchToProps
)(App)

Elm view function

view model =
 div []
 [ button [ onClick Increment ] [ text "+1" ]
 , div [] [ text <| String.fromInt model.count ]
 , button [ onClick Decrement ] [ text "-1" ]
 ]

Connecting

In React/Redux, components do not automatically have access to the redux store or actions/reducers, they must explicitly be connected. Connecting can be done nicely with another library called react-redux. In Elm, everything automatically has access to all the message types and data in the store.

React/Redux

import React from 'react'
import { render } from 'react-dom'
import { Provider } from 'react-redux'
import { createStore } from 'redux'
import { myReducer } from './reducers'
import App from './App'

const store = createStore(myReducer)

render(
 <Provider store={store}>
 <App />
 </Provider>,
 document.getElementById('root')
)

Elm

main =
 Browser.sandbox
 { init = initialModel
 , update = update
 , view = view
 }

Conclusion

So we created a simple counter app. Overall it was pretty painless, didn’t require any of the boilerplate that redux needs, and had typed payloads! If you want to play with this example, check it out on ellie-app.

If this article intrigued you and you want to learn more about Elm, check out these resources:

Follow me on twitter! @rametta

F# for JS Devs

Fri, 15 Mar 2019 00:00:00 +0000

I recently gave an internal talk at my work about the similarities of F# compared to JS. It was generally well received, and I would like to convert that talk into a blog post for others who may be interested.

This is by no means an exhaustive list of features in F#, but the point of this post is to show familiar JS code and how it can be written equivalently in F#, because I believe showing examples like this is the best way of learning a new language and has a better chance of adoption.

Intro

F# is a functional language that runs on the .NET runtime. It is cross platform now with the intro of .NET Core so it can be written and ran on any machine. It is immutable by default, but is completely interoperable with C# or VB. It is inspired by Haskell, Scala, Erlang, C# and Python.

F# can be used for creating servers, scripts, desktop apps and mobile apps. (Even webapps, by compiling to JS directly with tools like fable)

Functions

Functions are the core of F#. There are essentially two types of functions, named and anonymous. The syntax is similar to JS but slightly shorter. In F#, all functions are curried automatically, which means all functions can be partially applied without any extra work.

const add = (x, y) => x + y
const mul = x => y => x * y // curried
add(4, 4) // 8
mul(4)(4) // 16

let add x y = x + y
let mul x y = x * y
add 4 4 // 8
mul 4 4 // 16

// anonymous
let sub = fun x y -> x - y
sub 8 4 // 4

Composition

Function composition is the process of passing the output of one function as the input to another function. In JS, one would need to nest their functions, or use a pipe or compose function as a helper to achieve this. In F# there is the pipeline operator |>, the forward composition operator >> and backwards composition operator <<.

Pipeline Operator

The pipeline operator just allows having the function argument be infront of the function instead of after it.

const add3 = x => x + 3
const mul5 = x => x * 5
const div2 = x => x / 2
div2(mul5(add3(97))) // 250

let add3 x = x + 3
let mul5 x = x * 5
let div2 x = x / 2
97 |> add3 |> mul5 |> div2 // 250

Composition Operator

The composition operator allows combining functions into one. The difference between this and the pipeline is that only functions can be composed together, whereas the pipeline can take any value and pass it to the next function.

const compose = require('..')
const add3 = x => x + 3
const mul5 = x => x * 5
const div2 = x => x / 2
const doMath = compose(div2, mul5, add3)
doMath(97) // 250

let add3 x = x + 3
let mul5 x = x * 5
let div2 x = x / 2
let doMath = add3 >> mul5 >> div2
// or backwards
let doMath = div2 << mul5 << add3
doMath 97 // 250

Lists

F# lists are pretty similar to JS arrays. Although F# has 3 types of array-like collections. Lists, Arrays, and Sequences. But I’ll just focus on Lists because they are the richest.

List Mapping

List mapping looks almost the same in F# as it does in JS, except for the fact that you must use the List.map function instead of using the array prototype to dot chain like you do in JS.

const data = [1, 2, 3]
data.map(x => x * 2)
// [2, 4, 6]

let data = [1; 2; 3]
List.map (fun x -> x * 2) data
// [2, 4, 6]

List Transformations

JS is praised for it’s rich array prototype functions like map, filter, find, reduce. F# has all of those, and more than 60 others! Such as List.sum, List.average, List.distict, List.isEmpty, List.chunkBySize and many many more.

[1, 2, 3]
 .map(x => x * 2)
 .filter(x => x > 3)
 .reduce((acc, x) => acc + x, 0)

[1; 2; 3]
 |> List.map (fun x -> x * 2)
 |> List.filter (fun x -> x > 3)
 |> List.sum

Conditionals

JS has the classic if-else syntax and also the ternary operators. F# does NOT have a ternary operator, but it does have if-else. Ternary is not really needed in F# because everything is implicitly returned anyways. The great thing about F# is that you will rarely need the if-else syntax because of pattern matching (explained below). Regardless, here is an example.

const bigify = x => x > 4 ? 'big' : 'small'
bigify(2) // 'small'
bigify(5) // 'big'

let bigify x = if x > 4 then "big" else "small"
bigify 2 // "small"
bigify 5 // "big"

Objects / Records

The equivalent of JS objects would be the F# records. Notable differences are that records always need to be associated to a type, they are reference types by default, and they are immutable. So you can not update an existing record, you would need to create a new one and copy the values.

const data = {
 name: 'jason',
 cool: true,
 age: 3.14
}

// immutably update an object by creating a new object
const data2 = {
 ...data,
 age: 2.16
}

F# *Needs a type

let data =
 { name = "jason"
 cool = true
 age = 3.14 }

// immutably update a record by creating a new record
let data2 =
 { data with age = 2.16 }

Record Types

The above examples are not exactly possible in F# without specifying a type first.

A record type defines the structure of a record. You do not need to assign the type to the variable holding the data because of F#’s strong type inference. The compiler will infer data types based on the properties defined. So in the example below, the compiler knows that data is a Person type because it has all the exact same fields defined.

type Person =
 { name: string
 cool: bool
 age: float }

let data =
 { name = "jason"
 cool = true
 age = 3.14 }

Enum Types

There are no direct comparisons in JS for enums, unless you use an objects with ints, but it is not exactly the same.

// enum
type CoolLevel =
 | Good
 | Medium
 | Bad

type Person =
 { name: string
 age: float
 cool: CoolLevel } // requires a value from the enum

let data =
 { name = "lyagushka"
 age = 3.14
 cool = Good } // assign Good because it is in the enum

Discriminated Unions Types

To get the equivalent of Union Types in JS, you would have to use some 3rd party module to get a consistent declaration of types, such as DaggyJS.

Although Daggy is great in JS, it’s pattern matching capabilities are only as good as JS can allow. This is where F# starts to shine.

If you need an explanation of union types, see this article, it will explain it much better than I can.

Below is an example of an equivalent JS daggy type vs a native F# union type, and a peak of pattern matching at the bottom.

const { taggedSum } = require('daggy')

const ProductPage = taggedSum('ProductPage', {
 Loading: [],
 Error: ['msg'],
 Success: ['product']
})

const product = {
 name: 'Red Shoe',
 price: 3.14
}

const state = ProductPage.Success(product)

// pattern match
state.cata({
 Loading: () => `<div>Loading...</div>`,
 Error: msg => `<div>${msg}</div>`,
 Success: p => `<div>${p.name}</div>`
})

type Product =
 { name: string
 price: float }

type ProductPage =
 | Loading
 | Error of string
 | Success of Product

let product =
 { name = "Red Shoe"
 price = 3.14 }

let state = Success product

// pattern match
match state with
| Loading -> "<div>Loading...</div>"
| Error msg -> "<div>" + msg + "</div>"
| Success p -> "<div>" + p.name + "</div>"

Pattern Matching

Pattern matching is popular in ML style languages because of how powerful they can be. Think of it as a switch-case statement on steroids. In F#, using the syntax of match [anything] with you can successfully figure out what the type OR value is of anything. Completely avoiding if-else or switch-case statements.

Booleans

Booleans are straight forward because they can only be 1 of 2 things, true or false.

let age = 6

match age > 12 with
| true -> printf "Teen"
| false -> printf "Not teen"

Numbers

Numbers are not as straight forward as booleans because there are potentially an infinite amount of matching possibilities, so when trying to match numbers, you will be forced to provide a default pattern by using an underscore incase no pattern is matched.

let age = 5

match age with
| 13 -> "teen"
| 1 -> "One Year Old"
| 4 | 5 -> "little" // 4 or 5 will match here
| x when x < 0 -> "not alive" // conditional logic
| _ -> "any other age" // default incase age is not matched with anything

Lists

Matching with lists is even cooler because you can use the underscore as a wildcard for any value inside the list.

let myList = [1; 2]

match myList with
| [] -> "empty list"
| [ _ ] -> "list has 1 item"
| [ _; 5 ] -> "list has 2 items, 2nd item is 5"
| [ _; _; _ ] -> "list has 3 items"
| _ -> "list does not match any of the above patterns"

Monads

Monads are a big topic, I even wrote an entire article about monads in JS.

In F#, some monads are built in, such as the Option type, and no further work is needed to use besides typing Some or None.

const { taggedSum } = require('daggy')

const Maybe = taggedSum('Maybe', {
 Just: ['value'],
 Nothing: []
})

const { Just, Nothing } = Maybe

const data = Just(50)

data.cata({
 Just: x => console.log(`Value: ${x}`), // 50
 Nothing: () => console.warn("Nothing here")
})

let data = Some(50)

match data with
| Some x -> printf "Value: %i" x
| None -> printf "Nothing here"

Typing

A brief note about typing functions in F#. Below I wrote the exact same function 4 times, each with a different way of defining the types.

The first one has implicit types, letting the compiler infer the types based on the callers and the data passed to it.

The second defines types for each parameter and then defines the return type.

The third and fourth use a type signature and an anonymous function to define the types.

All of these are valid and each can be used for different use cases.

// inferred types
let add x y = x + y

// explicit types
let add (x: float) (y: float): float = x + y

// explicit inline type signature
let add: float -> float -> float = fun x y -> x + y

// explicit separate type signature
type Add = float -> float -> float
let add: Add = fun x y -> x + y

HTTP Requests

A great part of JS is the easy to work with Promise type for doing async actions, such as HTTP requests.

Async is built into F# aswell, by using the async keyword. Here is an example of an equivalent http request of getting the html of a page.

const axios = require('axios')

axios
 .get('https://github.com/rametta')
 .then(({ data }) => console.log(`HTML: ${data}`))
 .catch(console.error)

// sync
let html = Http.RequestString("https://github.com/rametta")

// async
async { let! html = Http.AsyncRequestString("https://github.com/rametta")
 printfn "%d" html.Length }
|> Async.Start

Other cool F# stuff

Briefs snippets of other neat F# features.

Range operator

Use two dots to define a range quickly.

let myList = [ 1..5 ]
// [1; 2; 3; 4; 5]

Mutable Keyword

Use the mutable keyword as an escape hatch when wanting to mutate variables.

let mutable data = 6
data <- 8

Yield Keyword

let mySeq = seq {
 for i in 1..10 do
 for j in 10..15 do
 yield i * j
}

Tuples

let myTuple = (5, "hello")

let typedTuple: int * string = (5, "hello")

I hope this article shed some light on how similar F# is to JS, and I hope it encourages you to use it in future projects.

Basic monads in Javascript

Mon, 03 Sep 2018 00:00:00 +0000

I’m going to explain some common monads that you can start using in your javascript today. Monads will help make your code easier to read, more maintainable and most importantly - safer.

Maybe

The Maybe monad is used for dealing with nullable data. Often we like to process data in javascript, like formatting, doing calculations, filtering and sorting. But often we need to make sure the data is there before doing anything. This is where Maybe can help.

I’m going to be using a small friendly helper library called Pratica for providing an implementation of the monads in this article.

Let’s take a look at a snippet that can benefit from the Maybe monad.

const data = 'Hello my name is Jason'

if (data) {
 console.log(data.toUpperCase()) // HELLO MY NAME IS JASON
}

Now lets see how that can be refactored with a Maybe.

import { Maybe } from 'pratica'

Maybe('Hello my name is Jason')
 .map(data => data.toUpperCase())
 .cata({
 Just: data => console.log(data), // HELLO MY NAME IS JASON
 Nothing: () => console.log('No data available')
 })

See we don’t need to check if the data exists, because Maybe will automatically not run any functions afterwards if the data is null. Avoiding error’s like Uncaught TypeError: Cannot read property 'toUpperCase' of undefined

Now you might not see the advantage right away, but this isn’t where Maybe shines. Let’s look at another example with more steps.

// Step 1: Filter cool people
// Step 2: Find the first cool person
// Step 3: Log their uppercased name if there is one

const data = [
 { name: 'Jason', level: 7, cool: true },
 { name: 'Blanche', level: 8, cool: false }
]

if (data) {
 const coolPeople = data.filter(person => person.cool)
 if (coolPeople) {
 const firstCoolPerson = coolPeople[0]

 if (firstCoolPerson && firstCoolPerson.name) {
 console.log(firstCoolPerson.name.toUpperCase()) // JASON
 }
 }
}

Now let’s see the Maybe alternative.

import { Maybe } from 'pratica'

Maybe(data)
 .map(people => people.filter(person => person.cool))
 .map(people => people[0])
 .map(person => person.name)
 .map(name => name.toUpperCase())
 .cata({
 Just: data => console.log(data), // JASON
 Nothing: () => console.log('No data available')
 })

If data was actually null or undefined, then none of the .map functions would run and the Nothing function would be executed in the cata.

But let’s say we also wanted to return a default value if the data was null. Then we can use the .default() method.

import { Maybe } from 'pratica'

Maybe(null)
 .map(people => people.filter(person => person.cool))
 .map(people => people[0])
 .map(person => person.name)
 .map(name => name.toUpperCase())
 .default(() => 'No cool people yo')
 .cata({
 Just: data => console.log(data), // No cool people yo
 Nothing: () => console.log('No data available')
 })

Wow such clean, much flat.

Result

So we learned that the Maybe monad is good for dealing with nullable data, but what if we want to check the value of the data and do different things depending on the values.

Enter the Result monad (or sometimes called the Either monad).

Result is used for “branching” your logic. Let’s take a look at an example without Result first.

const person = { name: 'Jason', level: 7, cool: true }

if (person.level === 7) {
 console.log('This person is level 7, ew')
} else {
 console.error('This person is some other level, but not 7')
}

Ok, now with Result.

import { Ok, Err } from 'pratica'

const person = { name: 'Jason', level: 7, cool: true }

const lvl = person.level === 7
 ? Ok('This person is level 7, ew')
 : Err('This person is some other level, but not 7')

lvl.cata({
 Ok: msg => console.log(msg), // This person is level 7, ew
 Err: err => console.log(err) // This person is some other level, but not 7
})

Humm, I don’t see the point of this. What is Ok and Err? How is this better?

Let’s do one more example before explaining it.

In this example, we’ll have some data we need to validate before proceeding.

const data = {
 first: 'Jason',
 level: 85,
 cool: true,
 shirt: {
 size: 'm',
 color: 'blue',
 length: 90,
 logo: {
 color1: '#abc123',
 color2: '#somehexcolor'
 }
 }
}

if (data) {
 if (data.shirt) {
 if (data.shirt.logo) {
 if (data.shirt.logo.color1 !== 'black') {

 // Color1 is valid, now lets continue
 console.log(data.shirt.logo.color1)

 } else {
 console.error ('Color1 is black')
 }
 } else {
 console.error ('No logo')
 }
 } else {
 console.error ('No shirt')
 }
} else {
 console.error ('No data')
}

That looks a bit messy. Let’s see how we can improve that with Result.

import { Ok, Err } from 'pratica'

const hasData = data => data
 ? Ok (data.shirt)
 : Err ('No data')

const hasShirt = shirt => shirt
 ? Ok (shirt.logo)
 : Err ('No shirt')

const hasLogo = logo => logo
 ? Ok (logo.color1)
 : Err ('No logo')

const isNotBlack = color => color !== 'black'
 ? Ok (color)
 : Err ('Color is black')

hasData (data2)
 .chain (hasShirt)
 .chain (hasLogo)
 .chain (isNotBlack)
 .cata ({
 Ok: color => console.log(color), // #abc123
 Err: msg => console.log(msg)
 })

Interesting, it’s a lot flatter, but I still don’t understand what’s going on.

Ok, here’s what’s happening.

We start with the hasData function. That takes the initial data that needs to be validated and returns the next data that needs to be validated, but returns it wrapped inside the Result monad, more specifically, the Ok or the Err type. Both of those are what makes the Result monad, and those are how our application will branch the logic.

Why is there .chain() for every line?

Well each function is returning either an Ok or an Err data type. But every function is also expecting it’s input to be just data, and not data wrapped inside of a monad. So calling chain on each function will unwrap the data from the monad so the function can read what’s inside.

Why is this better?

Well, better is subjective, but in functional programming this is considered better because it pushes the IO (IO being the console logging statements) to the edges of the program. That means that there are more pure functions that can be unit tested and don’t have IO mixed inside of them. Having IO inside of pure functions don’t make them pure anymore, which means they would be harder to unit test and be a source of bugs. Console logging is not a big deal in javascript, but if the IO was making a network request, then this type of programming makes a big difference, because all logic/validation would be independent of IO and easier to test and maintain.

So those are 2 popular monads you can start using today.

This is my first article of dev.to so let me know what you think in the comments!

If you’d like to learn more about monads, check out these cool articles and libraries.

About

Mon, 01 Jan 0001 00:00:00 +0000

Jason is a Software Engineer from Montreal, Canada.

He currently works at Zapier on AI orchestration and is the author of the Typescript Compiler API book.

Check out his Github.

Contact

Mon, 01 Jan 0001 00:00:00 +0000

Contact Jason by sending an end-to-end encrypted email to public@rametta.org.

If the email is not encrypted using the following PGP public key then it will not be delivered.