DEV Community: Ignacio Mattos

Good practices in ReactJs - State variables and attached logic

Ignacio Mattos — Mon, 19 Aug 2024 18:20:08 +0000

In ReactJs & React-Native we often find a bad use of components’ state. This is an issue that takes special relevance as applications scale up and get more complex (e.g. through the use of nested components) and it can end up in either a compromised performance (damaging the user’s experience), a harsh dev experience when it comes to maintain our code or even a buggy application plagued with unexpected behaviours.
When this happens it is also common for trivial problems to take more time to be fixed than they should or for particular solutions to trigger bugs at another corner of our app.

Today we will use a simple -but real- error scenario to show what a bad implementation of React Components' state can get us and how to make it work as expected. In this case we are using React Hooks for state management.

Particular situation

In one of our components, formed by a basic form and an attached logic that sends its data to an API, we detected an inconsistency between the inputted data and the one that our service was finally receiving.
It turned out to be an issue allocated within the logic attached to the component’s state changes. To be more specific, a state variable was being used to save the form values and its content was being sent inside a request immediately after its update (or the attempt to update its value, as we will see).

This is how React Components’ lifecycle was not being followed: when we update state variables React needs some time to re-render the whole component and its children (unless we tell it not to do so) with every change. That’s why we cannot make use of our state variables until this process is complete.

💡 Going a little further, bear in mind that when we instruct a state change in a component, React enqueues this update (along with any other that we might have requested), applies it in the Virtual DOM and finally (through a process called Reconciliation) transmits it to the DOM so we can see the update in our app. Definitely far more complex than just assigning a new value to a variable.
For more information about components state and re-renders, feel free to consult the docs!

Let me show our code at this point:

import { useState } from "react";
import TestApi from "services"

const MyComponent = (): ReactElement => {
  const [statefulData, setStatefulData] = useState<String>("");

  const handleClick = async (newData: String) => {
     // The problem here is that React needs some time to re-render our 
     // component everytime statefulData is updated (in this case through a 
     // hook). For this reason, statefulData is not updated by the time
     // we call TestApi.postData (its value will be `''`), so this       
     // handler needs a fix.
    setStatefulData(newData);
    await TestApi.postData(statefulData);
  }

  return (
    <button onClick={() => handleClick("New data")}>
      Click me!
    </button>
  )
}

Possible ways out

I believe that there are two paths to have a scenario like this one solved. The correct one depends on what you need to do with your state value once it gets an update.

1. Removing the state variable

If we are not after re-renders in our component every time the form receives any changes then there is no need for a state variable and we can directly consume our API using the form’s inner data.

import TestApi from "services"

const MyImprovedComponent = (): ReactElement => {
  const handleClick = async (newData: String) => {
    // If there is no need for a re-render (and therefore for a state 
    // variable), a possible solution is to avoid the use of the hook 
    // and simply use the value that we receive from params.
    await TestApi.postData(newData);
  }

  return (
    <button onClick={() => handleClick("New data")}>
      Click me!
    </button>
  )
}

2. Attaching logic to state changes

If we do want to re-render our component everytime our variable is updated (let’s say we want to show its content on screen) then we need a state variable and, what’s more, we need to add a useEffect hook that gets triggered when our variable is updated to handle this event.

import { useState } from "react";
import TestApi from "services"

const MyImprovedStatefulComponent = (): ReactElement => {
  const [statefulData, setStatefulData] = useState<String>("");

// If we need a state variable we have to attach our logic to its updates
// through the useEffect hook This way we will be consuming TestApi only
// when statefulData has been updated.

  useEffect(() => {
    // An extra validation here since this callback is not only
    // triggered when statefulData but also when mounting the component. 
    // For more information check the docs!
      if (!!statefulData) {
        await TestApi.postData(statefulData);
      }
  }, [statefulData])

  const handleClick = async (newData: String) => {
    setStatefulData(newData);
  }

  return (
    <button onClick={() => handleClick("New data")}>
      Click me!
      <div>{statefulData}</div>
    </button>
  )
}

