Functional JavaScript: Lenses

One of the most interesting talks among the ones I attended in lambda.world was Functional Lenses in JavaScript by FlavioCorpa. He talked about Functional Lenses in a practical way; what’s more, he started with his own small implementation (not for production), and then he talked about different libraries like Ramda or Monocle-TS.

The talk started with an easy-to-understand definition for those of us who are familiar with the procedural/imperative programming: “Lenses are basically functional getters and setters”. Basically, what we get with Lenses is the ability to reuse the data access of a structure in a modular and immutable way, either to obtain the data or to modify it. Later, we will see examples to better understand it.

Functional Lenses in JavaScript

Let’s start with a very small implementation of a Lens:

const Lens = (getter, setter) => {get: getter, set: setter};

Those who have not seen or do not know about functional Lenses might be asking: “and this can generate a talk of 1 hour?” We have to be aware that it is a concept of functional programming, so composition and immutability are very important concepts to consider when we use Lenses.

Continuing with our implementation, we will add types:

xxxxxxxxxx

type LensGetter<S,A> = (whole: S) => A;

type LensSetter<S,A> = (whole: S) => (part: A) => S;

interface Lens<S,A> {

    get: LensGetter<S,A>;

    set: LensSetter<S,A>;

}

const Lens = <S,A>(getter: LensGetter<S, A>, setter: LensSetter<S,A>) => ({get: getter, set: setter});

Now, we see how the getter is a simple function that receives an object (whole) and returns a piece of it (part). With the setter, we are looking to generate a new whole with the new part that we have passed to it. It’s basically the get/set functions we’re used to, right? Let’s continue creating our Getter/Setter implementations and see their use:

xxxxxxxxxx

interface User {

    name: String;

    company: String;

}

const user: User = {name: "Oscar", company: "Apiumhub"};

const getName = (whole: User): String => whole.name;

const setName = (whole: User) => (part: String): User => ({...whole, name: part});

const nameLens = Lens<User, String>(getName, setName);

expect(nameLens.get(user)).toBe("Oscar");

expect(nameLens.set(user)("Joaquin")).toEqual({name: "Joaquin", company: "Apiumhub"});

As we see in our test, the get of our lens passing a User gives us its name and using the set of our lens, passes it a new name and returns the complete object with the changed name.

Here, one can think that as we code the implementation, the get can point to one thing and the set can modify another. This would not make much sense, so let’s continue. Like everything in this life (and more in the world of mathematics/programming), there are laws. Laws that must be met in order to ensure the correct functioning of, in this case, a Lens.

You may also like: Functional Programming in JavaScript.

Lens Laws

There are Lenses laws, and they are easy to understand. I will try to explain them in a simple way; please note, that you can find some useful literature about it at the end of the article.

1. (set after get) If I update with what I receive, the object does not change. (Identity)

xxxxxxxxxx

expect(nameLens.set(user)(nameLens.get(user))).toEqual(user);

If this law is met, we should see that the set and get must focus on the same part of the object

2. (get after set) If I update and then receive, I should receive what I have updated.

xxxxxxxxxx

expect(nameLens.get(nameLens.set(user)("newName"))).toEqual("newName");

The first thing that will be executed is the set of our lens, which will return a new user with a new name. If we make the get of that new user, we should receive the new name.

3. (set after set) If I update twice, I get the updated object for the last time.

xxxxxxxxxx

expect(nameLens.set(nameLens.set(user)("newName"))("theNewName")).toEqual(nameLens.set(user)("theNewName"));

Look at the order; it executes first the internal, the user’s set with “newName.” With that object that returns to me, I change it again, but this time to “theNewName.” The last one is what we obtain. The expect reflects it.

View, Set, and Over

Now, we are going to implement three new functions: view, set, and over. These functions will be very simple, but they will help us work with Lenses:

xxxxxxxxxx

type LensView<S,A> = (lens: Lens<S, A>, whole: S) => A;

type LensSet<S,A> = (lens: Lens<S, A>, whole: S, part: A) => S;

type LensOver<S,A> = (lens: Lens<S, A>, map: Mapper<A, A>, whole: S) => S;

As you can see, the three types are quite simple and will help us to work with the lenses in a much simpler way. You call the functions of the lens with the data that they touch:

xxxxxxxxxx

type LensView<S,A> = (lens: Lens<S, A>, whole: S) => A;

type LensSet<S,A> = (lens: Lens<S, A>, whole: S, part: A) => S;

type LensOver<S,A> = (lens: Lens<S, A>, map: Mapper<A, A>, whole: S) => S;

So far, we have been fiddling with very specific entities. Let’s abstract from those specific types to start using generic ones:

xxxxxxxxxx

const view = <S, A>(lens: Lens<S, A>, obj: S) => lens.get(obj);

const set = <S, A>(lens: Lens<S, A>, obj: S, part: A) => lens.set(obj)(part);

const over = <S,A>(lens: Lens<S, A>, map: Mapper<A, A>, obj: S) => lens.set(obj)(map(lens.get(obj)));

