DEV Community: Juani Galan 🇺🇾

(Don't Fear) the components

Juani Galan 🇺🇾 — Sun, 19 May 2019 02:33:53 +0000

I have been working with React over a couple of years now, and over those years, I have noticed that there is a development life cycle ♻️ that tends to repeat itself for each component. We create a simple component on a single file, with no more than 30 - 40 lines of code where you define how it works, its internal state and how it is rendered to the end user. You also create a test file, where you test the logic that you implemented, passing different props and seeing how your component behaves.

Up until now, everything looks great! Your component is reusable, has tests of its own and it takes care of a simple task. But then, a new feature arrives and we need to add some code to it. We add those changes, we adapt our styles and tests to match them, and voilà! Our component displays this new cool feature 😎😎 and we still have it encapsulated in a single file within a single component.

The Snow Component Effect

However, we know that it does not end there. New features arrive all the time, and a component that used to be 40 lines of code becomes a really complex file with over 500 lines of code taking care of multiple responsibilities, and our tests and stylesheets start to suffer from the same symptom. I call this the snow component effect ❄️❄️, where we keep on adding code and features to a component, and it then becomes this monster that haunts us throughout our releases 👻👻

So how can we minimize this effect? What things do we need to keep an eye on in order to detect these scenarios? And how can we refactor our code to keep the snow component effect at bay?

A practical example

I decided that it would be best to take a look at these scenarios through a series of code examples that illustrate how a simple component can escalate real quick and what code smells arise that tell us "hey, maybe we can move this to another component!". These code smells 👃👃 do not mean that you are doing something wrong, they are just pointers that can help you to figure out if what you are doing makes sense for your current scenario, and maybe detect that there is a better approach! The idea behind all of this is that the code makes sense for you and your team, and that the decisions you are taking will not tie you up in the future.

Therefore, I created a small web that displays the latest PS4 games, showing a title, an image and a link to the game itself:

Taking a quick glance at the component, we could say that it looks simple enough right 🤔🤔? Our component should expect a list of games, each of them with a title, a source for the image and the link to redirect, and we will iterate through those games and create the link tag and the image tag for each of them:

As simple as it looks, we can already identify a couple of things that should raise some questions regarding our logic:

We are passing a games list to our component, so in order to check that each game has the correct information, we created a prop type validation that checks for the prop games to be an array with a specific shape, which is already starting to look like a small snow ball. Does it make sense to validate the game's information on the component that renders a list of them? Should the component that renders a list of games validate the information of each game, or should it only take care of how a list of games is rendered, no matter what the game has?
What if we want to render these games in a different manner, maybe using ordered lists or just plain divs? Is the rendering of a specific game tied to the fact that there is a list of them? What if we want to render a single game in a non-list context?
We have created two base class names for our components, one called "games" which we are using for all of our elements that are related to the list of games, and "game" for everything related to the game itself, and we are using one or the other depending on the element. This is already showing us that styles and class names have a different base depending on what we are rendering. Does it help us to have these class definitions on the same file? What about stylesheets? Does it make sense to have styles for "games" elements and "game" element on the same file?

Now imagine that we released this component as is, and a couple of weeks later new requirements arrive. Winter is coming for your components:

We want to add some visual distinction to the games that we consider featured, maybe a border outline of some sort, just to capture the user's attention towards these games
We also want to show what games are not available, maybe due to out-of-stock situations, and we want to prevent users from clicking on it.

From a data standpoint, it makes sense to add some flags to each game, maybe something like isFeatured and isAvailable. But what happens to our component? To tackle these requirements, we will add specific css classes to our component in case the game is featured or available, and also prevent the click on the link if it is not available.

This new requirement has added some key changes that should also start a discussion:

We added the prop types for isAvailable and isFeatured on the arrayOf definition. But these are new props, and it could take sometime for the consumers of this component to adjust to these new props. So in order to avoid showing Prop Type warnings as well as resulting in unexpected behavior, we want to default to a specific value. Since these are booleans, it should be easy enough, so let's say we will default to isFeatured = false and isAvailable = true. But taking a look at the example, how can we actually achieve that? We currently have an arrayOf a shape, how are we going to write our default props? Should default props for an object depend on the data structure that holds it? We could achieve that by creating a specific default function for these props, but we would be mutating the array, which can result in unstable behavior.
Changes related to these features are now directly tied to the component that renders the list of games. If sometime in the future, these css classes change, or we need to add a new variety, we will always comeback to the games component. Here we could ask ourselves, does it make sense for functionality related to iterable objects live beside the component that iterates them?
Also let's take a look at the test for this component. We will need to define different arrays in order to try out the original requirement plus how the game is rendered when it is featured and when it is available:

Should the games component really care if the games list has some featured games and some available ones? Should this component test edge cases that are related to the iterated objects? Aren't they more tests cases related to the game itself? If we want to test the click on the link and see that it trigger the preventDefault function when the game is not available, does it make sense to test that on the Games component test?

One possible solution

Up until now, we have seen that there are a couple of decisions that we made make the Games Component and each game itself really coupled between one another. But what if we separate these pieces, and create another component for the Game itself?

So we have created two separate components, one called Games and another one called Game. By doing so, we have several advantages that come from it:

The most noticeable is that the Games component has turned into a much smaller and simpler component. It is easier now to read and maintain, and tests will only need to pass and test scenarios related to the games prop and the title prop. No need to create edge cases for the game specific functionality.
Namespaces used for classes are now separated between the two components, making our classes independent from each other. Separating these components also allow us also separate our styles, maybe creating separate files for each component.
Game props are directly validated on the Game component, not in the Games component. The Game component is actually the one that states what things are necessary for it to render, and are not tied to the data structure that holds them. Also, we can declare those default props for isAvailable and isFeatured, setting the default behavior directly in the Game component.
We have also made the Game component independent from the context in which it renders. Previously, there was no way to render an image outside of a list. Now, we can use the Game component wherever we want, in a list, individually, or in another way. When separating components, we can extract the functionality and increase our reusability.
Finally, testing has become much simpler and targeted, since for example, testing related to the featured and availability functionalities are directly tested on the Game component, and the Games component does not know about this. In the future, if there are further changes to the game component, we will add the appropriate tests to that suite, and our Games component will still be agnostic to this.

To sum up!

There is definitely a breaking point when developing React components when our components pass from a maintainable and reusable piece of code to a big complex component that englobes a lot of functionality. This at first can seem simple, but later in the development process, iterations and new functionality can turn these components into a snow ball, each time adding more and more code that becomes this massive structure that everyone is scared of getting hit by it.

In order to avoid that, take sometime to think through where each functionality should live, and if it makes sense for it to live in a particular component, or maybe migrating to another one will save you sometime in the future. Try to see what helps your code be more maintainable and readable, and I hope that these pointers I found can give you an idea of what questions to ask when you are writing React components :)