Concluding remarks

The problem solved here was a consequence of bad components’ state management. As React lifecycle stages were not respected, our component experienced a lag between the data stored in its state and the expected result of an enqueued state update attached to the user’s interaction.

In conclusion, the use of good practices and the components’ adjustment to the official React documentation is crucial. Correct state management, components’ atomization after SRP (Single Responsibility Principle, centralizing logic after DRY (Don't Repeat Yourself) decoupling from external components and the achievement of a highly cohesive internal logic are practices that minimize problems' solving time, lower error rate and allow for stability and scalability in our applications.

Picture taken from the official React docs.

Tuning de conexiones en MongoDB con Serverless Lambda

Ignacio Mattos — Fri, 10 May 2024 11:55:12 +0000

Contexto

Luego de una etapa de gestión y mantenimiento manual de una base de datos MongoDB (nosql) instalada on premise, se tomó la decisión de comenzar a usar el servicio cloud Mongo Atlas. Esto se debió a que el mismo ofrece múltiples ventajas -de las cuales “replication” es la más destacable, ofreciendo la posibilidad de implementar la base de datos en un cluster de nodos de forma rápida y eficiente. También ofrece buenas herramientas para monitorear tanto la escalabilidad de la base de datos como los estados del cluster.

Problema

Al comenzar a utilizar Mongo Atlas, se observó que crecía exageradamente el número de conexiones concurrentes abiertas –alcanzando, por ejemplo, picos de 100 conexiones con un test de carga de solo 5 usuarios simultáneos. Esto derivó en dos escenarios de error:

Escenario en el que el backend (AWS Lambda) terminaba requests por timeout debido a problemas de conexión.
Caída de la base de datos en caso de haber superado el límite de conexiones de ese momento (500).

Diagnóstico

Tomando como referencia a la documentación de Mongoose y Lambda se encuentra que, al estar acotado el parámetro poolSize de las conexiones a la BD (por defecto 5) y al mismo tiempo no definido un tope para la cantidad de containers (instancias) de Lambda Functions que AWS levanta / crea on-demand, AWS está levantando containers arbitrariamente según el tráfico y requests que recibe el servicio (a través de API Gateway).

Por otra parte, debido a que la API está desplegada en una sola Lambda (donde internamente corre un API Express), todos los requests a diferentes recursos los gestiona un único container. Por ende, este recibe varios requests concurrentes y todos son atendidos por un único pool de conexiones. Dicho de otra manera, cada instancia de Lambda podrá procesar únicamente 5 operaciones concurrentes con acceso a base de datos.

Debido a que AWS no tiene predefinido un tope límite de instancias creadas, estas son creadas a medida que son necesarias para de esta manera “balancear” el tráfico. Por ese motivo, y ya que por cada container Mongoose está creando un pool de 5 conexiones: si AWS levanta 20 containers vivos, levantamos con 100 conexiones en Mongo Atlas, exponiéndolo a la condición de saturación con la que nos encontramos.

Alcanzar el límite de conexiones del cluster puede afectar el rendimiento y la disponibilidad de la base de datos o, en el peor de los casos, generar una caída en el servidor, requiriendo un reinicio manual.

Solución

Ya que el pool de conexiones al cluster es proporcional a la cantidad de containers creados por AWS, se decidió poner un límite al número de containers vivos que pueden existir. Para este caso definimos un máximo de 20 instancias a través de la opción reservedConcurrency en nuestro archivo serverless.yml para configurar el serverless framework.

functions:
   <api_name>:
      reservedConcurrency: 20
      timeout: 20
      memorySize: 1536

Asimismo y tomando en consideración este parámetro buscamos un valor para poolSize que nos permitiera tener el mayor número de conexiones en el pool disponible sin superar el límite del cluster: 20 x 24 = 480 parece un escenario más conservador y, al mismo tiempo, más eficiente en el uso de los recursos. De la siguiente manera configuramos la conexión a la base desde nuestra API Express:

const db = await.mongoose.connect(mongodbUri, {
   poolSize: 24 
});

Otra configuración viable podría ser 30 x 16; léase, 30 instancias máximo de containers Lambdas x 16 conexiones reservadas en pool.

Monitoreo y conclusión

Luego de las medidas tomadas, no se observaron picos en la apertura de conexiones con lo cual se concluye que la solución fue efectiva.

Es igualmente recomendable darle un seguimiento al performance del cluster de la base de datos, observando las estadísticas de conexiones y gestionando alertas para casos en los que dicho número de conexiones se acerque a las 480.

En lo que concierne al API, es a su vez recomendable observar y buscar errores 5xx dentro de API Gateway y configurar alertas en caso de que sean persistentes en un corto período de tiempo (downtime).

Quiero agradecer a @frangeris por su colaboración y aportes en el diagnóstico y la construcción de una solución acorde al escenario en cuestión, así como también en su documentación posterior.

Imagen del encabezado tomada de Nick Van Hook (2020). "Marrying Mongodb Atlas and AWS Lambda."

Organizing your React code: Cohesion and Coupling

Ignacio Mattos — Fri, 06 Jan 2023 12:25:15 +0000

Have you ever needed to spend a considerable amount of time reviewing your own code (written just a couple of months ago) or been assigned to a new project just to find a pile of messy and eternal files?

I'm sure we've all had the feeling that a fix that took a day could've been solved in a fraction of that time by only having the code a little more organized.

Consequences of spaghetti code are usually spending days instead of hours solving problems, code repetition, inconsistencies between behaviors that should work the same way, inaccurate estimations and, of course, some headaches.

In this series I’ll try to share some notions that help me when it comes to designing clean and maintainable components, architecture and logic.

Cohesion and coupling

These two are key concepts that will go along with you wherever you code, leaving aside the particular language or framework you work with. Since they've already been explained way better than I could do here and now, I'm only talking about the core concept.

Imagine that your web has a couple of pages that share a component. Let's also say this component has a basic behaviour: a button that requests some data from an API, formats it and stores it, but this process slightly varies in each case.

It's easy to see that we are going to reuse at least a part of our code, keeping in mind that our goal is to have as little code as possible (we'll return to this later). The point is, which is going to be our criteria here? Is there a standard to conform to when designing our reusable component? The golden rule is: the greatest cohesion, the lowest coupling.

What does this mean? Said in a few words, cohesion is related with the criteria that gathers the inside elements of your component, while coupling has to do with the external relations established between your component and the environment in which it is used (I mean, everything else). And let me just add that, as we have a components tree, these concepts are to be transported to wherever you want, from less to more abstract.

For more info about this topic have a read.

Why do we want our components to be cohesive and decoupled?

The stronger relation you achieve between your inside elements, the more definite and accurate the identity of your component is. The more abstracted you keep from the external requirements, the freer you get to reuse and adapt your components to different situations.

Should I declare every single behavior the button might have when handling the click? Seems we could get a handler from our props, decoupling our logic from the one depending on foreign elements. Are you sure it's clean to fill your component with ifs to validate what to render or not according to every possible use case? Let's have a simple one-job component as external logic is out of our scope since it is inside another component's one.

Have you heard about the single-responsibility principle?

Let me share a simple example so we can figure this out:

import React from "react";

const MyComponent = (props) => {
    const {isHeader = false, isFooter = false, text} = props;

    const headerTitle = isHeader ? "MyHeader" : "";
    const footerTitle = isFooter ? "MyFooter" : "";
    const styles = isHeader
        ? {
            backgroundColor: "red",
            fontWeight: "bold",
            width: "200px",
        }
        : {
            backgroundColor: "green",
            fontWeight: "lighter",
            width: "500px",
        };

    const handleClickHeader = () => console.log("Getting header's data from API.");
    const handleClickFooter = () => console.log("Getting footer's data from API.");

    return (
        <div style={styles}>
            {isHeader && <p>{headerTitle}</p>}
            <p>{text}</p>
            <button onClick={isHeader ? headerClickHandler : footerClickHandler}>
                Click Me!
            </button>
            {isFooter && <p>{footerTitle}</p>}
        </div>
    );
};

export default MyComponent;

As we said, in these two scenarios the components' behaviour is similar. We can find differences in the button's callback, in the labels' content and in the subcomponents' order and styles, but the core idea of the component is the same for both cases.

Besides, it's bothering to see that the component is full of validations that adjust what the component renders and does according to the props' values. This means the component is coupled to the context's needs.

Doing it better 😃

As all of this can be parameterized without losing the component's identity, we are going to extract the contextual logic to achieve a simpler and more compact component that only does what it's meant to.

Following this same logic, we end up generating a few more components that gather their own specific logic (including a parent Container):

import React from "react";

const MyComponent = ({styles, text, onClick}) => (
    <div style={styles}>
        <p>{text}</p>
        <button onClick={onClick}>Click Me!</button>
    </div>
);

const Header = () => {
    const headerStyles = {
        backgroundColor: "green",
        fontWeight: "bold",
        width: "200px",
    };
    const headerTitle = "MyHeader";

    return (
        <div>
            <p>{headerTitle}</p>
            <MyComponent
                styles={headerStyles}
                text="Footer"
                onClick={() => {
                    console.log("Getting header's data from API.");
                }}
            />
        </div>
    );
};

const Footer = () => {
    const footerStyles = {
        backgroundColor: "green",
        fontWeight: "lighter",
        width: "500px",
    };
    const footerTitle = "MyFooter";

    return (
        <div>
            <MyComponent
                styles={footerStyles}
                text="Footer"
                handleClick={() => {
                    console.log("Getting footer's data from API.");
                }}
            />
            <p>{footerTitle}</p>
        </div>
    );
};

const Container = () => (
    <div>
        <Footer/>
        <Header/>
    </div>
);

export default Container;

But hey! Didn't I say one of our targets is to have less code? 🤔 Why do we have a larger amount lines in the
second snippet?

Well the point here isn't only the code you use to define your components, but also the potential repetition you are avoiding by having a reusable example that can adapt to different situations and be upgraded if your requirements change.

In the next post, I am going to share a few tips that help me organize my files.

But if this didn't move you to review your programming habits, check this out: the person on the left is a responsible developer who follows the best practices and makes an effort to improve his code's legibility when he has the chance.
The one on the right is his twin brother, who thinks it’s fine to copy&paste the same logic over and over again and concentrate his code in a few files.
Choose your cards wisely!

An alternative way to integrate with Slack using Node-RED

Ignacio Mattos — Thu, 27 May 2021 20:04:38 +0000

Do you want to make an integration with Slack?
Do you already know Node-RED but the solutions that appear in the documentation and the tutorials are not working?

I’ve been there and I passed through that.

Context
Pros and cons using Node-RED
Using a simpler node
Conclusion

Context

A few weeks ago I started working in a Slack chatbot which should answer some questions. The idea was good and the tool that was suggested to me to solve this - we talk about Node-RED - has a lot of examples on the web where it actually works.
But for some reason they didn’t work for me. I don’t know if the solutions proposed on the web are outdated or if I’ve been missing something important (of course this is something probable). The thing here is that, as developers, we are supposed to either reuse or to create new solutions.

And after a while, I finally managed to connect with the Slack API, but not in the way it was supposed to according to the doc.

In this post I’m going to show you how I solved this out hoping this might be reusable for other similar scenarios.

Pros and cons using Node-RED

Something really helpful about Node-RED is that it’s really worth it as it saves a lot of time that you would spend writing down every function you need. There’s a pile of useful nodes that facilitate the integration with external APIs.

The problem is that once you let the app manage your code, you’ll start wondering what is actually occurring and how things happen.
Leaving aside the annoying or not this could be, the big problem will show as the bugs appear and you don’t know what the node function is doing, so it is double tedious to fix them.
I mean, it is a problem to don’t know if you are missing a semicolon or if the auth token is wrong.

That is exactly what happened and what pushed me to find an alternative solution to slack-rm node or the slackbot listen, which were the ones proposed everywhere I searched for.

Using a simpler node

There’s a node called http in which listens to API calls. The advantage of using this one is that we can directly test the endpoint services using either curl or postman. This lets you know if you have an error in the request, I mean, before adding some logic.

Let me show you how to set it up:

Now we can test this from outside the app with the debug node, using curl -X POST http://localhost:1880/postmessage

The next step here is using a function node, in which we’ll set the headers and body of the request:

const BOT_TOKEN = "xoxb-...";
const CHANNEL_ID = "your_channel_id";

msg.headers = {
    "Authorization": `Bearer ${BOT_TOKEN}`,
    "Content-Type": "application/json; charset=utf-8"
};
msg.payload = {
    "channel": CHANNEL_ID,
    "text": "This is finally working"
};

return msg;

You’ll find the BOT_TOKEN in Slack apps settings. But the CHANNEL_ID is something that you’ll be able to obtain after reading this post ;)

