Functional Lenses in JavaScript

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 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 the functional Lenses, when you see this you will 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:

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 what we are looking for is to generate a new whole with the new part that we have passed to it. It’s basically the get/set functions we’re badly used to, right? Let’s continue creating our Getter / Setter implementations and see their use:

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, it 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.

Lens Laws

There are Lenses laws and they are easy to understand. I will try to explain them in a simpler 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)

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.

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.

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 y Over

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

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 lens in a much simpler way.
The implementations, as you can imagine, are quite simple. It is simply to call the functions of the lens with the data that they touch:

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:

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)));

Changing User and String for generics such as S and A, we already have 3 functions that apply in all contexts, consumers like it, no broken tests, we have 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 in particular:

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:

interface User {
   name: string;
   age: number
}
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 of 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 2 part of type C:

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:

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, to the name of the company of our contact. First we must create two Lens, one that focuses on the Company part of our Contact, and the one that focuses on the company name (string) of a Company:

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 that exists in this article, despite working, is not recommended to use in production, our software development team in Apiumhub uses a lot Ramda library although there are many other good ones such as Monocle-ts (Already mentioned at the beginning of the article).

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 domain but it is something that has to be well thought out.

The use case for Lens in domain is to create getters and setters, so we go into issues of bad design of our domain. We are breaking the encapsulation.

I would dare to say that using domain Lens is an anti-pattern even though I have not read it anywhere else since most of the explanations and talks you see are VERY technical, that don’t cover the business aspect and it generates some questions… In certain scenarios where they tell you to use Lens in domain, you see God Objects that obviously need help of all the possible technicalities to solve a bad design decision.

On the other hand, I see very interesting the use of Lens in frontier layers to our domain, all DTO input by HTTP, database, events, etc. The solution is very easy to understand and easy to test (and unnecessary, since Lens is strongly typed).

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.

Bibliography

• 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

If you are interested in Scala implicits or in software development in general, I highly recommend you to subscribe to our monthly newsletter!

If you found this article about Functional Lenses interesting, you might like…

Scala generics I: Scala type bounds

Scala generics II: covariance and contravariance

Scala Generics III: generalized type constraints

BDD: user interface testing

F-bound over a generic type in Scala

Microservices vs Monolithic architecture

“Almost-infinit” scalability