DEV Community: Christos Dimitroulas

Currying, Part 2 - Partial Application

Christos Dimitroulas — Wed, 11 Aug 2021 17:19:50 +0000

Note: This post is also available on my personal blog. If you prefer to read it there, please click here

Introduction

Welcome back to the "Currying - What's the point" series. Last time we looked at how currying can improve function composition. In today's post, we will be looking at a technique called partial application, which is closely related to curried functions.

Partial application is where we pass only some of a function's arguments to the function and in return we get back a function taking the rest of the remaining arguments. For more details on the basics of partial application, take a look at this post. As I did in the previous post, rather than focusing on explaining what the technique is, I will instead be focusing on code examples which showcase how partial application is beneficial to real world applications.

We're going to look at two examples. Firstly, we'll explore a "classical" use-case for partial application which is for dependency injection. Next, we'll take a look at an example of how partial application can be used to handle user permissions.

Dependency Injection

Most developers are familiar with the concept of dependency injection (DI). Usually, big frameworks with built-in dependency injection containers come to mind when we hear the words "dependency injection", but the concept is actually very simple and doesn't require any of this more advanced machinery to work.

In OOP, DI is generally achieved by accepting arguments in the contructor. For example, we may have a Car class which accepts an instance of ILogger:

class Car {
  private logger: ILogger;

  constructor(logger: ILogger) {
    this.logger = logger;
  }

  honkHorn(): void {
    this.logger.log("HONK HONK!");
  }
}

const logger = { log: console.log }

const car = new Car(logger);
car.honkHorn();

In functional programming, DI is simply achieved by passing arguments to functions! Here's the same honkHorn function written without a class:

const honkHorn = (logger: ILogger) => () =>
  logger.log("HONK HONK!");

const logger = { log: console.log };
honkHorn(logger)();

In both paradigms, the benefits of using DI are the same:

It makes our code more maintainable as we can focus on a single responsibility.
It keeps the code loosely coupled to other parts of the codebase as our code doesn't depend on anything directly. It only depends on an interface.
It helps to keep our code unit testable by making it easy to mock dependencies.

Now that we've gotten the basics out of the way, let's look at a common example that we encounter in web applications. In most web applications, a lot of our work results in an interaction with a database. Since most applications deal with users, we can take a look at how we can use partial application to our advantage when we need to update a user's email.

We have some core logic we want to enforce:

The email must be of a valid format
After the email is saved, we must log details about the fact that a user changed their email

Let's define a function updateUserEmail which encapsulates this core logic:

export type User = {
  id: number,
  email: string
}

export type ILogger = {
  info: (msg: string) => void
}

export type IUserRepository = {
  fetchUser: (userId: number) => Promise<User>,
  saveUserChanges: (user: User) => Promise<void>
};


type Dependencies = {
  logger: ILogger,
  userRepository: IUserRepository
}

// Very basic implementation, just for illustration
const checkEmailFormat = (email: string): void => {
  if (!email.includes("@")) {
    throw new Error("Not a valid email");
  }
};

export const updateUserEmail = (
  dependencies: Dependencies
) => async (userId: number, newEmail: string): Promise<void> => {
  const { logger, userRepository } = dependencies;

  checkEmailFormat(newEmail);
  const user = await userRepository.fetchUser(userId);
  const updatedUser = { ...user, email: newEmail };
  await userRepository.saveUserChanges(updatedUser);
  logger.info(`Email updated for user with ID ${user.id}`);
}

Since our updateUserEmail function is curried and accepts the dependencies argument first, we can easily partially apply it to get back a function which has the dependencies "baked in". We can then pass this new function to the various places that require it in our app, such as in an Express request handler.

import express from "express";
import {
  ILogger,
  IUserRepository,
  updateUserEmail,
  User
} from "./updateUserEmail";

// Simple logger which logs to the console
const logger: ILogger = {
  info: console.log
};