By changing User and String for generics, such as S and A, we already have three functions that apply in all contexts. We only had to refactor the name of the function.

Now, we are going to generalize the part of the creation of the Lens together with its getters and setters.

xxxxxxxxxx

const prop = <S, A>(key: keyof S) => (whole: S): A => whole[key];

const assoc = <S, A>(key: keyof S) => (whole: S) => (part: A) => ({...whole, [key]: part});

const lensProp = <S, A>(key: keyof S) => Lens<S,A>(prop(key), assoc(key));

const nameLens = lensProp("name");

In our prop function, as a parameter we are passing a value of type: keyof S. This type is a union type of all the public properties of the object S. In the following example, it will fail to compile if we try to assign to userProps something other than name or age:

TypeScript

 

xxxxxxxxxx

1

 

1

interface User { 

2

   name: string; 

3

   age: number 

4

}

5

6

let userProps: keyof User; // 'name' | 'age'

As we can see, with a single call to a function indicating the part of the structure that we want to focus on it would be enough to have everything that we have explained in this article for now. So far so good.

Composition

And last but not least, we will work with the composition of Lenses. With the composition of Lenses, we will be able to reach the most profound data within our structure in a simpler way.

The first thing we will do is create a function that, given two Lenses, returns a composite Lens.
At the type-level, we could say, I have a Lens that speaks to type A as a data structure and B as a part of A, and I also have another Lens that knows B as a data structure and C as an internal part of it. Our function must return a Lens that knows A as a structure and lets us work with a level two part of type C:

xxxxxxxxxx

const compose = <A, B, C>(lens1: Lens<B, C>, lens2: Lens<A, B>): Lens<A, C> => ({

    get: (whole: A) => lens1.get(lens2.get(whole)),

    set: (whole: A) => (part: C) => lens2.set(whole)(lens1.set(lens2.get(whole))(part))

});

The code is simple, and only by looking at the signature of the method, we can understand exactly what it does. From here, we will start using a slightly more complex data structure:

xxxxxxxxxx

interface Company {

    name: string;

    location: string;

}

interface Contact {

    name: string;

    company: Company;

}

const contact: Contact = {

    name: "Oscar",

    company: {

        name: "Apiumhub",

        location: "Barcelona"

    }

};

As a first step, what we are going to do is access, by composing Lenses, the name of the company of our contact. First, we must create two Lenses — one that focuses on the Company part of our Contact, and the one that focuses on the company name (string) of a Company:

xxxxxxxxxx

const companyLens = lensProp<Contact, Company>("company");

const companyNameLens = lensProp<Company, string>("name");

const contactCompanyNameLens: Lens<Contact, string> = compose(companyNameLens, companyLens);

const locationLens = lensProp<Company, Location>("location");

const cityNameLens = lensProp<Location, string>("city");

const companyLocationLens: Lens<Contact, Location> = compose(locationLens, companyLens);

const locationCityNameLens: Lens<Contact, string> = compose(cityNameLens, companyLocationLens);

it('focus nested data', () => {

    expect(view(contactCompanyNameLens, contact)).toEqual("Apiumhub");

    expect(over(contactCompanyNameLens, toUpperCase, contact).company.name).toEqual("APIUMHUB")

});

it('composing composed lens', () => {

    expect(view(locationCityNameLens, contact)).toEqual("Barcelona");

    expect(over(locationCityNameLens, toUpperCase, contact).company.location.city).toEqual("BARCELONA")

});

Cool! We already have the ability to create Lenses, compose them, and work with them. That said, all the code in this article, despite working, is not recommended to use in production; our software development team in Apiumhub uses the Ramda library extensively although there are many other good libraries, such as Monocle-ts.

Where to Use a Lens

To finish, let’s talk about when is the right time to use Lenses and when NOT to use them.

I have read many articles and presentations where they talk about how to use them in a domain, but it is something that has to be well thought out.

The use case for a Lens is to create getters and setters, so we can get into issues of bad design of our domain if we end up breaking encapsulation.

I would dare to say that using domain Lenses is an anti-pattern. In certain scenarios, where they tell you to use Lenses in a domain, you see God Objects that need the help of all the possible technicalities to solve a bad design decision.

On the other hand, I see the use of Lenses in frontier layers to our domain — all DTO input by HTTP, database, events, etc.

Conclusion: Functional Lenses in JavaScript

As I mentioned above, there is a lot of literature that I used and here I leave it for you. Let me tell you that as you get deeper into the subject, you will enter a spiral of functional programming, mathematics in general and category theory in concrete (although abstract) that generates addiction.

References

• Lenses, Stores, and Yoneda.
• Category Theory: Lens by Bartosz.
• Functional Lenses.
• Lenses from scratch.
• Lenses Are Exactly the Coalgebras for the Store Comonad.
• Lenses, Folds, and Traversals.
  • Slides.

Further Reading

• Angular Developer: JavaScript to TypeScript.
• How to Define an Interface in TypeScript.