After setting this up, we can send a request to the Slack API. If you didn’t do this yet, remember that you must set your bot’s permissions to let it use the API methods. Otherwise, no method will work.

For this use the http request node:

Finally, we add the http response node so we can have the response in the console.
The complete flow should seem like this:

After calling the endpoint we should receive the response in the bot chat as a formatted “This is finally working” message. To change that, you only need to modify the text at the request body, either in the app or in the call.

Conclusion

This is just a very first step in the general task, but I wanted to share it because I think that Node-RED is a good tool to make integrations with external APIs, but also it can get confusing when tuning it in at first.

I think that something useful after this example is that, most of the time, I guess I’d rather have smaller functions that make it clear to see what I am doing instead of using those in which we can’t see the code in the back but should solve the problems at once.

I'd like to thank to @lucasota and @navarroaxel for the tips and the reviews which have been helping me to improve my posts.

What you should know about Reactjs if you are a mobile developer

Ignacio Mattos — Tue, 11 May 2021 17:07:46 +0000

If you are a Mobile developer, it is very likely that, at some point, you will be asked to switch to web development, or even to develop an hybrid app.
Has this already happened to you? You surely have noticed that there are a few differences between each type of app that you should consider before facing a new web project.

In this post I’ll try to show some of those differences as we can see the similarities we can find among them.

