DEV Community: Daniel Silva

Stop returning NULL components

Daniel Silva — Wed, 26 May 2021 13:29:42 +0000

Conditional rendering on React helps you build your apps avoiding unnecessary renders depending on some validations, and it can be used on tooltips, modals, drawer menus, etcetera. But, if we do it wrong, we can end up losing performance instead of improving our app.

It's pretty common to see something like this:

import React, {useState} from 'react';

export const MyComponent = ({}) => {
   const [show, setShow] = useState(false);
   return (
      <p>This is my main component</p>
      <MyChildComponent show={show} />
   )
} 

export const MyChildComponent = ({show}) => {
   return show ? <p>This is my child component</p> : null;
}

That is a mistake that can potentially decrease a lot the performance of your application. Why? Because this is not conditional rendering, what we are doing in this example is returning a NULL component or, in other words, a component that renders NULL.

But you guys may think "Yeah, but...It's null, so it doesn't do anything". Au Contraire my friend, and the reason relies on its name NULL COMPONENT, and what does a component have? Right, a lifecycle. So, when we return a Null component we still have a full lifecycle that will trigger depending on what we do on their parent component.

The true Conditional Rendering:

To avoid these problems the correct way to do is to do the conditionals on the parent component to avoid even call that child component. We're gonna be using the same example:

import React, {useState} from 'react';

export const MyComponent = ({}) => {
   const [show, setShow] = useState(false);
   return (
      <p>This is my main component</p>
      show ?? <MyChildComponent />
   )
}

export const MyChildComponent = () => {
   return <p>This is my child component</p>;
}

Moving the show validation to the parent component instead of the child will make the rendering to be truly conditional. The only lifecycle that will trigger in this example will be only the MyComponent lifecycle because the MyChildComponent isn't even being called.

Why if we need the validation inside the component?

That can happen if we are working on legacy code and we need to fix something without changing every single one of the files where the component is being called. Then, we need to check if the validation will not change a lot in a short amount of time.

If that prop will not change a lot, we can use the memo() function provided by React to memoize that component and avoid unnecessary re-renders on that component and improve the performance of the app without a huge refactor. But, if this prop changes a lot, then we need to change the validation as we learn before, otherwise, the performance may drop.

If you're building something like a wrapper component that will have a conditional render inside of it but will always be rendered, for example, a Tooltip component wrapper another tip can be to manage the show as a state INSIDE the tooltip component and wrap it with the memo() function to avoid unnecessary re-renderings and prop passing to make the component reusable, autonomous and performant.

Do you have a different opinion? Do you think just like me? Do you like to add something to the post? Do it in the comments below!

I do this completely non-profit, but if you want to help me you can go here and buy me a coffee ;)

How to prepare for a technical interview - Part 1: Candidates

Daniel Silva — Tue, 13 Apr 2021 23:22:55 +0000

This is a post that I'll break into two parts: Candidate and Interviewer side.

In my career, I've been doing a lot of interviews (as an interviewer and as a candidate) for several companies and I think that I have some of the secrets to tell and help you get that dream job.

- Always be prepared:

This sounds like a cliche but I don't know how many times I've heard: "I didn't know that this was a technical interview and didn't study". You don't study FOR an interview because the interviewer wants to know how much do you know about a specific technology, and that won't change in a day.

With this, I don't say that you don't have to study and learn more and more every day but you just don't study because you're going to do an interview, it's not a test, and the interviewer will know that you're just saying things that you read but don't actually handle right.

- It's ok to say "I don't know":

One thing that interviewers know is that you don't have to know EVERYTHING, the important thing is to learn how to say it.

If you say that you don't know something try to say it with a little enthusiasm or try to talk about what you think that is (don't try to say something false because that will notice), this will inspire interest in what you do.

- It's all about the basics:

Knowing frameworks and libraries is always a plus, but what really gives you that advantage in an interview is knowing the basic concepts of the technology you are working on. With this, you can know how to handle a lot of questions.

