Join the DZone community and get the full member experience.Join For Free
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.
Let’s start with a very small implementation of a Lens:
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:
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:
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.
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)
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.
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.
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:
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:
So far, we have been fiddling with very specific entities. Let’s abstract from those specific types to start using generic ones:
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.
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
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.
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:
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:
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
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.
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.
- 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.
Published at DZone with permission of Oscar Galindo. See the original article here.
Opinions expressed by DZone contributors are their own.