// A few mock users
const users: Record<string, User> = {
  1: { id: 1, email: "test@example.com" },
  2: { id: 2, email: "test@example.co.uk" }
};

// Simple in-memory implementation for IUserRepository
const userRepository: IUserRepository = {
  fetchUser: async (userId) => {
    const user = users[userId];
    if (!user) {
      throw new Error("User not found");
    }
    return user
  },
  saveUserChanges: async user => {
    users[user.id] = user;
  }
};

// We partially apply updateUserEmail, getting back a function
// with the dependencies baked in
const updateUserEmailWithDeps = updateUserEmail({
  logger,
  userRepository
});

// Now we can use our function where it's needed without
// needing to worry about the dependencies.
// Here's an example of it being used in an express handler
const app = express();
app.use(express.json());
app.use(express.urlencoded({ extended: true }));

app.post("/users/:id/email", async (req, res) => {
  const email: string = req.body.email;
  const userId: number = parseInt(req.params.id);

  // In a real app we would need to add some error-handling
  // to this :)
  const updatedUser = await updateUserEmailWithDeps(userId, email);

  res.status(200).send(updatedUser);
});

app.listen(8080, () => {
  console.log("App listening on port 8080");
})

There are a few clear benefits here.

Our express request handler code is able to purely focus on handling the wiring between our core logic and HTTP requests and responses.
Our core logic can easily be reused in multiple places.
As mentioned earlier, our core logic is blissfully ignorant of things like HTTP requests and even databases, making it easy to maintain. Click here to see example unit tests for updateUserEmail.

User permissions with partial application

One interesting usage of partial application is for handling user permissions. Let's imagine a system which has two user types: 1. a customer 2. an admin.

Let's extend our user type from earlier to look like this:

type User = {
  id: number,
  email: string,
  type: "customer" | "admin"
}

We can continue thinking about the case where we need to update a user's email, but let's forget about the dependency injection for now. Let's also curry the function some more so that all the arguments can be passed one at a time. The reason for this will become clear as we go through the example.

declare const updateUserEmail: (
  userId: number
) => (email: string) => Promise<User>

Here are the security rules we want to enforce:

An admin is allowed to update any users's account.
A customer can only update their own account.

We can use partial application to our advantage to enforce these rules.

type User = {
  id: number,
  email: string,
  type: "customer" | "admin"
};

// Create separate AdminUser and CustomerUser types
type AdminUser = User & { type: "admin" };
type CustomerUser = User & { type: "customer" };

type CustomerActions = {
  updateUserEmail: (email: string) => Promise<User>
};

type AdminActions = {
  updateUserEmail: (
    userId: number
  ) => (email: string) => Promise<User>
};

// Overloaded function which had a different return type
// based on the type of user passed in.
function getPermittedActions(user: CustomerUser): CustomerActions;
function getPermittedActions(user: AdminUser): AdminActions;
function getPermittedActions(
  user: User
): CustomerActions | AdminActions {
  switch (user.type) {
    case "customer":
      return {
        // Using partial application, we "bake" in the customer's
        // user ID into the `updateUserEmail` function.
        updateUserEmail: updateUserEmail(user.id)
      };

    case "admin":
      return {
        updateUserEmail
      };
  }
}

declare const admin: AdminUser;
const permittedAdminActions = getPermittedActions(admin);

// Admin can update the email on any account, as we wanted
permittedAdminActions.updateUserEmail(1234)("new-email@test.com");

declare const customer: CustomerUser;
const permittedCustomerActions = getPermittedActions(customer);

// Customer doesn't even have the option of passing a customer ID.
// Their own ID is "baked" in to the function, which prevents any
// security concern.
permittedCustomerActions.updateUserEmail("new-email@test.com");

// The type system prevents us from trying to pass a customer ID
// in the same we did for the admin user:
permittedCustomerActions
  .updateUserEmail(1234)("new-email@test.com"); // Type error!