Remember, this is a career of logic, every single one of the frameworks, libraries, snippets, APIs, are just an implementation of the basic concepts of programming and languages they're built. So, if you know how something works, you can figure out a lot of questions.

- 40% what you know / 60% how you sell it:

This is maybe the most important thing that you have to learn but what you say and how you do it.

One of the things that most companies want is someone with a good attitude, who wants to help and grow with them, that can work on a team, proactive, who can listen, honest, and who wants to improve. Getting a job isn't something that's completely about who codes better than who, but who fits better for a given position.

I can see daily, people who are not super programmers, but someone thirsty for knowledge and willing to improve every day and try to become better and better getting the position because of their motivation and because it aligns better with the company vision. You can be a great programmer that wants to do everything by yourself, but if that's not what the company wants, then you're screwed.

Have to be noted, by this, I'm not saying that you should lie about yourself, but learn how to sell yourself to get what you want.

- Don't be discouraged:

Even the best of the best got rejected at least one time and that's not entirely bad, the path to greatness is plagued with obstacles.

I guess we all know the history of Jack Ma, the CEO of Alibaba, about how he got rejected a lot of times from college and pretty standard jobs, or Michael Jordan, who got rejected because he wasn't that good at basketball. This is something that can happen to anyone at any job, the important thing is what you gonna do with that.

Learn what you did wrong on the interview and improve it for the next one, your dream job will be there waiting.

Thanks for reading my post, I hope this will help you see what the companies and interviewers want.

If anyone has something to add and help the community put it in the comments section, I would love to read it and discuss it.

I do this completely non-profit, but if you want to help me you can go here and buy me a coffee ;)

Why I don't like to use Styled-Components

Daniel Silva — Sat, 10 Apr 2021 02:28:49 +0000

It's been a while since I post something here (Really busy, sorry!) and I will start to do it again with a polemic opinion. First, it's important to say that this is completely an opinion and I'm not trying to say "Don't use it!!", but creating a space to discuss some things I do not like about StyledComponents and why I don't use it.

- Not a natural syntax:

This is probably the main reason and I mean, it's weird...There is no natural syntax about

const Wrapper = styled.div`
   width: 30px;
`

What the heck is that string template after the div?! (I know what it is, but come on). It's used to do function callings, method callings, prop passing, but it's weird to get used to tagged template literals for CSS at least.

- There's no clear convention to use it:

If you see this:

export const MyComponent = () => (
   <Button />
)

It's <Button /> a component or a Styled-Component? Can be both and we have to search for it and, depending on how big your project is, can be a pain in the a$$.

Some code editors (sometimes VsCode does this) even have problems going to the code line when you cmd + click the Styled-Components making it a little awkward to track.

Sometimes even it's exported from a "General" style file and that makes it even harder to know what you have to do or fix.

Some projects use:

const StyledWrapper = styled.div``

to differentiate between a React Component and a Styled-Component, but there's not a real convention.

- You can do theming without it:

You can easily build a ThemeProvider using React Context API that could manage the theming for the whole app and can be accessed anywhere you want. You can even build a simple useTheme() custom hook to make it more descriptive and can manage a lot of things without installing another dependency on your project.

Again, I'm not saying that Styled-Components are bad or that the creators are bad people or something, this is just my personal opinion based on projects that I've been working with.

Do you have a different opinion? Do you think just like me? Do you like to add something to the post? Do it in the comments below!

I do this completely non-profit, but if you want to help me you can go here and buy me a coffee ;)

Tips to manage your git repositories like a pro

Daniel Silva — Mon, 14 Dec 2020 02:34:40 +0000

Git is one of the most used tools for every programmer because it lets you store your code and version it, not only for your development team but also with a lot of developers that can (and probably will) improve your code or add documentation to it if the repository is public, and not do any change without your permission. So, I'll give you some pro tips to manage your git repository like a boss.

1. GitFlow's the lit flow:

GitFlow is a git workflow (maybe a little too obvious, right?) that defines a strict branching model designed for project publishing and it's perfect when you're working with at least one more developer.