The great similarities between this two tools are most related with the fact that React Native is a framework that implements Reactjs.

Some of the main diffs

These are some of the most visible things you’ll notice at first glance once you switch to Reactjs.
However, I’m not making the deepest possible comparison here, so some of you guys will probably find a more consistent way to make an intensive comparison.

Anyway, I think you will find some of these points quite useful.

At first, something important here is that, as React Native is a framework, you should have almost everything you need to develop an app from scratch in it. This is something that won’t happen with Reactjs, which is just a JS library.

What does it mean? Basically in React Native you use some features and components that are integrated with the framework and are not able outside it.
For example, in RN you use react-navigation to switch between your app screens, which is something that we won't have in Reactjs, so it may be replaced by the implementation of Nextjs and its router.
Or remember the <FlatList> component? That is also a RN component, so we'll need to use a Map instead.

However, I didn’t say that external libraries implementation was forbidden or something. Even more, something that won't happen in Reactjs is that, unlike RN, the components style won't differ according to the OS nor the platform they are rendered in.

And that's the point where you'll be pleased to know that there are some Component Libraries like Chakra, Bootstrap and many others you might have met in mobile development that, combined with some JSX, will allow you to display your web app quickly.

The components

Another thing you should know is that, unlike React Native, Reactjs uses a virtual DOM that compiles your javascript code to HTML and renders the app.
This doesn’t happen in RN: here you don’t have a thing like a DOM, and the React-Native components are formed only by JSX.
You will notice that HTML thing when you try to debug your app in the browser, so if you have skipped the basics, it is time to start reading.