As you can see, with the use of partial application we can bake in arguments to our functions to aid us in enforcing user permission rules. Having a strict compiler which can help you enforce these rules with static types such as Typescript is also a great help in these scenarios.

Conclusion

Partial application is a simple technique with a wide range of use-cases, the only limit is your creativity and imagination. In this post I have shown a couple of interesting examples which hopefully demonstrate why you may wish to use this technique in your applications moving forwards.

As always, I look forward to your questions, comments and feedback!

Currying, Part 1 - Function Composition

Christos Dimitroulas — Mon, 02 Aug 2021 21:41:52 +0000

Note: This post is also available on my personal blog. If you prefer to read it there, please click here

Introduction

Currying is a well known functional programming (FP) technique, often baked into FP languages like Haskell by default. When we say a function is curried, what we mean is that the function has been transformed from taking multiple arguments into a series of functions which each take a single argument. Imagine a function with 3 arguments f(a, b, c). The curried version of that function would instead be called like so: f(a)(b)(c).

The most common question that is asked after learning about currying is "What's the point?". The purpose of this series will be to look at some examples which illustrate the benefits of currying in real world applications. All code shown in the posts is written in Typescript and will also be available in this repository.

If you're looking for a more detailed explanation of what currying is and how to use it, please take a look at the chapter on currying in Mr. Frisbee's Mostly Adequate Guide to Functional Programming or this video on the FunFunFunction channel.

Function Composition

In functional programming, a lot of our time is spent composing smaller functions together into larger functions, also known as pipelines of functions. If we can find ways to compose our various functions together more easily, this could bring significant benefits to the way our programs are structured.

Let's imagine we are working on a web application which lets users review video games they have played.

Reviews have a couple of validation and sanitization rules to keep the data consistent and safe:

Reviews cannot be longer than 5000 characters
Reviews can only contain certain html tags, additional tags will be stripped.

Additionally, due to a pervasive toxic culture in many gaming circles, the company has decided they will add some rules on what is allowed in reviews:

Swear words will be replaced by a cat emoji.
No more than one exclamation point in a row. Reduce multiple exclamation points to a single character e.g. "!!!!" becomes "!"

Here are some functions and utils which will help us meet those requirements, written without currying:

const checkStringLength = (
  length: number,
  str: string
): string => {
  if (str.length < length) {
    return str
  }

  throw new Error(`String longer than max length (${length})`);
};

// implementation omitted for brevity
declare const stripHtml:  (
  allowedTags: string[],
  html: string
) => string 

const allowableHtmlTags = ["p", "h1", "h2", "a"];

// no, I'm not really gonna list the swear words here
const swearWords = ["poop"];

const catEmoji = "🐈";

const replaceWordWithCat = (str: string, word: string): string =>
  str.replace(new RegExp(word, 'g'), catEmoji)

// Matches all instances where there are 2 or more "!" characters in a row
const multipleExclamationMarks = /\!{2,}/g;

We want to define a function handleReview which combines all of the above. Here is a simple implementation.

const handleReview = (review: string) => {
  const correctLenReview = checkStringLength(5000, review);

  const strippedHtmlReview = stripHtml(
    allowableHtmlTags,
    correctLenReview
  );

  const noSwearWordsReview = swearWords.reduce(
    replaceWordWithCat,
    strippedHtmlReview
  );

  const noMultiExclamationMarksReview = noSwearWordsReview.replace(
    multipleExclamationMarks,
    "!"
  );

  return noMultiExclamationMarksReview;
}

/**
 * Example usage
 */
handleReview("<p>hello</p><script>window.alert('You\'ve been hacked!')</script>");
// --> "<p>hello</p>"

handleReview("The devs who made this game are poop!!!");
// --> "The devs who made this game are 🐈!"

handleReview(new Array(5000 + 1).join("a"));
// --> Error: String longer than max length (5000)