This can be done by installing git-flow and starting the project with git flow init that's just a wrapper for git init and adding GitFlow, or, you can do it a little more casual and work it your own way but following the rules without using the GitFlow wrapper.

Gitflow is based primarily on two branches: develop that's the development branch where should have all the code that's not in production yet, and master that should have the code currently in production. Also, it provides tags to manage your branches that work as a folder system and will help you and your team to know what everyone is doing and what has to be done next. These are the tags and a little explanation about it:

feature: This is for new things that will be added to new versions. This will be merged directly DEVELOP branch
bugfix: This is for old things that don't work as expected on the actual version and will be added to newer versions. This will be merged directly DEVELOP branch
hotfix: This is for old things that don't work as expected on the actual version and will be added to that version. This is for bugs that break the production version or an important flow of it and it's needed to be fixed for the app to work. This will merge directly to MASTER.
release: This is to have the code for every release to easy access if it's needed a hotfix without having to do a cherry-pick of a specific commit.

The way to use these tags are:

git branch -b feature/your-branch-name

That will create your branch your-branch-name as a new feature for the app without actually modifying the development branch to avoid conflicts between teams.

2. The branch name is important:

Try to keep your branch's name to describe what you're working on to help your teammates know what they have to review when they check your code.

git branch -b feature/add-button-action

If you're working with JIRA/SCRUMWISE/TRELLO or whatever software for task management, you should use the name of the ticket with the ticket code as your branch name.
Let's imagine that we need to fix something broken for the next app release, the ticket code is APP-100 and the ticket name is Fix buy button, then your branch name should be:

git branch -b bugfix/APP-100-fix-buy-button

Or even we have a release for the app, then the branch name should be:

git branch -b release/1.0.0

3. Only merge to develop or master using Pull Request:

It's important to do Pull Requests instead of pushing directly to develop to avoid conflicts with other team members.

A good practice it's to block the develop and master branch to anyone other than the project owner or admin and only accept merges to those branches by doing a Pull Request.

4. Keep your branches updated:

To do this, at end of the day, do a rebase/merge from the develop branch, it will keep your branch up to date and will decrease merge conflicts between the development team.

5. Small and descriptive commits:

First, let's talk about what "small commits" means. This refers to don't do a single commit for a huge change on different files. For example, if you have 3 things to do: Fixing a typo in file1, Adding a new feature to file2, and fixing a wrong formula on file3, you should make three commits, one for every fix to keep your git tree clean and descriptive, and if someone needs to cherry-pick something on a single commit, can see where they need to do it.

And, for the second part, always use a message to your commits that describe really what you're doing, this will also help your team to identify what's going on on the whole branch and make the git tree clean and easy to read. Following the same example, our commit message should be something like this:

git commit -m "Fixing typo on sample text for file1"
// ...
git commit -m "Adding sample feature for file2"
// ...
git commit -m "Fixing sample formula for file3"

Also, another thing important is to set the git configuration to add your name and your email to identify who did what. We can configure this using:

git config user.name "YOUR FIRST AND LAST NAME"

git config user.email "YOUREMAIL@mail.com"

6. Code review is important:

If a lot of people are working on the same code it's important to check what they do, if they're doing it right, if it's working properly and it's following the best practices to avoid making the project messy. If not, comment on the lines you think are not ok and request changes before merging branches to develop.

Do you have other tips to improve your repository management? Leave it in the comments below.

I do this completely non-profit, but if you want to help me you can go here and buy me a coffee ;)

Most important things to become a developer

Daniel Silva — Tue, 01 Dec 2020 13:18:13 +0000

I know, this sounds like I have the secret formula to becoming a developer, but it's actually what I, in my experience working with teams and my personal growth, find important to accomplish that goal.

Some things that most people ask when they find out I'm a software developer are: "You must be so intelligent", "Can you hack a Facebook/Instagram?" (I know I'm not the only one, right?) and the most important one "How can I become a developer like you?" and I kept wondering about that. Here, I will name what I think are the most important to accomplish that goal.

