DEV Community: Glib Zaycev

Never call the same function twice (with memoization)

Glib Zaycev — Tue, 30 Jul 2024 14:50:09 +0000

So I've just discovered this interesting little concept of memoization.

I've started reading the article about it and stopped as soon as I caught the tail of the idea.

Then I decided to figure out the simple solution in my own and in the way I understand it.

If you've never hear of it, memoization is the process of storing the results of function execution, so you can pull it from a little (or not so) cache next time you run that function with the same arguments.

In reality this can be useful for a high resources consuming function. It comes with cost of using extra space as a cache. But it can improve the speed of your code and the experience of the users who use it.

I've played with JS code a bit and came with this solution:

const memoize = fn => {
  const cache = {}
  return (...args) => {
    const fnKey = `${fn.name}(${args})`;
    if(!cache[fnKey]) {
      cache[fnKey] = fn(...args);
    }

    return cache[fnKey]
  };
}

Then you can run it like that:

function _add(x, y) {
  console.log("function runs", x, y);
  return x + y;
}

const add = memoize(_add)

add(42, 69)
add(10, 15)
add(10, 15)

That leads to the execution of function twice (#1 and #2 'add' calls). Third 'add' call will use cache as it's the same as #2 call.

'function runs' 42 69
'function runs' 10 15

You can see that 'function runs' 10 15 is only called once. This is because the second time we call it, the cache is being used.

Now let's quickly break down what's going on here.

In this example we utilize closure mechanism to store the cache.

const memoize = fn => {
  const cache = {}
  return () => {

  };
}

This allows us to throw the "fn" argument, which is the king of the party as this is exactly the function we want to operate with, down the scopes and "listen" to each of its execution.

I really have written it in the most simplistic, naive way. So we are going to use function name with arguments as keys of the cache, and the results of its execution as values.

That means, that executing:

add(2, 2)

Results in

// Our cache
{
  'add(2, 2)': 4
}

Cache value.

I know that this is possibly not exactly how it should be done "the right way". But the idea of this exercise and the article isn't about the well tested safe and edge cases free solution.

It's about the learning and simple implementation. About the concept. So I'm not focusing on details of implementation right now.

Now, we first figure out the key for the function call:

const memoize = fn => {
  const cache = {}
  return (...args) => {
    const fnKey = `${fn.name}(${args})`;
  };
}

We will use it to store results of the function execution in the cache.

Then we check if this key (fnKey) already exists. If not, we set the key with its value as a result of the passed function execution.

In the end we always return the result from the cache. So really the execution of the function passed to memoize method always ends in the closure (in the "cache" object).

We only operate with this object now:

const memoize = fn => {
  const cache = {}
  return (...args) => {
    const fnKey = `${fn.name}(${args})`;
    if(!cache[fnKey]) {
      cache[fnKey] = fn(...args);
    }

    return cache[fnKey]
  };
}

And that's it.

Now I'm gonna go and look how it should be done "properly". But if you find this interesting, let me know. If something is unclear or wrong with this approach (for your taste), just drop the comment and let's talk about it.

Thanks, see you!

How to create simple Angular signal() in JS

Glib Zaycev — Wed, 02 Aug 2023 10:06:43 +0000

Hey there!

So recently I was playing with Angular signals and noticed that I didn't really understand how exactly this language construction works:

public counter = signal(0);

// Then you use it like that in the template.

{{ counter() }}

// But also work with it like that:

counter.update((count) => count + 1)

Although I've been working with JS for years, for some reason I'd never seen such a way to use functions before until I tried signals.

This is pretty basic JS functionality, and I will show you in super simple example how exactly it works.

You'll learn

What JS functions really are
How angular signals are implemented

JS Functions

So a quick note: functions in JS are not exactly functions; they are function-objects. Functions are objects with internal, hidden [[Call]] and [[Contruct]] methods, and they basically make an object a function.

But it is still an object, and this is exactly how we can achieve the functionality that we have in signals.

I think it's a rather interesting feature of the language. But I am generally ok with any weirdness (that JS supplies in huge volumes), so you can draw your own conclusions.

Implementing signal

We are not going to dive deep into how exactly angular signals are really implemented, but we'll create very simple, basic functionality for them. First, we just create a function:

function signal(value) {

}

To make it look exactly like an angular signal. As you remember, we put signal into a variable by calling it like that:

const counter = signal(0);

And after that, we can either call counter or update it. That means we, for first, should make the signal function return another function:

function signal(value) {
  function caller() {
    return value;
  }
  
  return caller;
}

I called it caller for whatever reason that popped up in my mind at the moment of writing that code. And now the final stroke: using the nature of JS function objects to make counter have mixed behavior:

function signal(value) {
  function caller() {
    return value;
  }
  
  caller.set = (newValue) => value = newValue;
  caller.update = (fn) => value = fn(value);
  
  return caller;
}

And here we are, utilizing the hybrid nature of JS functions.

You can see that we are clearly assigning properties to the caller function as if it were an object.

We've added set and update callbacks to the caller function. Now, when the signal is initialized, we always have the option to call those callbacks or the signal itself.

set method allows direct updating of the value.
update method lets us do the same but using a callback, passed as a parameter.

// getting the signal value
counter();

// updating signal value
counter.set(42);
// or
counter.update(c => c + 1);

Angular Signals is a very powerful and well-thought-out interface; it is much more complicated and flexible, than our implementation. But it still uses a similar approach because there is always a limiting factor in language possibilities.

However, now you know how to utilize the hybrid nature of JS functions in your everyday routine.

Hopefully you learned something new and it was helpful.

Thank you!

Colorizing console logs with JS Proxy. Part 1

Glib Zaycev — Thu, 20 Jul 2023 08:59:34 +0000

Hey there!

Today we're going to talk about two things modern society cannot imagine its life without:

console logs
Proxy objects

Well, maybe not that dramatic, but this will be a short introduction to the subject with examples of the code I used in my work for real clients. This whole thing is a QoL feature; it's not about performance or optimal code, but it for sure made my life better during my work.

What you'll learn:

How to style console logs
What the JS Proxy class is
How to apply it to logging to create better outputs

Let's go!

Imagine you have a lot of logs. Like a lot. And you hate your life for the mess they create at your favorite browser console.

You want to distinguish them. To highlight test messages with green and system messages with blue, maybe you have state machines that log out their state (and you want them to be different from the other logs).

Well, the first thing you think of is styling the console logs.

Now it's better. We can go further and incapsulate it in the method to hide the wires.

export const systemLog = (msg) =>
  console.log(
    `%с ${msg}`, 
    `background: blue; color: white;`
  );

But what if we need different styles for different messages? Well, we can create a generic method and a number of useful methods:

const log = 
  (msg, styles = ``) => console.log(`%c ${msg}`, styles);

const logSystem = (...args) =>
  log(args, `background: blue; color: white;`);
const logWarning = (...args) =>
  log(args, `background: orange; color: black;`);

Now we can use it like that:

It's already pretty useful as it is; we can specify 10–20 of those methods and use them around the app. It's not too elegant, but it's working and pretty clear.

However, we're going to do something much cooler and more flexible. Something to use any color and not care about background or text color combinations. For that, we need a proxy object.

Proxy

Before I explain the use case of proxies for our case, here's a brief explanation of what a proxy is in JS:

Proxy is a class that wraps around any object in JS and lets us intercept any calls made to that object.

It is used just as a usual object, but the difference is that it allows us to handle calls to any property of that object, modify it, or add any side effects.

Here's a quick example: let's create a simple object that will be the base for our proxy.

const everySringfieldCitizen = {
  callsHim: "Flanders",
};

And after that, immediately wrap it with a fresh Proxy:

const homer = new Proxy (averageSringfieldCitizen, {
  get: (target, prop, receiver) => {
    return `Stupid sexy ${target[prop]}`;
  }
});

Now that's what we have when we call the original object and the proxy made using it:

What is going on here?

Proxy is a class that receives two objects in its constructor:

The base object, which basically can be whatever object, even just

{}

fits

handler that works as a configuration for our proxy. It has a set of methods predefined by JS called "traps".

We are not going to dive deep into traps and focus only on get one that will serve all our needs.

Now, the get trap is being called whenever you call any property, even an existing one, on the proxy object. It works as a callback that receives three arguments:

target: the object we used as the first argument in Proxy, the base object
property: the name of the called property is whatever is typed after the period (in my example, it is calls him").
receiver: the object of the proxy itself

Let's have another example with more generic data:

const quiz = {
  question: "How much is the fish?",
  answer: "Very much",
};

const handler = {
  get: (target, prop, receiver) => {
    return `42`;
  },
};

const proxiedQuiz = new Proxy(quiz, handler);

Now let's call the properties:

As you see, now any call of the proxy object always returns the same data.

We can clearly do whatever we want with object calls on proxies. Even assign or reassign keys and values to the object. We will use this knowledge to create dynamically set, colorful logging.

Using a proxy in the real world

We've learned a lot about proxies and are ready to apply this knowledge to create a useful, minimalistic tool for better logging.

For now, we're going to focus on the background color for our logs. We'll leave text as white by default, but in the next article, I'm going to show how you can automate picking up a contrast color for any background.

The core idea of dynamic color logging is to set the background with a property name. So this is the goal:

Each background is picked up dynamically.

We'll define base object as an empty object for now:

const baseObject = {};

And this will be our handler:

const handler = {
  get: (target, prop, receiver) => {
    if (!(prop in target)) {
      target[prop] = (...args) =>
        console.log(
          `%c${args}`,
          `background: ${prop}; color: white;`
        );
    }

    return target[prop];
  },
};

Finally, we're going to create a proxy just like we did before:

const log = new Proxy(baseObject, handler);

It's ready now, but let's take a closer look:

When any property is called on the proxy object, we check if it exists on that object.
If it is, we just return whatever is stored in there (it is implied to be another instance of our logging callback with a different background color).
If it doesn't exist in the target object, we're going to create a new key-vvalue pair, where the key is the requested property name and the value is the callback with the console log.
After that, we just return that callback with target[prop].

And immediately call this callback with any arguments like that:

log.red("Apple");

Now we're going to see:

Let's take a closer look at our proxy:

Before any interactions with the proxy, we had zero properties in it, and that was just a simple empty object. Now we've added a "red" property that has a callback as a value.

We are also using property name as the name of the CSS color for the console log background. So technically, this will work:

Be careful with this; it can be dangerously beautiful.

Now you can see how it works. We start with an empty object, but we keep accumulating callbacks.

There are several questions that you could raise after all this:

Why add a property at all?

Why can't we just use color from properties to use it in the console log?

How does it work with non-primitives like arrays and objects? (Hint: it does not work well, but that's a case to handle.)

What's up with picking the right text color to not have a white-on-white situation?

All these are pretty valid points, and just to not make the article too long and boring, I am leaving them for the next parts.

In the second part, we'll work on points 1–3 from the list above and refactor what we already have (because there is always room for improvement, right?)

In the final, third part, we'll implement the functionality for smartly picking colors for the background and mess with CSS a bit.

And now lets recap what we've learnt today:

Console logs could be styled with simple rule (%c in the start of the log text)
What is JS Proxy
How Proxy can be used in practive for everyday needs

Thanks for reading; hopefully that was helpful and see you soon in part 2!

Best way to clean JS objects from empty values

Glib Zaycev — Wed, 19 Jul 2023 15:21:47 +0000

Hi there! This is my first try at posting something meaningful and related to the everyday developer experience. I hope you'll like it, and thanks for reading!

Recently, I faced the issue when I had to clean the json object from the empty fields. This is a pretty common case and can be found in various places, like formatting API responses, preparing API requests, and working with reusable forms.

So I created the method to format such objects and then wondered what is the best way to do it was. Let's look at the example. I have a simple user object, but I really don't need all the information about him.

const person = {
  id: "",
  name: "Glib",
  age: 30,
  group: "",
};

That was the initial implementation of the method to clean this object.

const removeEmptyValues = (object) =>
  Object.fromEntries(
    Object.entries(object)
      .filter(([_, value]) => value)
  )

Totally works.
What I love about it is that it is a one-liner.
What I hate about it is that it is, eh, a one-liner. Which implies it doesn't have all the checks and maybe even doesn't have the best performance (not necessarily, but probably). Spolier: It really is not good.

The main problem here is not even the performance, but the fact that it will fail with the first not object passed to it as an argument.

So this was the better version:

const removeEmptyValues = (object) =>
typeof (!!object &&
          object === "object" && 
          !Array.isArray(object))
    ? Object.fromEntries(
        Object.entries(object)
          .filter(([_, value]) => value)
        )
    : object;

And even though it's still a one-liner, the way this code looks make me wanna leave coding for working at slaughterhouse. Primarily not because of the ternary but because of, well, all things together.

Now it's much better functionally, though. It's going to make a check and extract the object to clean it up if it's truly an object, and just return a passed value if it's something else.

It could throw the error to make it more informative, but let's keep this talk at the current level of abstraction. Let's just pretend it's okay as it is, and if you want, you can add your error handling the way you like it.

I ended up separating logic a bit, making this method dirtier by nature but much cleaner for the reader, and just extracting the check and the actual logic into their own little methods isolated in the scope of the file that's going to store all 3 methods:

const isObject = (object) =>
  typeof !!object && object === "object" && !Array.isArray(object));

const cleanObject = (object) =>
  Object.fromEntries(
    Object.entries(object)
      .filter(([_, value]) => value)
    );

export const removeEmptyValues = (object) =>
  isObject(object) ? cleanObject(object): object;

Now I actually quite like it. It's readable, responsibilities are separated and extracted, and it looks like most possible failure cases are resolved.

However...

It's slow. Simple as that, just looking at this chain of calls to Object.entries() and Object.fromEntries() makes me want to throw the monitor out of the window.

So I've decided to make a simple experiment with performance and created two more methods with the same functionality but different logic. Here we go:

const removeEmptyValuesForLoop = (object) => {
  if (!isObject(object)) returns;

  for (let key in object) {
    if (!object[key]) delete object[key];
  }
  return object;
};

const removeEmptyObjectsByKeys = (object) => {
  if (!isObject(object)) returns;

  let newObject = {};
  Object.keys(object).forEach((key) => {
    if (object[key]) {
      newObject[key] = object[key];
    }
  });
  return object;
};

Leaving aside the initial type check, you can clearly see the approaches:

In the first one, we just go through the object in a for loop and delete the properties that are empty.
In the second one, we are building the new object from scratch.

To be honest, I kind of hate the idea of the last one, and I thought it would have the worst performance with big objects. However, I was a bit surprised when I ran performance tests.

For it, I created a little helper function that just iterates through the same function again and again for N times:

const measure = (fn, times) => {
  const start = performance.now();
  for (let i = 0; i < times; i++) {
    fn();
  }
  const finish = performance.now();
  return (finish-start).toFixed(2);
};

And ran it for 1 000 000 times for each of 3 methods:

As we thought, formatting objects with the Object class methods was the slowest one.

Going through the loop was much faster.
And building a new object from the old one showed the best performance!

I've tried to increase the number of fields in the object, but in a reasonably larger range, it kept its best performance even with hundreads of fields.

That was a pretty interesting little experiment with raw JS to understand the best way to clean objects from empty values.

As for me, I'll still probably prefer the #1 solution even though it's slower, because in my use cases I only need to run it once for a long time, and after all the refactoring, it looks readable and neat.

However, if you need to process big chunks of data, you definitely should choose a lower-level approach, the delete operator, or build the object from scratch.

Thanks for reading this far; hopefully it was helpful!

I'd love to hear any feedback!