This works, but there are several issues with this implementation:

It is difficult to scan through it and gain a quick understanding of the business rules.
We needed to define intermediate variables (e.g. noSwearWordsReview and noMultiExclamationMarksReview) at each step which required coming up with clear variable names.
There is the potential to make a mistake and pass the wrong variable to a function. You could even accidentally return the wrong variable, such as correctLenReview instead of noMultiExclamationMarksReview!

We have used all of our smaller functions within handleReview, but wiring them up together is done in a very explicit and manual way. Function composition doesn't need to be so tedious! Let's try composing our functions using a utility like pipe/flow to simplify the process.

Note: flow is a function which allows us to compose multiple functions into a pipeline. Each function is ran in order, passing it's output onto the next function in the pipeline. The implementation I use the most is defined as flow in the fp-ts library. I don't recommend using pipe/flow from lodash as it is not type-safe at all and can easily introduce bugs into your program.

const handleReview = flow(
  (review: string) => checkStringLength(5000, review),
  correctLenReview => stripHtml(allowableHtmlTags, correctLenReview),
  correctLenAndStrippedReview => swearWords.reduce(
    replaceWordWithCat,
    correctLenAndStrippedReview
  ),
  nonSwearingReview =>
    nonSwearingReview.replace(multipleExclamationMarks, "!")
);

The use of flow eliminates the potential for mistakes, so we have made some improvement to our implementation. It is no longer possible to accidentally return review directly, or to pass the wrong argument to one of our functions. However, we still have the issues with legibility and intermediate variables that the original implementation had.

If only we had a way to compose our functions in a better way, we could eliminate the remaining problems with the implementation. It almost feels like we have a bunch of puzzle pieces that don't quite fit together properly. Luckily, we are programmers... so we can just create new puzzle pieces that fit our needs!

Let's see what happens if we rewrite our original functions to be curried:

const checkStringLength = (
  length: number
) => (str: string): string => {
  if (str.length < length) {
    return str;
  }

  throw new Error(`String longer than max length (${length})`);
};

declare const stripHtml: (
  allowedTags: string[]
) => (html: string) => string;

// Curried version of String.replace
const replace = (
  searchValue: string | RegExp
) => (replacement: string) => (str: string): string =>
  str.replace(searchValue, replacement);

// Curried version of Array.reduce
const reduce = <Accum, T>(
  fn: (accum: Accum, x: T) => Accum
) => (list: Array<T>) => (initial: Accum) =>
  list.reduce(fn, initial);

With our new curried functions in hand, we can re-implement our handleReview function like so:

const handleReview = flow(
  checkStringLength(5000),
  stripHtml(allowableHtmlTags),
  reduce(replaceWordWithCat)(swearWords),
  replace(multipleExclamationMarks)("!"),
)

handleReview("<p>hello</p><script>window.alert('You\'ve been hacked!')</script>");
// --> "<p>hello</p>"

handleReview("The devs who made this game are poop!!!");
// --> "The devs who made this game are 🐈!"

handleReview(new Array(5000 + 1).join("a"));
// --> Error: String longer max length (5000)

Our handleReview function is now much easier to scan and understand at a glance. We have eliminated intermediate variables (reducing the mental effort to come up with good variable names) and didn't need to use any arrow functions to wire up function arguments correctly. Overall, the result is much better.

Conclusion

In this post we've taken a look at how currying can be used to improve function composition. By making it easier to compose our smaller functions into bigger ones, we gained several benefits:

Reduced mental load by removing the need to come up with names for intermediate variables
Improved the readability of our code, making it easier for future developers to understand the business logic of our domain
Eliminated an entire category of potential bugs by avoiding the task of manually composing our functions together

In the next post, we will look at a technique called partial application which is closely related to currying and how it can be used for handling user permissions.

As always, I look forward to your questions, comments and feedback!

A very simple JSON API in Haskell