1. Think out of the box

I know, it's a cliche, but it's RIGHT! Developers must think out of the box to build the software that solves users' problems. This is because when developing we have to think like users, clients, developers, and every single one of the actors that will use or participate with that software.

Most of the solutions that clients ask us to build or the ones that we build as entrepreneurs must be thought out from a perspective no one has ever thought of, or even add something new to aggregate that key point to your application to make it more appealing to users.

2. Always stay hungry for knowledge

If you're about to pursue this career, you have to know that it changes a lot! In one moment vanilla PHP is the best you have and out of nowhere something comes and becomes the new cool stuff to use and you have to learn it to try (Let's be honest, we try our best but technologies changes faster than us) to be "surfing the wave" and to be up to date with new languages, frameworks, libraries, and a lot of things that will help us find good jobs or become better at ours.

There are a lot of websites that we can access to keep track of the new stuff: Medium, Hashnode, DEV (DUH!), and really huge etcetera of places where you can find more information (If you wanna know more, I recommend reading the post of my good friend Alberto Yanes about 5 tools to keep up with tech).

But continuing in this topic, I highly recommend finding a language you love and become really good at it instead of trying to be like my people say, "an ocean of knowledge with 1 cm dept".

3. We are a community

One important thing to understand is that we're not alone. There's a huge possibility that one problem that you have with your code, someone else around the world had it too and probably it's been solved. So, ask the community, see other developers' solutions, don't be ashamed to don't know something, this is completely normal. Also, keep asking your more experienced developer friends about your doubts and problems, I'm sure they will help you out.

4. Software Factories are a good way to start

Software factories allow us to work with different teams, projects, project managers, workflows, technologies. So, use this as a way to fully understand how to work with teams, and different technologies, the difference between a really great client with all his processes and fully organized and clients not so great that will ask you to work with the minimum and want everything in no time. I know the last part doesn't sound too appealing, but trust me, it's really useful for your personal development. Then, when you gather some experience and knowledge, you can move to a product company, they're usually less stressful.

5. You have to love it

This is the most important one, to be a developer you have to love it. Because it's really stressful and frustrating, can be repetitive sometimes, you can work with clients that have really boring projects, you have to keep track of new things, always keep studying, some clients will be a pain in the ass or even some managers. But, it's a great thing to do when you do it with passion.

When writing this post I remembered the words of Anton Ego from Ratatouille:

Not everyone can become a great DEVELOPER, but a great DEVELOPER can come from anywhere.
Anton Ego

Yeah, I paraphrase a little, but it's the same idea.

6. The devil knows more by being old than by being the devil

This is an old saying from my country, but it means not being stubborn when someone more experienced gives you advice. Higher seniority developers can know best about some things because they were in the same spot you are right now and don't want you to hit the same wall.

It's ok to don't know something or to ask for advice if needed, and who is better at that than your Senior/Technical Lead/Software Architect/CTO? Remember, they have the same goal, to finish the project in time and with a quality software.

Well, this is it. Do you have some key points to add? Please, put it in the comments below.

I do this completely non-profit, but if you want to help me you can go here and buy me a coffee ;)

How to optimize your React Components using Hooks

Daniel Silva — Mon, 23 Nov 2020 20:00:38 +0000

When developing, it's important to make good, reusable, and fast components. Here, we'll check some ways to make your app to go faster than ever. But, to do this, we have to understand how React works and how we should create our components to make them faster.

How React works with renders

When a state changes in a component, it will re-render again (Simple components lifecycle), but what not all developers know is that it will also re-render every single one of their children's components. Why is that? Because with every render of the component, it will send props to their children in some kind of domino effect.
This is the normal React behavior but ¿What if we have a component that doesn't change any of their props values? It will re-render? The answer is yes! But this is not always the best for the performance of the app.
Let's imagine we have a form with one input and there's also an static image:

import React, { useState } from 'react';
import { Logo } from './Logo.js';
import { Input } from './Input.jsx';