Is there a price to pay for using exceptions?

Juani Galan 🇺🇾 — Sat, 11 May 2019 20:16:03 +0000

Have you ever wondered how exceptions start to shape and have an impact on your project? Are they useful? Do they affect performance in anyway?

During a recent class at my University there was a specific discussion related to exceptions and how they can take a toll on your project. Most of the conversation involved arguments about how exceptions work, when are they useful and how they affect your project, from several perspectives; code readability, coupling, performance and overall usefulness of exceptions. I wanted to explore this idea a little bit and see what implications exceptions have when you start using them.

In my experience, exception handling is a very vast and discussed topic, with several different opinions on it, which usually are formed due to each individual’s personal experience. I have seen programmers doing extensive and defensive code by doing a try/catch for every single operation or method execution, to surround everything in a big try/catch with one exception handling, to nothing at all.

Is exception handling useful?

Yes, it is very handy in scenarios were you are accessing specific resources that can fail in a critical way, for example, accessing a database, an API call, opening a file, etc. These situations will eventually fail, due to a timeout, a resource cannot be found, you did not comply with a specific rule in your database such as a foreign key or a required field, or an unexpected error. And exceptions allow you to recover from those scenarios and show something to the user, an Error Page, a Page not Found, a “Sorry, try again later”. Something meaningful that will let the user know that something went wrong, and not just have their window or browser closed or frozen.

Exceptions are very useful as well when you are developing libraries that are meant to be used by other teams or if you want to contribute to open source. Usually people don’t take the time to read how a specific library works, and they just use it. If there is something that they missed, throwing an exception would be a great way to educate them and control how they interact with your library.

But sometimes, could it be a little bit too much?

On the other hand, we have other scenarios were using an Exception would be a bit of an overkill, since you maybe could solve that scenario by other simple control structures.