In Reactjs, for example, you won’t have a <View> component, so you should learn what a <div> is.

The styling

What happens with the CSS? Are you used to the React Native StyleSheet class? Forget about it, it won’t accompany you anymore in Reactjs.

This is how you style a component using a React Native StyleSheet class:

const styles = StyleSheet.create({
    title: {
        color: #32A287,
        font-size: 2.5rem,
        text-decoration: none,
    }
});

return(
    <View>
        <Text style={styles.title}>This is a styled title in React Native</Text>
    </View>
)

And this is the way you will do the same using basic CSS:

.title {
    color: #32A287;
    font-size: 2.5rem;
    decoration: none;
}

This must be imported from the .css file to be able to use:

import styles from "../styles/Home.module.css";

...

return <div className={styles.title}>This is a styled title in Reactjs</div>

Are you wishing to start a web app yet or what?

As you can see, it is not that difficult to switch to web development if you’ve learned the basics of React.

Even the hardest issues are a matter of time until you get used to some new practices.

If it’s helpful to say it, when I started programming in React Native, it was very nice to avoid downloading an intricate and annoying emulator to run my code. As you are going to work with a browser, the only thing you'll have to think about is where to put your console.log’s: no Reload button, no external programs and no native APIs.

So, if you think there is no such big deal to replace a View by a div, I hope I can see the progress of some React engineers here! ;)