export const MyComponent = () => {
   const [value, setValue] = useState(null);

   return (
      <Logo size={300} />
      <Input type="text" value={value} onChange={setValue} />
   )
}

The only prop that the Logo component is receiving is a number and will never change, but the keypress of the keyboard will make MyComponent change its status and re-render with its children. This has no sense because that unnecessary render from the Logo component will make the performance of your application go down, but don't worry, we will fix this.

Pure functions are the way

A pure function is a function that has to accomplish two things:

With the same entry values, it will return the same result.
When executed, it won't have any side effects on other values. A good example is:

const sum = (a,b) => a + b;

sum(2,2) /* will return 4 */

Doesn't matter how many time we call sum(2,2) will always return 4. In this way, React has something called Pure Components for classes components or memo() for functional components, that acts just like a pure function, only re-rendering a component when their props change.

Mastering the memoization

Memoization is a way to allocate in memory the results of a function call to be used again if needed to avoid going to the execution again and optimizing the call times if the result will be the same. So, if working with pure functions, this will be perfect to avoid unnecessary execution that will return the same value.

This technique will work with functional components as well and, as we are working with Hooks and functional components, we will be working with the memo function that will be provided to us by React and is just as easy as wrapping our component with the memo function.
Let's see how to fix our previous problem memorizing our Logo component:

// Logo.ts

import React, { memo } from 'react';
import { Images } from './images.js';

const LogoUnmemoized = ({size}) => (
   <img src={images.logo} width={size} />
);

export const Logo = memo(LogoUnmemoized);

That's it! Now your component will not do unnecessary re-renders by props passing.

But components are not the only thing we can allocate in memory, but also do it with functions, and here React provide us two hooks to use, useCallback and useMemo.

useCallback and useMemo

useCallback and useMemo are a way to memoize functions depending on how they work and will be written almost the same way, receiving a callback function and a dependency array. This dependency array is the one that works exactly as the useEffect dependency array, checking if it's different and if it's needed to re-create the function.
The useCallback will work on functions that will not return anything but to call another function(s), for example:

const mainFunction = () => useCallback(() => {
     console.log("this")
     // This will not have a return value
}, [/* dependencies */]);

And, useMemo will work on functions that will return a specific value. We can take the same sum pure function that we use before:

const sum = useMemo((a,b) => a + b, [/* dependencies */]);

sum(2,2); /* 4 and memorize this value. */
sum(2,2); /* Also 4, but will not execute the function and will take the same value memoized before. */
sum(4,4); /* 8 and delete the previous memoized value and store this one */

Those two functions will also avoid unnecessary re-renders on children's components, therefore optimizing the app, but there's nothing free or perfect in life, and memoization it's not the exception.

With great power comes great responsibilities.
-Ben Parker

While this can look great, memoizing costs a lot, so we have to be careful and learn what functions/components can or cannot be stored in memory.
If a component will have their props changed a lot in a short amount of time shouldn't be allocated in memory because it will do this memory allocation a lot of times and, besides optimizing our app, will take the performance ground floor. The same thing happens with the functions we're calling if the variables declared on the dependency arrays will be changing a lot, it's highly recommended don't use useMemo nor useCallback

Pro tip: Use debounce

Let's imagine we have a search bar on our application, and with every keypress, it will do a new search, making unnecessary requests to the server because users keep typing more than one letter.
Well, we can improve the performance of the app in this case by using debounce. This is used to request the server when the user stops typing for some amount of time. For example, if the user stops typing for 0,3 seconds will make the request. If not, it will wait until they stop typing and pass the time.
This could not be a lot of time, but this makes a lot of difference and will improve the performance of the app by avoiding unnecessary backend calls.

Here's an easy implementation of debounce using hooks:

import { useEffect, useState } from 'react';

export default function useDebounce(value: string, delay: number) {
  const [debouncedValue, setDebouncedValue] = useState(value);

  useEffect(() => {
    const handler = setTimeout(() => {
      setDebouncedValue(value);
    }, delay);

    return () => {
      clearTimeout(handler);
    };
  }, [value, delay]);

  return debouncedValue;
}