Christos Dimitroulas — Mon, 11 Jan 2021 18:28:53 +0000

Note: This post is also available on my personal blog. If you prefer to read it there, please click here

The simplest Haskell JSON API tutorial

I was following along on this blog post by Felix Mulder and I found it quite challenging to grasp the main concepts as a newcomer to Haskell for a variety of reasons.

This is my attempt to recreate the JSON API from that blog post using a much more simplified approach which doesn't require as much Haskell knowledge to understand the code. I hope this is useful to others and I'm sure it will be a useful learning experience for myself!

Credit goes to Sean Hess for this blog post which also helped me along the way

Let's build an JSON API!

In this tutorial we're going to be building a very simple API with two endpoints:

Create a user POST /user, receive the new user ID (String) in the response
Delete a user DELETE /user/:userId

Getting started

This tutorial assumes that you will be using stack to build your Haskell project.

A package.yaml file you can copy to ensure you have the right dependencies and language extensions can be found here: https://github.com/cdimitroulas/simple-json-api-haskell/blob/main/package.yaml

All the code we write in this post can also be found at:
https://github.com/cdimitroulas/simple-json-api-haskell

Our domain types

Lets begin by defining some simple types for our domain and the necessary FromJSON instances for them.

-- User.hs
module User where

import Data.Aeson
import Data.Text
import GHC.Generics

data User = User
  { userId :: Text,
    userName :: Text
  }

-- Data type which describes the request which
-- will be received to create a user
data CreateUserRequest = CreateUserRequest
  { name :: Text,
    password :: Text
  }
  deriving (Generic)

-- We define a FromJSON instance for CreateUserRequest
-- because we will want to parse it from a HTTP request
-- body (JSON).
instance FromJSON CreateUserRequest

Faking a database

To keep this tutorial simple and avoid us having to set up a database we will be using a mutable variable to store our users. Mutable variables in Haskell I hear you cry?! Is that even a thing?!

Well, it's probably not exactly what you are imagining if you are coming from another language where mutating variables is easily achievable but in Haskell IORef provides a way to mutate a variable, so we are going to use this! (This approach is obviously just for educational purposes and is in no way recommended for a real application :D)

-- Db.hs
module Db
  ( DbUsr (..),
    getUserStore,
    insertUser,
    deleteUser,
    mkDb,
    UserStore (..),
  )
where


import Data.IORef
import Data.List (sort)
import Data.Map (Map)
import qualified Data.Map as Map
import Data.Text (Text)

data DbUsr = DbUsr
  { dbUsrName :: Text,
    dbUsrPassword :: Text
  }
  deriving (Show)

newtype UserStore = UserStore {unUsrStore :: IORef (Map Int DbUsr)}

-- Creates our initial empty database
mkDb :: IO UserStore
mkDb = do
  ref <- newIORef (Map.empty :: Map Int DbUsr)
  pure $ UserStore ref

-- Accepts a default value to return in case the list is empty
safeLast :: a -> [a] -> a
safeLast x [] = x
safeLast _ (x : xs) = safeLast x xs

-- Utility to allow us to read the data in our "database"
getUserStore :: UserStore -> IO (Map Int DbUsr)
getUserStore (UserStore store) = readIORef store

-- VERY naive utility to get the next unique user ID
getNextId :: UserStore -> IO Int
getNextId x = (+ 1) . safeLast 0 . sort . Map.keys <$> getUserStore x

-- insertUser uses getNextId to get the next ID and then updates our database using
-- modifyIORef from the Data.IORef library. It returns the new ID as a result.
insertUser :: UserStore -> DbUsr -> IO Int
insertUser userStore usr = do
  nextId <- getNextId userStore
  modifyIORef (unUsrStore userStore) (Map.insert nextId usr)
  pure nextId

-- deleteUser updates our database by deleting the relevant user data 
deleteUser :: UserStore -> Int -> IO ()
deleteUser usrStore uid = modifyIORef' (unUsrStore usrStore) (Map.delete uid)