Take the following example: You have a class called Employee, that has a constructor that accepts 1 parameter, a name. Imagine that name is required, and you cannot create an Employee without a name. So you decide to implement a custom exception, that when name == null, you throw this exception to anyone who wants to use it, which we are going to call EmployeeException. This would imply that:

Every part of your application that wants to create an employee, would need to surround the code in a try catch to catch that specific error
Every part of your application would have a dependency to both Employee and EmployeeException, which would increase coupling that could lead to maintenance problems in the future.
The try/catch would be a little bit confusing, since you would be throwing an EmployeeException. Was it because the name was empty? or did I have to set other variables as well? Or the name needs to have a specific format? Obviously you can change the name of the exception to something more understandable, but if you are working in a team or using an external library, and someone else coded that Exception, it could lead to confusion. And imagine if there are several errors that could throw that Exception? Would you create a custom exception for each of them? That could lead to increase more the coupling between your project and Employee.
It could have an impact on performance (I will explain this later on)

We could potentially resolve this by adding a static method to the Employee class that from a specific set of parameters, returns a boolean that shows if the Employee can be created or not and that would help with the points I stated above. This would be one of those alternatives to exception handling, validate inputs and create validation methods.

And how about the performance of my application?

For this discussion, I thought that I could take a more practical approach. So I created a simple Java Project that does follows the Employee scenario that I mentioned before. Basically we create an Employee with a constructor(String name) and we throw an exception if name is null. And we do the same but we add an isValid method to check before creating the Employee. I tested this using a for loop and running the constructor several times, because in order to see a difference in time execution, I need to create more than 1 Employee. So I tested the following scenarios:

1- Create an Employee with name = null and surround it with a try/catch.

2- Create an Employee where half of them will throw an error and half of them would pass and surround it with a try/catch.

3- Create an Employee where half of them will throw an error and half of them would pass and surround it with a try/catch, and also on the catch, I execute ex.getStackTrace(), just to simulate exception handling.

4- Create an Employee where a fifth of them will throw an error and surround it with a try/catch.

5- Create an Employee with name = “test” and surround it with a try/catch, but since it is a valid name, no exceptions are thrown

6- Create an Employee with name = “test”, but before I executed an isValid

I executed these scenarios with total set in 100, 1000, 10000, 100000, 1000000. And here are the results (measured in milliseconds):

For i = 100, there is not much of a difference, executions take from 0 to 1 ms
For i = 1000, scenarios 1, 2, 3 take 3 times more than scenarios 4, 5, 6. This starts to give the idea that handling an exception takes more time. Furthermore from number 5, we can notice that adding a try/catch block does not slow down performance, if no exception is thrown.
For i = 10000, scenarios 1, 2, 3 take 16 to 23 times more than the other scenarios
For i = 100000, it sky rockets to 136 ms and 154 ms for scenarios 1 and 3, and 5 ms and 4 ms for scenarios 5 and 6.
For i = 1000000, scenarios where exceptions are thrown and managed can take up to 1 second.

To sum up!

Overall, we can say that exceptions are obviously one of the pillars for programming languages. They enable us to recover from several critical scenarios and allow us to convey that information to the user. Moreover, it allows us to track these errors on the catch closure, so we can learn from these errors and iterate our project to prevent them.

On the other hand, we need to take into consideration that exceptions are not only affecting the end user, but also the developer. Custom exceptions can lead to problems with code maintenance, readability and performance. IMHO would say that it is more of a case-by-case analysis, sometimes they can be quite helpful, but in other scenarios it could lead to some headaches! Just make sure you give a little bit of thought before introducing exceptions into the mix.

Battle of the colors

Juani Galan 🇺🇾 — Sun, 07 Apr 2019 20:38:50 +0000

Search filters are one of the most important aspects of eCommerce websites, allowing our customers to refine their results and find what they are really looking for. In order to do that, we usually try to make these filters as useful and usable as possible, since we want them to be really helpful and provide a great experience for our customers. From a frontend technical perspective, the filters design can turn into a complex problem to resolve, which can impact both usability, maintainability and performance of our search result pages.

Our contestants

After doing some research through the most popular eCommerce websites, I was able to categorize those implementations into these groups:

Sprites with dynamic styles: images are used to display colors, which are located on a sprite and later each color rendered has an inline style that sets the background-position to the corresponding color.
Inline styles: background color for each option is set via inline styles with a background-color property to the corresponding HEX or RGB color
Css class based: css classes are defined for each specific color, with a specific naming convention. On rendering, that class is added to each color filter option, which then links to the css class, and their respective RGB or HEX color.

Once I got the the most popular implementations, I decided to recreate them in a simple environment, with the idea to evaluate the following:

Performance: How each alternative affects the size of each dependency of the page, as well as the time for the page to complete load, doing a specific focus on the Critical Rendering Path
Maintainability and scalability: we need to consider how the implementation will affect us in the future, in case we need to edit the colors in any way, or maybe change the entire filter
User experience: It is very important that we take into consideration how the final version affects our users and how they will use our filter, and how the interaction with this filter can increase conversion and return rates.

For the implementation itself, I wanted to create a free external dependencies scenarios, in order to have a website where there would only be the html, with the css and images dependencies, with no js on the client side. In order to achieve that, I created three separate html files which each alternative.

To test this, I created a repository on GitHub with these three html files, and I accessed them via GitHub pages:

Also, to evaluate all these aspects and try to determine a difference between the alternatives, I used Lighthouse Audits with Throttling Applied Fast 3G, 4X CPU Slowdown from the Google Developer Tools, for evaluating the performance and cost of each implementation.

Fight Highlights

Without further delay, here's the results for each alternative.

Sprites

So in rendering terms, the sprites alternative took 860 ms to render the first content on the browser. In this case, it would be the texts for each color and also the title. Since we are showing these colors using an image, the request to retrieve that image does not block our rendering, so the browser can show the names of each color before showing the actual block with the color.

This is actually a good thing, since this approach allows us to render something meaningful (like the audit said) to the user, which ends up enhancing the experience that they have. See the below example, which one would you say that includes the red you are looking for?

Plus, with images you can provide a filter that is more detailed and precise, and represents what they are really searching. Imagine searching for a red shirt, but you are not quite sure what specific tone of red you want. Maybe an image displaying a palette of reds will make you as a user more confident that what you are looking for is in that area.

On the other hand, we obviously need to fetch the sprite containing all these images for each color and that adds loading time and costs. And that affects the load event been triggered, since this won’t happen until that image is downloaded, which ends up making the crazy spinner that you see (and every user sees and worries about) on your browser’s tab spin a little big longer. That’s why the Speed Index (how fast the page is visible) and Time to Interactive (time when page is fully interactive) happen 400ms after First Contentful Paint, because the page is not fully loaded yet. However on the next request, you will have this image cached by your browser.

Furthermore, taking this approach without considering what colors are really shown when searching on a specific category or filtered list can result on sending really big sprites to the frontend, and maybe end up using 2 or 3 of those colors, since the items that you are displaying do not have all the colors on your sprite.

Plus, if you have a different image for different states (hover, selected), that sprite will duplicate in size, which will add up to the overall size of your application. You can definitely create several sprites for different scenarios (maybe by category) but it will take some operation time to do this and maintainability for this scenarios will be some hard work.

Dynamic Styles

With dynamic styles, we can see that the First Contentful Paint takes around the same time as using sprites. However, when we show the user content, we automatically display the names of each color with their corresponding RGB. We can see this by analyzing the Speed Index and Time to Interactive ms, which are faster than the sprite scenario. This means that the site could be considered more interactive, since the time that the browser takes to display the full content of the page is faster, and we allow the user to interact with it in less time.

The size of the HTML is a little bit smaller for this alternative, since the css needed to set a background-position is longer that setting a background-color. But the difference here is less than 1KB, so it would not be a big impact. Plus, since you are only bringing to the frontend the colors that you are going to use, the more specific the filter is, the more bytes you will save, because that color list will probably get smaller and smaller. However, this approach does not scale when you have several color filters on your website, like primary and secondary colors. This is because each filter will be rendered with its own inline css, which will make some css to repeat itself.

Static Styles

As we can see for this alternative, all metrics take considerably more time than sprites and dynamic styles. This is due to the fact of the presence of the stylesheet, which blocks the rendering of the page until it is loaded. We even have a note from Lighthouse regarding that stylesheet:

In this scenario, not only did we have to download the HTML to render the page, but also wait for the css to be downloaded so then they can be processed and rendered. Moreover, the stylesheet used will potentially have all the colors that you need, which will result in the browser not using a percentage of that file, since not all the colors could be present. On the other side, the file will be cached by the browser, so the next request will be much smoother. And also if you have several color filters on your site, it will be useful to have all colors centralized in one file.