I do this completely non-profit, but if you want to help me you can go here and buy me a coffee ;)

Flexbox 101: Do you even flex, bro?

Daniel Silva — Mon, 26 Oct 2020 00:38:46 +0000

There are a lot of doubts about how to use Flexbox. Do flex 1 be the same size as flex 10? And what about flex 0.1? Why that's not positioning in the center of the screen? Well, buckle up, kids! We're about to learn something.

What is Flexbox?

It's just a way to manage the layout on your web or your applications using CSS that's based primarily on 2 things: Where something will be placed and what's the direction of the content.

The first part to actually start using Flexbox is to add the property to a container. This can be done 2 ways:

Adding the property display: flex to a container to make this and their children to use Flexbox. (recommended at the top container that wraps the app or the component)
Adding the property flex: 1 to a container that will only make that container to be flex.

And with this comes our first question. Why is flex number 1?

Actually, we use it as a way to determine the unit of all the container size as 100%, but flex works with mathematical divisions:
If we have a container with no other containers at the same level and we have a flex: 10 is like having 10/10 = 1.

<div style="background-color: red; flex: 10; height: 100vh;">
     <p>This is a full screen container</p>
</div>

But now, let's imagine we have two containers at the same level, one has flex: 1 and the other one flex: 3, then we take the sum of the flex number, that will be our denominator for every division and every flex will be the numerator for each container. The first container will take 1/4=0.25 (25%), the other one will take 3/4=0.75 (75%), and the sum of both results will be 1 (100%) of the parent container.

<div style="background-color: red; display:flex; flex: 10; height: 100vh;">
     <div style="background-color: blue; flex: 1;">
          <p>this will be 25% of the container size</p>
     </div>
     <div style="background-color: yellow; flex: 3;">
          <p>this will be 75% of the container size</p>
     </div>
</div>

This division will work for whatever number we declare on the flex property.

Let's give some direction to it

So, now we know how to use the basic flex and how much space we can take with the flex number, now it's time to give a direction to the container items. For this, we can rely on flex-direction property.
This property has 4 values: row, column, reverse-row and reverse-column. If you're working on a mobile app with React Native, for example, the property flex-direction will take column like default value, but for web, the default is row because of the screen size and usage for apps. The values exposed for this property just set what's the principal flex axis; those values talks a lot about itself but will have some changes in future properties we'll talk about in this tutorial.

Justifying and aligning

If we want, for example, to align something on the center of the screen we have to rely on justify-content and align-items:

<div style="display:flex; height: 100vh; justify-content: center; align-items: center;">
     <p>Centered</p>
</div>

Now is that simple to align center an element!

But wait, now this is where the plot thickens. These properties help you positioning the elements inside a flex container but will work differently depending on the direction we give to the flex container.

The values for justify-content are:

flex-start: the elements positioning at the beginning of a flex container direction. This is the default value.
flex-end: the elements are positioning at the start of a flex container direction.
center: the elements are positioning at the center of the container
space-between: the elements are distributed with a space between them. Each space will depend on how many elements are inside the container
space-evenly: the elements are distributed with space before and after. Each space will depend on how many elements are inside the container

And the values for align-items are:

stretch: Items are stretched to fit the container
center: Items are positioned at the center of the container
flex-start: Items are positioned at the beginning of the container
flex-end: Items are positioned at the end of the container
baseline: Items are positioned at the baseline of the container

Also, depending on flex-direction, justify-content and align-items can align in different directions. Why is that? Because flex-direction sets the principal axis of the container and justify-content works in that axis, meanwhile align-items works on the secondary axis, so visually will be different. I know this is a little confusing, but with some practice, this will be really easy to understand.

Now it's time to Flex:

With all the information given here, you can start the world of Flexbox!
There's a lot of information about this that will be covered in another post and, it's fair to point out that this guide is for beginners.
If you want more information about this, there's a lot of free tutorials to see:

I do this completely non-profit, but if you want to help me you can go here and buy me a coffee ;)