My first month as an intern mobile developer

Ignacio Mattos — Fri, 15 Jan 2021 13:33:02 +0000

Well, I have to say that this is not only the first time I write about my job: this is the very first time I write a post, so I think this is the best way to get along with the situation that I’ve got here.

I’m an Argentinian 21 years old beginner developer, and this is directed to those young developers who don’t know if they are capable of start working on what they like to do.

I started an internship as a JavaScript developer last December. My previous work had no relation with the IT world and I was trying to get out of it and find a place where I could upgrade my skills or at least do something cool.

First of all, I have to tell you that my very first time with a code line was at school, where I had my introduction to backend development and I had to construct a few desktop applications.

So, am I a beginner or not? The truth is, after I finished high school, I’ve started college and began to work in a lot of different places, but none of them were related to IT, so everything is more like a new beginning for someone that is not used to programming anymore.

Joining a team

It’s been just one month working at Cloud(x); and the most important thing that I have to say is that there is no way that someone can just imagine the difference between developing at home or in a school project and doing it for work.

I’m not saying that this is a nightmare or something similar. Far away from that, you will be happy to join a team formed by experienced people who have passed through your current situation and who can show you all those mistakes that would have taken you hours of headaches and sleepless nights.

Obviously, nobody is ever going to bring you the definitive solution that will fix all your bugs and tell you what to do line by line. But it’s always better to have someone to ask for help when those YouTube solutions are not working.

First steps, getting stuck and… what’s next?

As I told you before, my academic previous experience had no relation with almost anything that I’m doing right now. Linux, React Native, Redux and even Git were such unknown stuff to me, and it wasn’t easy to catch up with all these new tech, neither with the app that my actual team has developed up to now.

But you know what? That is the best thing that could have happened to me right now. I’m learning a lot of new things every single day, and it’s not that bad to get stuck all the time while this is useful to keep my brain working hard.

Step by step, everything is getting easier as I get able to develop higher solutions to bigger problems.

From now on...

If I have to give advice to those people who are trying to get an IT job, I think this would be that you shouldn’t be afraid of getting stuck or not knowing what to do. That’s the funny thing in here and the one that makes the difference between this and any other job: the point is that you can learn a new thing every time you solve a problem.

So get along with the idea of you passing through hard times sometimes but with a high comfort once you understand what is going on with your code and what you will need to do next time.

Make sure you have a clear idea of what you want to do -I mean, in which area would you like to begin working at- and, if you don’t know it yet, good news! Software development needs more people everywhere.

One last thing! If this isn’t your first language, I recommend you to start practicing your English with a mirror because you’ll need to communicate with people from all over the world and guess what, you won’t be able to use smoke signals or something.

As I’m just starting in this, I would like to read about your experiences as beginner developers too!