From a maintainability stand point, adding new or changing colors will result in generating a new stylesheet and deploying, as well as adding or changing the classes that we have created to map colors to their rgbs. Plus, this creates a new dependency, since the way that we have to associate colors to their rgbs is by naming convention, which usually ends up being the ID of the color. If that ID also changes, we need to update the stylesheet as well.

And the winner is…

Taking a look at the options, we can say that there is actually no winner, but a more suitable approach for a specific scenario.

If you are very focused on how the user perceives your website and want to provide a very customized experience, with different color flavors and patterns depending on what you are seeing, definitely using sprites is the option for you. But beware, you will need to take into consideration that creating those sprites and the css to set the background position could take some time!

If your website targets mainly mobile devices and you want to deliver as little as possible to the end user, then dynamic styles will definitely fit your scenario. It will allow you to download only what is needed, which will save both processing and loading time, as well as overall costs for your application. Also you can leverage this possibility by displaying a small set of colors on your filter, maybe the most popular ones, and then allow the user to see more. Once that happens, you can do an AJAX request to retrieve the full list of colors, which will come directly on the HTML.

And to finish up, if you have a simple scenario where you only would like to show a simple color filter with no custom logic or different flavors, going with the static alternative will suffice for the moment. You can also leverage this technique when building Single Page Applications, since styles will be downloaded only once and will be useful during the entire time the user is navigating your application. However do take into consideration that this alternative can bring some headaches in the future if your application grows.

Hope you enjoyed this article! If you liked it, leave a clap or a comment, I would love to hear some feedback!

If you want to learn more about Critical Rendering Path, I suggest you take a look at the free course in Udacity about Web Performance Optimization. I took it to have a little bit more background for this article and loved it!

First Workshop JS in Montevideo!

Juani Galan 🇺🇾 — Fri, 05 Apr 2019 17:48:57 +0000

In recent years, in Mercado Libre, we have begun to use new technologies in all our frontends. It has been a long way, but now we have a Frontend technological Stack that has the following components:

Node JS as the server for our frontend applications
React JS for our client-side code
Webpack

With this new adoption, it has really been a change in our way of working and developing. We have substantially lowered the development, generation of versions and deployment times, as well as installation and testing times. It has been a great success for all of us who developed frontend in Mercado Libre!

And for this reason, we decided that it was a good opportunity to start promoting the use of these frontend technologies in the community in Uruguay, and that is why we organized one of the first JS workshops in Montevideo.

From scracht!

We wanted to start the beginning, so that anyone who is really interested in frontend can join the event and learn a little about these technologies. With this in mind, we decided to hold the workshop on React JS.

React is a library developed by Facebook, oriented to the development of components. It seeks to create visual units independently so that later these components can work together creating more complex applications. This approach is very important for us, since one of our objectives when developing frontends is that Mercado Libre maintains a visual coherence throughout the user experience, and with React JS, it is very simple and fast for us to share different components in order to maintain that coherence.

With all this, with Martin Varela we decided to put together an event where the community could get closer and learn a bit of this technology, to have the basic concepts and be able to promote the use in their companies or in their personal projects.

The event

This workshop was held on May 26 and the places to come quickly sold out. About 40 people came to the Mercado Libre development center in WTC in the Buceo zone in Montevideo.

During the workshop, we carried out a dynamic that interspersed theoretical aspects with practical ones. Our idea was to give a workshop where you can quickly apply the concepts seen, in order to increase the understanding of them. Making this approach, we set up a practical exercise where each person had to make a list and a search engine of Mercado Libre products, which we were building in each stage using concepts seen in the practical part.

At the same time, we created a practical/theoretical material that served as a guide to perform these exercises, as well as allowing people to follow the workshop in a more detailed manner and with code exercises. This material allowed them to see examples and have a knowledge base to which they can return.We used the wonderful tool of GitBook to make this material.

The workshop was a success, all those who joined contributed a lot and in general terms, we received very good feedback from the workshop, since 100% of the people commented that they would return to another.

We want to thank all the people who came to the workshop as it was a great experience and we hope that they left wanting to know a little more about these technologies, as well as the way in which we apply them here in Mercado Libre.

We also thank all the people in Mercado Libre who helped us organize the workshop!