Putting together our JSON API

Now we have all of the pieces of our application that we need, it's time to put them together and expose them via a JSON API! In order to do this we will be using the scotty library (very similar to Sinatra from Ruby!).

-- Main.hs
module Main where

import Control.Monad.IO.Class
import qualified Db
import User (CreateUserRequest (..))
import Web.Scotty

main :: IO ()
main = do
  -- Initialize our fake DB
  db <- Db.mkDb

  -- Run the scotty web app on port 8080
  scotty 8080 $ do
    -- Listen for POST requests on the "/users" endpoint
    post "/users" $
      do
        -- parse the request body into our CreateUserRequest type
        createUserReq <- jsonData

        -- Create our new user.
        -- In order for this compile we need to use liftIO here to lift the IO from our
        -- createUser function. This is because the `post` function from scotty expects an
        -- ActionM action instead of an IO action
        newUserId <- liftIO $ createUser db createUserReq

        -- Return the user ID of the new user in the HTTP response
        json newUserId

    -- Listen for DELETE requests on the "/users/:userId" endpoint
    delete "/users/:userId" $ do
      -- Get the value of the userId from the URL
      userId <- param "userId"

      -- Delete the relevant user
      -- Same as with the user creation, we need to use liftIO here.
      liftIO $ Db.deleteUser db userId

-- Our createUser function simply deals with constructing a DbUsr value and passes it
-- to the Db.insertUser function
createUser :: Db.UserStore -> CreateUserRequest -> IO Int
createUser db CreateUserRequest {name = uname, password = pwd} = Db.insertUser db dbusr
  where
    dbusr = Db.DbUsr {Db.dbUsrName = uname, Db.dbUsrPassword = pwd}

Conclusion

We now have our completed JSON API! We can run it using stack run.

You should see this output:

Setting phasers to stun... (port 8080) (ctrl-c to quit)

We can then make some http requests to check it's all working. I like to use the httpie command line tool for this:

Writing a type-safe prop function in Typescript

Christos Dimitroulas — Sat, 16 Mar 2019 12:54:46 +0000

Note: This post is also available on my personal blog. If you prefer to read it there, please click here

In this post I will be going through how to write a type safe function which takes a path and an object and returns the value at that path. This is similar to lodash's "get" function except that we will make it obey much stricter rules!

The requirements for the function:

throws a compiler error when accessing an object property that doesn't exist
correctly infers the return type
Is a curried function with the arguments flipped (because I'm a functional kinda guy)

Now, you may ask yourself why would I not just use one of the many already existing "get" or "prop" functions provided by libraries like Lodash and Ramda?

The reason is that depending on how strict you want to be with your types, the implementation provided by those libraries may not be sufficient for your needs. Let's have a closer look at the behaviour of Lodash's get function to see why limitations it doesn't satisfy our requirement.

Firstly, lodash.get does a decent job of inferring the return type when the path we look for exists in the object.

import _ from "lodash";

type MyObject = {
  what: boolean;
  am: string;
  i: number;
  doing: { value: string };
};

const myObject: MyObject = {
  what: true,
  am: 'hi',
  i: 0,
  doing: { value: 'x' }
};

const what = _.get(myObject, "what"); // what: boolean
const am = _.get(myObject, "am"); // am: string
const i = _.get(myObject, "i"); // i: number
const doing = _.get(myObject, "doing"); // doing: { value: string }

However, Lodash as a library generally allows you to pass any types to it's functions without throwing errors most of the time. In a JS application, this can be handy as you can be sure to avoid TypeError's, but as we are using Typescript we should be able to use the compiler to achieve the same thing instead. Next, let's look at what happens if we try to access a path which doesn't exist in the
object or we pass in values which are not objects:

import _ from "lodash"

type AnotherObject = {
  something: boolean
}

const anotherObject: AnotherObject = {
  something: true
}

// try to get "value" which doesn't exist in anotherObject
const value = _.get(anotherObject, "value") // value: any

// try passing in undefined as the object
const x = _.get(undefined, "value") // x: undefined

// try passing in a number as the object
const y = _.get(0, "value") // y: any

As we can see, the type inference in these cases is not good. In the first case Lodash doesn't even manage to infer that the value variable will be undefined. In the final case where we pass in a number, the result is inferred as "any" although it should be undefined here as well. Furthermore, in our stricter prop function we would like to see a compiler error for all of these last three cases.

Now that we've seen what the limitations of Lodash's get function are, let's try writing our own prop function to satisfy our needs.

From our original requirements we know we need a curried function which first takes a path which is a string, then an object and returns the value at that path in the object.

Naive attempt:

// This naive first attempt isn't descriptive enough of the object argument
// type or our return type. This results in poor type inference when
// using the function. 
const prop = (path: string) => (obj: Record<string, any>) => obj[path]

const x = prop('value')({ value: true }) // x: any

The compiler needs more information about the return type in order to infer it correctly. Let's try and improve what we have using generics.

// We are now telling the compiler that the return value is O[P] where O is our
// object and P is our path.
const prop = <P extends string>(path: P) =>
  <O extends Record<string, any>>(obj: O): O[P] =>
  obj[path]

const x = prop('value')({ value: true }) // x: boolean
const y = prop('value')({ anotherProperty: 'string', property: 0 }) // y: number

Great! Our return type is being inferred correctly now. However, what happens if we try to access a path which doesn't exist in the object?

const x = prop('non-existant-property')({ value: true }) // x: unknown

The compiler tells us that the return type is unknown, which is not what we want. We know what keys properties our object has so we should be able to make the compiler understand that the key non-existant-property does not exist in an object like { value: true }. The problem is that the type of the object argument in our prop function is not descriptive enough.

In order to improve this we can use the in operator which lets us map a set of types to a new set of types (for more information on type mapping: https://www.typescriptlang.org/docs/handbook/advanced-types.html#mapped-types).
We can use this to take the value of our path argument and specify that this value must exist in our object.

// { [p in P]: V } specifies an object which must have a key of value p and that this
// key must pair with a value of V.
// Then, we say that our function returns this value V.
const prop = <P extends string>(path: P) => <V>(obj: { [p in P]: V }): V => obj[path]

const x = prop('value')({ value: true }) // x: boolean

// Now we correctly get the following compiler error for the below statement:
//   'value' does not exist in type '{ "non-existant-property": {}; }'.
const y = prop('non-existant-property')({ value: true })

// However, we have introduced a new problem.
// The following throws a compiler error:
//   'something' does not exist in type '{ value: boolean; }'.
const z = prop('value')({ something: 0, value: true })

We succeeded in adding the restriction that our object must have a key which is
equal to the path argument. However, our type is now too restrictive and doesn't
allow any additional properties on the object. We can fix this by telling the compiler that the object can also have any other keys and values.

// we add "{ [key: string]: any }" to our object's type to specify that it can
// include any other properties
const prop = <P extends string>(path: P) =>
  <V>(obj: { [p in P]: V } & { [key: string]: any }): V =>
  obj[path];

// Hooray! This now compiles correctly
const z = prop("value")({ something: 0, value: true }); // z: boolean

Let's review our function requirements to see whether we have satisfied them:

throws a compiler error when accessing an object property that doesn't exist

Yes, if we pass a path argument which doesn't exist in our object we get a compiler error.
correctly infers the return type

Yes, our return type is inferred correctly.
Is a curried function with the arguments flipped

Yes, our first argument is the path and the function is curried so the arguments can be partially applied, allowing for better functional composition.

Great, our function satisfies all our requirements and we now have a prop function which is type-safe and can be used throughout our application nicely!