DEV Community: Facundo Botta

JavaScript - Things

Facundo Botta — Wed, 29 Oct 2025 17:07:09 +0000

Introduction

In this post, I want to share some JavaScript behaviors that often seem nonsensical at first, but actually reveal something about the language’s nature. Understanding them can help us avoid mistakes — and even take advantage of them.

The following examples are inspired by the book Eloquent JavaScript and by the quiz on JS is Weird web's site.
Another interesting resource, not taken into account for these examples, is jsdata.wtf that shows unexpected, or not so much, behaviors of the Date object.

So:

`true + false === 1`

Boolean values are converted into their numeric counterparts:

Number(true); // -> 1
Number(false); // -> 0
1 + 0; // -> 1

`!!"" === false`

The double exclamation mark (double NOT) converts any value to its corresponding boolean, based on its truthiness or falsiness, just like the Boolean() function :

!!""; // -> false ("" is falsy)
Boolean(""); // -> false
!!0; // -> false
!!"hello"; // -> true
!!666; // -> true

`+true === 1`

This is an example of type coercion, its minds JS tries to convert a value to a number. Internally JS use the Number() function:

Number(true); // -> 1

`true == "true" // false`

Here the loose equality operator (==) tries to convert the values to number:

Number(true); // -> 1
Number("true"); // -> NaN
1 == NaN; // -> false

`null + 0 === 0`

When performing arithmetic, null is coerced to 0:

Number(null); // -> 0
0 + 0; // -> 0

`if ([] == false) → true` but `if ([]) → true`

This one shows how truthiness and type coercion are two different mechanisms:

if([]) When you use a value inside an if statement, JavaScript simply checks its truthiness — no type conversion, no comparison.

if ([]) console.log("truthy"); // → truthy

Arrays (and any non-null objects) are truthy, even if they’re empty:

!![]; // -> true
Boolean([]); // → true

if ([] == false)

Now we’re using the loose equality operator ==, which triggers type coercion and the rules changes.
When comparing an object [] and a boolean false, JavaScript first converts the boolean to a number:

Number(false); // -> 0
// So we get
[] == 0;

Then it tries to convert the array to a primitive value (a number or string).
For an empty array:

[].toString(); // → ""
Number("");    // → 0

Finally we have:

0 == 0; // -> true

JS uses truthiness for if(x) and type coercion for x == y, that’s why something can be truthy and loosely equal to false at the same time.
We have the === operator to avoid these surprises...

`0.1 + 0.2 !== 0.3`

This behavior comes from how floating point numbers are represented based on the IEEE-754 standard used by JS and every major language.
The result is actually 0.30000000000000004, if you want to know more check the https://0.30000000000000004.com/ web site.

`NaN !== NaN`

A Not a Number value is, by definition, not equal to anything... not even to itself

`'5' - 3 === 2` but `'5' + 2 === '53'`

The - operator always expects numbers, so '5' becomes 5.

But the + operator can mean addition or string concatenation, so if one operand is a string, the string concatenation wins.

`'' == 0 -> true`

The empty string is falsy and JS convert it to 0:

Number(''); // → 0
0 == 0;     // → true

`0/0 -> NaN`

In divisions by 0, JavaScript does not always behave the same way:

1 / 0 // Infinity
-1 / 0 // -Infinity
0 / 0 // NaN

This behavior is caused too by the IEEE-754 standard that JS uses for its numbers.

`[1,2,3] + [4,5,6] // -> "1,2,34,5,6"`

Ones again the + operator treats values like strings if they are not numbers, so it performs a string concatenation with the two arrays.

If you want to save the , you have to put it before the 4:

[1,2,3] + [,4,5,6] // -> "1,2,3,4,5,6"

But not after the 3 because of the trailing coma will be ignored.

Conclution

This list could go on with more and more examples, but as you start to understand the why, the examples start to sound repetitive.

Most of these behaviors, which seem “weird” at first, are actually the result of how the language uses different strategies to handle the values it receives.
We can recognize in these examples some of JavasCript's main strategies, like type coercion and truthiness.

It’s thanks to those decisions JavaScript makes for us that we get certain freedoms — to be care, and to be creative too, like:

('b' + 'a' + + 'a' + 'a').toLowerCase(); // -> "banana"

😁 Thanks for reading!

Git 3-3 - Workflows

Facundo Botta — Sat, 12 Jul 2025 16:11:00 +0000

Hi there! It's taken me a while, but I'm finally back to wrap up this 3-part series on Git and GitHub. I hope you’ve found it helpful so far!

In this final part, instead of continuing with commands and terminal examples, I want to talk about Git workflows. Knowing a handful of useful commands is enough to get started, and we can always refer to the docs or ask the ever-present friend we all share: ChatGPT. 😄

But when working on a team, understanding some basic collaboration strategies and branching models is very helpful.

What is a Git workflow?

A Git workflow is a branching strategy or structure that development teams agree to follow when working on a project. It ensures smoother collaboration, clearer versioning, more efficient debugging, and a generally more organized development process.

There are several popular Git workflows out there. Personally, I’ve worked with Git Flow and GitHub Flow, but I also want to touch on Trunk-Based Development and Ship/Show/Ask, which are more modern and increasingly common.

Git Flow

Git Flow is one of the earliest formal Git workflows, proposed by Vincent Driessen in this influential blog post from 2010. At the time, teams were transitioning from centralized version control systems to Git, and needed a more structured way to handle parallel feature development, releases, and hotfixes.

Git Flow became widely adopted, especially in enterprise environments and teams building software with scheduled release cycles (e.g., desktop apps, backend APIs, mobile apps). While it can be overkill for continuous deployment setups, it remains valuable for structured, long-lived projects where stability and versioning are priorities.

The strategy is based on two main branches:

main (or master)
development (or dev)

Alongside them, there are support branches like:

hotfix/*
release/*
feature/*

Note: The branch names are just conventions, you and your team can use whatever naming style suits you.

main branch

This branch contains the code that is currently in production. Ideally, it should always be stable, clean, and free of debug logs or experimental features. All merges into main should be reviewed, tested, and approved, ideally backed by automated tests.

We do not work directly on main; instead, it only receives thoroughly tested changes from release or hotfix branches.

development branch

This branch contains the code in pre-production, features that are being actively developed but not yet ready for deployment. Developers merge their completed features here for testing, code review, and integration. Once stable, changes from development are moved into release, and eventually into main.

hot-fix branches

Sometimes bugs appear in production, and the development branch isn't in a deployable state, maybe it contains half-finished features. In those cases, we create a hotfix branch from main, apply the fix, test it, and then merge it back into both main and development. This avoids introducing the bug again during the next release cycle.

release branches

These branches are used to prepare a new version of the application before pushing it to production. Think of them as a staging area to finalize bug fixes, polish features, or update documentation.

When everything is ready, the release branch is merged into main and tagged with the version number. It is also merged back into development to ensure it stays up-to-date.

So where do we actually do the work?

Developers don’t work directly on main or development. Instead, they create temporary branches for each task, feature, or bug:

feature/ for new features
fix/ for bug fixes
refactor/ for code improvements

These branches are created from development, and when finished, they’re merged back into it.

Example

# Make sure your main and development branches are up to date
git fetch origin
git switch development
git pull origin development

# Create a new branch for your feature
git switch -c feature/contact-form

# Work locally, commit changes
git add .
git commit -m "Add contact form to homepage"

# Push your feature branch
git push origin feature/contact-form

Then, from GitHub (or GitLab), you’ll open a Pull Request (or Merge Request) targeting the development branch. The team lead or reviewer will evaluate your changes and decide whether to approve them.

When to Use Git Flow

Git Flow works best when:

Your team releases software in fixed versions or sprints.
You need to manage parallel development, hotfixes, and releases.
You want to enforce a clean separation between stable and experimental code.

It may be too rigid for teams practicing continuous deployment or working on fast-moving web applications, but for many software projects, Git Flow provides clarity and discipline.

GitHub Flow

GitHub Flow is designed to be lightweight and fast-paced. It focuses on just one main branch (main), and uses temporal branches to introduce new work. There’s no development, release, or hotfixbranches, just your feature branches and main.

It was popularized by GitHub around 2011 as an alternative to more heavyweight workflows like Git Flow. It aligns well with continuous deployment practices, where the codebase is always in a deployable state and new features are delivered to users as soon as they’re ready.

It’s especially popular in:

SaaS applications
Web apps with daily deployments
Startups or small teams prioritizing speed and flexibility

Example

# Make sure you're up to date with the main branch
git fetch origin
git switch main
git pull origin main

# Create your feature branch
git switch -c feature/new-navbar

# Work on your changes
git add .
git commit -m "Add new responsive navbar"

# Push to GitHub
git push origin feature/new-navbar

When to Use GitHub Flow

GitHub Flow is ideal if:

You deploy frequently, even multiple times a day
You have automated testing and CI/CD pipelines
You value simplicity and speed over structured release cycles

It might not be suitable if:

Your project requires strict versioning
You need parallel hotfix and release management
You're working with large teams and long-running features

Trunk-Based Development

Trunk-Based Development (TBD) is a modern Git workflow used by high-performing engineering teams, especially those practicing continuous integration and continuous delivery (CI/CD).

In this model, all developers commit to a single shared branch, usually called main or trunk. Feature branches either don’t exist or live very briefly (e.g., for hours, not days). The goal is to reduce integration overhead and release changes quickly and safely.

TBD has been around for over a decade but gained traction thanks to Google, Facebook, and other companies that needed to ship code rapidly without drowning in long-lived branches.

It’s often paired with practices like:

Feature flags
Canary releases
Automated testing
Code reviews on small commits

Core Concepts

Only one long-lived branch: main (or trunk)
Developers push directly to main or short-lived branches merged quickly
CI runs on every commit to ensure stability
Use feature toggles to hide incomplete work from users

But... It seems the same as GitHub Flow 😄

Yes, they are very similar, but there are some key differences:

Development Worflow

In GitHub Flow, you create pull requests from your feature branches into main. Once the pull request is approved, the deployment process starts.
In Trunk-Based Development, changes are pushed directly to main, often multiple times per day. Every new commit can trigger a deployment pipeline, which is strongly backed by automated testing and CI/CD tools.

Handling New features
In GitHub Flow, new features can live in their own branches until they're complete and ready for production.
In TBD, new features live inside main from the start. They're controlled using feature flags or feature toggles, which allow developers to merge incomplete work without exposing it to users.

if (isFeatureEnabled("newCheckout")) {
  renderNewCheckout()
} else {
  renderOldCheckout()
}

Feature flags allow us to gradually test new features, experiment with multiple versions at the same time, or roll out functionality to a specific group of users, such as in canary releases.

When to Use

Use TBD when:

You practice continuous integration/deployment
You want to reduce merge conflicts and simplify code integration
Your team ships often and values small, incremental changes\

It may not be ideal if:

You lack automated tests or CI pipelines
Your team isn’t disciplined about pushing only tested code
You release on a strict versioning schedule

Ship / Show / Ask

Ship/Show/Ask (SSA) is less of a branching strategy and more of a philosophy for how developers collaborate and share their work. Unlike Git Flow or Trunk-Based Development, SSA doesn’t prescribe a specific structure—it’s about how and when you involve others in your development process.

This model has been promoted by companies like GitHub and others that favor developer autonomy, asynchronous workflows, and decentralized decision-making.

SSA defines three modes of contributing code, each reflecting a different level of collaboration:

1. Ship

Ship means you make the change, push it, and deploy it without asking for permission. This is best for small, low-risk, or well-understood changes—like fixing typos, updating comments, or making trivial bug fixes.

It relies on strong developer judgment and confidence in the CI/test suite to catch issues.

2. Show

Show means you share your work before merging or deploying it, but you’re not necessarily asking for approval. It’s useful for mid-sized tasks, experimental ideas, or when you want early feedback. You might open a Pull Request with a title like [WIP] Refactor login logic and invite comments.

It’s collaborative, but informal.

3. Ask

Ask is the most formal mode. You request a review and wait for approval before merging. This is appropriate for high-risk, complex, or sensitive changes; basically, anything that should be reviewed before going to production.

What about branches?

SSA doesn’t enforce a particular branching model. In practice, it often looks like GitHub Flow: one long-lived branch (main or trunk) with short-lived feature branches. The key difference is how you handle the social process of merging, not the structure itself.

When to Use Ship/Show/Ask

SSA works well when:

Your team is experienced and trusts each other
You value asynchronous, low-friction collaboration
You have strong CI/CD and automated tests in place
You want to balance autonomy with communication

It might not be ideal if:

Your team needs more structure or clarity
Newer team members could benefit from stricter review processes
Your organization requires tighter control over what reaches production

Conclusion

As we’ve seen, there are several Git workflow options, and the “right” one really depends on your team and project context. Choosing the right strategy can make a big difference in how smoothly your team works and how cleanly your project evolves.

Even if you stick to just one workflow most of the time, I believe it’s important to be familiar with the others—you never know when a different model might come in handy. In the world of open source and cross-team collaboration, it's common to encounter these patterns, and recognizing them can make it much easier to jump in and contribute.

I hope you’ve enjoyed this mini three-part series on Git and GitHub as much as I enjoyed writing it. If you have any questions or suggestions, feel free to drop a comment!

Git tricks 2/3

Facundo Botta — Sat, 29 Mar 2025 10:19:09 +0000

Hi! I'm back with the second part of this series. Sorry for the delay. I don't have a lot of experience writing posts, and it takes me a moment. 😆 In this post, I want to share more cool Git commands and use cases inspired by my experience. I hope you enjoy it!

By the way, I generated an image for the post with Mistral to have a cool banner picture. 😅 Let me know what you think!

Git stash

The git stash command is incredibly useful when you need to switch contexts but don't want to commit your current changes. It allows you to save your changes temporarily and come back to them later.

# Stash your current changes
$ git stash

# List all stashes
$ git stash list

# Apply the most recent stash
$ git stash apply

# Apply a specific stash
$ git stash apply stash@{1}

# Drop the most recent stash
$ git stash drop

# Drop a specific stash
$ git stash drop stash@{1}

# Clear all stashes
$ git stash clear

Git cherry-pick

Sometimes, you might want to apply a specific commit from one branch to another. The git cherry-pick command allows you to do just that.

# Cherry-pick a specific commit
$ git cherry-pick <commit_id>

# Cherry-pick a range of commits
$ git cherry-pick <start_commit_id>^..<end_commit_id>

Git bisect

git bisect is a powerful tool for finding the commit that introduced a bug. It uses a binary search algorithm to help you identify the problematic commit efficiently.

# Start bisecting
$ git bisect start

# Mark the current commit as bad
$ git bisect bad

# Mark a known good commit
$ git bisect good <commit_id>

# Git will check out a commit in the middle. Test it and mark it as good or bad.
$ git bisect good  # or
$ git bisect bad

# Continue this process until Git finds the first bad commit.

# Reset bisecting
$ git bisect reset

Git tag

Tagging is useful for marking specific points in your repository’s history as important. Typically, this is used to mark release points (e.g., v1.0.0).

# Create a lightweight tag
$ git tag <tagname>

# Create an annotated tag
$ git tag -a <tagname> -m "Tag message"

# Push a tag to the remote repository
$ git push origin <tagname>

# Push all tags to the remote repository
$ git push --tags

# List all tags
$ git tag

# Delete a local tag
$ git tag -d <tagname>

# Delete a remote tag
$ git push origin :refs/tags/<tagname>

Git diff

The git diff command shows the differences between commits, branches, files, and more. It’s a crucial tool for understanding what changes have been made.

# Show changes in the working directory that are not yet staged
$ git diff

# Show changes between the index and the last commit
$ git diff --cached

# Show changes between two commits
$ git diff <commit_id_1> <commit_id_2>

# Show changes between two branches
$ git diff <branch_1> <branch_2>

# Show changes in a specific file
$ git diff <file>

Git blame

The git blame command annotates each line in the given file with information about the last modification. This can be helpful for understanding who made specific changes and when.

# Show the last modification for each line of a file
$ git blame <file>

# Show the last modification for each line of a file at a specific commit
$ git blame <commit_id> -- <file>

Git commit --amend

The git commit --amend command is a lifesaver when you need to make changes to your most recent commit. Whether you forgot to add a file, made a typo in the commit message, or need to adjust the changes, --amend allows you to modify the last commit without creating a new one.

Use Cases

Fixing Commit Messages: If you realize you made a typo or want to provide more context in your commit message, you can amend it.
Adding Forgotten Files: If you forgot to add a file to the last commit, you can stage it and amend the commit to include it.
Modifying Changes: If you need to make minor adjustments to the changes in the last commit, you can do so and amend the commit.

How to Use

# Make your changes (e.g., edit files, add new files)
$ git add <file>

# Amend the last commit
$ git commit --amend

When you run git commit --amend, your default text editor will open with the previous commit message. You can edit the message if needed, save, and close the editor. The commit will be updated with your changes.

Important Notes

Avoid Amending Published Commits: If the commit you want to amend has already been pushed to a shared repository, avoid using -amend. Amending a published commit can rewrite history and cause issues for others who have based their work on the original commit.
Force Push: If you must amend a published commit, you will need to force push the changes to the remote repository. Be cautious with this, as it can overwrite history.

# Force push the amended commit
$ git push --force

Saving Disk Space with `git clone --depth=1`

When working with large repsitories, cloning the entire history can consume a significant amount of disk space. Fortunately, Git provides a way to clone only the latest commit, which can save you a lot of space and time. This is particularly useful when you only need the most recent version of the code.

Use Case

Large Repositories: If you're working with a repository that has a long history and many large files, cloning the entire history can be time-consuming and disk-intensive.
CI/CD Pipelines: In continuous integration and deployment pipelines, you often only need the latest code to build and test. Cloning the entire history is unnecessary and can slow down the process.

How to Use

The --depth option in git clone allows you to specify how many commits you want to clone. Setting --depth=1 clones only the latest commit.

# Clone only the latest commit of a repository
$ git clone <repo> --depth=1

Important Notes

Shallow Clones: Cloning with -depth=1 creates a shallow clone. This means you won't have the full history of the repository, which can limit some Git operations that rely on the complete history.
Fetching More History: If you later decide you need more history, you can fetch additional commits using the git fetch command with the -depth option.

# Fetch more history (e.g., the last 10 commits)
$ git fetch --depth=10

Unshallowing: If you need to convert a shallow clone to a full clone, you can use the git fetch --unshallow command.

# Convert a shallow clone to a full clone
$ git fetch --unshallow

Conclusion

I tried to cover real-world scenario examples from my experience to show you some of Git's tools that can be useful. In the next and final post of this series, I will talk about workflows and more real-world use cases. I'm looking forward to your comments and I hope you've learned something! If you have any recommendations or corrections, please let me know!

Thanks for reading, and see you next time!

Git tricks 🚀 1/3

Facundo Botta — Sun, 15 Dec 2024 16:50:12 +0000

Hi there! Today I want to share with you some cool git tricks that I recently learned from a book, “Aprendiendo Git & GitHub” (Learning Git & GitHub), and maybe it can be interesting to someone, and it's also a self-recap for me. I will split the post into three parts for a better reading and writing experience.

In this book, we can find many pieces of advice and mentions of the importance of key concepts in the Git world, like good commit messages, descriptive PRs, and more. But here, I only want to share some useful commands I’ve learned. I’m at a trainee/junior level, so don’t judge me too harshly if the topics here are basic to you! Maybe you’ll learn something anyway 🤣. So, let's go on...

Git config

git config allows to us to personalize somes core aspects of our git installation.

You can list your current config like this :

# To see all your config
$ git config --list
# To see only your global scope config
$ git congit --global --list
# To see your local scope config
$ git config --local --list
# To see your system config
$ git config --system --list

# You can add the --show-scope parameter to see the scope of any config
# only available from 2.26.0 version of git
$ git config --list --show-scope

# You will see something like this
# system  diff.astextplain.textconv=astextplain
# system  filter.lfs.clean=git-lfs clean -- %f
# system  filter.lfs.smudge=git-lfs smudge -- %f
# system  filter.lfs.process=git-lfs filter-process
# system  filter.lfs.required=true
# system  http.sslbackend=openssl
# system  http.sslcainfo=C:/Program Files/Git/mingw64/etc/ssl/certs/ca-bundle.crt
# system  core.autocrlf=true
# system  core.fscache=true
# system  core.symlinks=false
# system  core.editor=nano.exe
# system  pull.rebase=false
# system  credential.helper=manager
# system  credential.https://dev.azure.com.usehttppath=true
# system  init.defaultbranch=main
# global  user.email=myMail@gmail.com
# global  user.name=MyName
# global  safe.directory=C:/xampp/htdocs

You can change some configuration like, for example, the default text editor…

$ git config --global core.editor "code"

Here we tell Git that we want VS Code as our global default text editor instead of the nano editor. You can specify another scope or text editor if you want to.

An other interesting thing you can do is set a global gitignore

$ git config --global core.excludefile path_to_the_file/.gitignore_global

Git checkout & git switch

We often use the checkout command to create and/or switch between branches in Git repositories.

It’s fine, but in fact, the checkout command is an old and powerful command that can do more things than just switching branches:

# Switch to a specific branch
$ git checkout <existing_branch_name>

# Create and switch to a new branch
$ git checkout -b <new_branch_name>

# Restore a file or many
# (Note: if you don't use the -- directive you are creating a new branch...)
# It will to restore the file to its state in the last commit
$ git checkout -- <file_1> <file_2> ...

# Restore a file to a specific commit state
$ git checkout <commit_id> -- <file>

# Switch to a specific commit
# Note: If you do this, you won't be on any branch. This state is called "detached HEAD."
# Any changes you make here can be lost because HEAD is not attached to a branch.
# To save your changes, you need to create a new branch from this point.
# In other words, you are not working on any branch at this moment.
$ git checkout <commit_id>

# Restore all the working tree
# It will to restore all to its state in the last commit
$ git checkout .

As you can see, the checkout command can do many things, and we may be doing something that we actually don’t want to do…

To solve these potential confusions, Git introduced the switch command in version ≥2.23:

# Switch to a specific branch
$ git switch <branch_name>

# Create and switch to a new branch
$ git switch -c <new_branch_name>

So to restore one o more files to the last commit state we have de restore command:

# Restore une o more files
$ git restore <file1>, <file2>
# Restore all working tree
$ git restore .
# Restore all files with js expension
$ git restore '*.js'
# Restore a file to a specific commit state
$ git restore --source <commit> <file>

Git reset

If you accidentally add one or more files into the stashing area, you can run the reset command to solve this problem:

# Exit a file from the staging area
$ git reset <file>

Git reset allows you to restore your branch to a specific commit

# Go back to the previous commit and SAVE THE CHANGES 😉
$ git reset --soft HEAD~1

# Go back to the previous commit and DISCARD ALL the changes
$ git reset --hard HEAD~1

# Go back to the second commit in this relative position
$ git reset --hard HEAD~2

# Reset the branch to the remote repo state
# WARNING: This will eliminate your local commits!
$ git reset --hard origin/<branch_name>

I use this git reset when working on a feature or issue in my local branch, I might make several progressive commits, but I prefer not to "clutter" the commit history of the main branch with these intermediate commits. Instead, I aim to deliver a clean and concise PR with a single, well-organized commit.

This approach ensures that only one commit is added to the main branch's history, making it easier for the team or the person responsible for reviewing and merging the PR.

# Here we see only the commits in my local branch
$ git log --oneline --no-merges --branches --not --remotes

0f56980 (HEAD -> preprod) add_FTP_to_GA
1342e47 update_GA

# So, I want only one commit
# First, we reset to the last commit
# ⚠️ use --soft !! 😂
$ git reset --soft HEAD~2

# Then we can do a new sigle commit
$ git commit -m 'Add FTP integration and update GA configuration'

# And now we have only one commit
$ git log --oneline --no-merges --branches --not --remotes

e6bc2e1 (HEAD -> preprod) Add FTP integration and update GA configuration

Git rm

Imagine you added a .env file, committed it, and then realized you forgot to add it to .gitignore... maybe it's not too hard to imagine 🤣.

To fix this, you can use the git rm command. While rm itself is a shell command, git rm is part of Git and provides additional functionality to help us manage files in our repository

# Remove the file from the repository but KEEP it locally
$ git rm --cached .env

# Add it to .gitignore to ensure it's ignored in the future
$ echo ".env" >> .gitignore

# Commit the changes
$ git add .gitignore
$ git commit -m "Remove .env and add it to .gitignore"

Note if you already push le .env file to your remote repo, is always recommended to update yours sensitives keys because one’s the .env file is in the remote repo this information can maybe already by exposed…

Git rebase

The git rebase command is particularly useful when you want to keep your branch up-to-date with the main branch without introducing unnecessary merge commits. For example, if you're working on a feature branch (feature-branch) and the main branch (main) has received updates, you can use git rebase to synchronize your branch with the latest changes. This repositions your commits so they appear as if they were made directly after the latest commits in main, creating a cleaner and more linear history.

This approach makes the commit history easier to read and avoids introducing extra merge commits. It’s especially helpful when collaborating in teams, as it minimizes potential conflicts and simplifies the process of merging your changes back into the main branch.

# In your feature-branch
$ git pull --rebase origin main
# or
$ git fetch origin
$ git rebase origin/main

To ilustrate the situation :

with rebase : A---B---C---D'---E'---F’

without rebase : A---B---C---Merge---D---E---F

Another use case for git rebase is when you want to modify your local branch's commit history before publishing it. It’s important to note that you should avoid making this type of modification if your branch has already been published, as it can generate conflicts by overwriting the existing commit history. You can squash multiple commits into one or change the commit’s messages and more.

# Here, -i is for interactive rebase
# HEAD~4 tells Git that we want to rebase the last 4 commits
$ git rebase -i HEAD~4

# In your text editor, you will see something like this:
pick <hash> Commit message A
pick <hash> Commit message B
pick <hash> Commit message C
pick <hash> Commit message D

# Now, you can modify the commit history:
# - 'reword' allows you to change the commit message of one or more commits.
# - 'squash' tells Git to combine commits into one.

# Example: Changing the message of the second commit and squashing the last two commits into one.
pick <hash> Commit message A
reword <hash> Commit message B  # Change the message of this commit
squash <hash> Commit message C  # Combine this commit with the previous one
squash <hash> Commit message D  # Combine this commit with the previous one

# After saving and closing the editor:
# - If you used 'reword', Git will open an editor to change the commit message.
# - If you used 'squash', Git will prompt you to combine the commit messages.

# This way, you can clean up your commit history, making it more concise and readable before pushing or creating a PR.

I invite you to see more details in the documentation https://git-scm.com/docs/git-rebase

Conclusion

I think that's enough for this post. I have more things to share, but I'll save them for the next one. I'm looking forward to your comments and I hope you've learned something! If you have any recommendations or corrections, please let me know!

Thanks for reading, and see you next time!

Meta Data in React

Facundo Botta — Wed, 10 Apr 2024 18:34:23 +0000

Hello! Today I want to delve into a crucial but often overlooked aspect of web development: SEO (Search Engine Optimization) and how we can improve the visibility of our React web applications through dynamic meta-data.

As many of you may know, React is a powerful tool for building interactive and dynamic web applications. However, one of its limitations is its performance in terms of SEO, especially if you are working with client-side rendering. This is due to the behavior of the virtual DOM and how it renders on the page.

When search engines crawl a website, they prefer static and well-structured content. However, React generates content dynamically on the client side using JavaScript, which can result in indexing issues for search engines.

One way to address this issue is through the manipulation of meta-data, such as page titles, descriptions, and more meta tags, for each page of our application. This not only helps search engines understand and rank our content but also enhances the user experience by providing accurate and relevant information in search results.

A common way to implement dynamic meta-data in a React application is through the use of libraries like Helmet. Helmet allows us to manipulate meta-tags programmatically, greatly simplifying the process and freeing us from the need to manually update each page.

In this post, I want to share with you how I've used it to significantly improve the SEO of my applications.

Installation
After React Helmet encountered certain difficulties in updating tags for social media, React Helmet Async emerged as a fork of React Helmet. This new library was established as a more reliable and robust solution for handling dynamic meta-tags updates. Therefore, it is recommended to use it over the original version of React Helmet to ensure consistent and optimal behavior in managing meta-data.
So first, we need to install it with our package manager. In my case, I'm using npm, so:

npm i react-helmet-async

Implementation

Now you must wrap your application with the HelmetProvider component. In my case, it looks like this:

import AnimatedRoutes from './AnimatedRoutes.js';
import Header from './Header.js';
import Footer from './Footer';
import { HelmetProvider } from 'react-helmet-async';

function App () {
  return (
    <HelmetProvider>
      <Header />
      <AnimatedRoutes/>
      <Footer />
    </HelmetProvider>
  );
}

export default App;

So on each of your pages, you can import a Helmet component and declare each necessary meta-tag for that page within it. But why not leave that logic to a component, let's call it 'MetaTags', and have more concise and maintainable code?


import React from 'react';
import { Helmet } from 'react-helmet-async';

// You can have more props. In my case, these are enough.
function MetaTags ({ title = '', description = '', image = '', name = '' }) {
  return (
        <Helmet>
            { /* Standard metadata tags */ }
            <title>{title}</title>
            <link rel='canonical' href={ window.location.href } />
            <meta name='description' content={description} />
            { /* Open Graph tags (OG) */ }
            <meta property="og:url" content={window.location.href} />
            <meta property="og:type" content="website" />
            <meta property="og:title" content={title} />
            <meta property="og:description" content={description} />
            {/* OG image tags */}
            <meta property="og:image" content={image} />
            <meta property="og:image:secure_url" content={image} />
            <meta property="og:image:type" content="image/jpeg" />
            <meta property="og:image:width" content="200" />
            <meta property="og:image:alt" content={`Image of ${title} site`} />
            { /* Twitter tags */ }
            <meta name="twitter:creator" content={name} />
            <meta name="twitter:card" content="summary" />
            <meta name="twitter:title" content={title} />
            <meta name="twitter:description" content={description} />
        </Helmet>
  );
}

export default MetaTags;

Open Graph is a protocol developed by Facebook that allows us to control how our shared content appears on social media platforms. It is used by Facebook, LinkedIn, TikTok, and many others. However, Twitter has its own protocol for setting up its meta-tags. You can find more information about these protocols on their official websites:
Open Graph
Twitter Tags

Now we only need to place a MetaTag component on each page to have all our meta-data configured:

import React from 'react';
import MetaTags from '../components/MetaTags';

// Example page
function MetaExample () {
  return (
        <>
            <MetaTags
                title='Meta Example'
                description='This is a test description to show you how to improve SEO in your React web applications!'
                image='url to the image'
                name='FacuDev'
            />
            <div>MetaExample</div>
        </>
  );
}

export default MetaExample;

To verify the functionality of our meta-tags, we can use a Google Chrome extension such as "META SEO Inspector":

If you are hosting your site, you can see how the social cards look using the Facebook Card Validator and by simply making a post on your Twitter account. Twitter has its own card validator, but it's no longer functional, so you have to simulate a post to see it.

Conclusion
We have seen a simple way to manage our meta-data to provide better performance in our SEO. I consider this a crucial aspect if we are working with single-page applications and client-side rendering where this aspect is more affected.
I hope this post has been helpful to someone, and you can suggest changes or ideas!

Auto-size </h1> Facundo Botta — Mon, 01 Apr 2024 09:44:22 +0000 Hi! Recently, in one of my React projects, I had to use a textarea for my contact form, and this time I wasn't willing to accept its default behavior... So here I show you the solution I found to give our component the auto-sizing property. 1. So, first we have to create the basic TextArea component and set some styles for it: <div class="highlight js-code-highlight"> <pre class="highlight javascript"><code>import React from 'react'; const TextArea = () => { const styles = { width: '100%', height: '70px', padding: '10px', outline: 'none', resize: 'none', borderRadius: '5px', scrollbarWidth: 'none', // Firefox '-ms-overflow-style': 'none', '::-webkit-scrollbar': { width: '0px' } }; return ( <textarea style={styles} /> ); }; export default TextArea; </code></pre> </div> You can set more styles or pass them as props if you want to. 2. Now, to use it, we have to import it: <div class="highlight js-code-highlight"> <pre class="highlight javascript"><code>import TextArea from '../components/TextArea'; import React, { useRef } from 'react'; function YourParentComponent () { const textAreaRef = useRef(null); return ( <TextArea ref={textAreaRef} placeHolder={'I'm a auto-size textarea'} minHeight={'100px'} /> ); }; </code></pre> </div> You can set a placeholder or more options with props. To access the value of our TextArea, we have to use the useRef hook and then pass the ref to the component, so we have to modify it a little: <div class="highlight js-code-highlight"> <pre class="highlight javascript"><code>import React from 'react'; // Thanks to the react's function forwardRef() // we can give a external ref to our component. const TextArea = forwardRef(( {minHeight = '50px', placeHolder}, ref) => { const styles = { width: '100%', minHeight, padding: '10px', outline: 'none', resize: 'none', borderRadius: '5px', scrollbarWidth: 'none', // Firefox '-ms-overflow-style': 'none', '::-webkit-scrollbar': { width: '0px' } }; return ( <textarea ref={ref} style={styles} placeHolder={placeHolder} /> ); }); export default TextArea; </code></pre> </div> 3. Now we can set the behavior of auto-sizing: <div class="highlight js-code-highlight"> <pre class="highlight javascript"><code>// This simple function sets the textarea's height to its scrollHeight value. const handleHeight = (e) => { e.target.style.height = minHeight; e.target.style.height = `${e.target.scrollHeight}px`; }; // So we just have to call this function when the textarea's value changes. return ( <textarea ref={ref} style={styles} placeHolder={placeHolder} onChange={(e) => handleHeight(e)} /> </code></pre> </div> And that's it! Now our textarea is more user-friendly, in my opinion: <a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fsnoj2we7pbrtywvl3km3.gif" class="article-body-image-wrapper"></a> In my case, I'm using it with a default value taken from the database. So, you have to set the defaultValue and add a useEffect() to set the height on the first render. So, finally, the TextArea component looks like this: <div class="highlight js-code-highlight"> <pre class="highlight javascript"><code> import React, { useEffect, forwardRef } from 'react'; const TextArea = forwardRef(({ minHeight = '50px', content = '', placeholder = '' }, ref) => { useEffect(() => { if (ref.current) { ref.current.style.height = `${ref.current.scrollHeight}px`; } }, [content, ref]); const handleHeight = (e) => { e.target.style.height = minHeight; e.target.style.height = `${e.target.scrollHeight}px`; }; const styles = { width: '100%', height: '70px', padding: '10px', outline: 'none', resize: 'none', fontSize: '18px', borderRadius: '5px', minHeight: minHeight, scrollbarWidth: 'none', // Firefox '-ms-overflow-style': 'none', '::-webkit-scrollbar': { width: '0px' } }; return ( <textarea ref={ref} style={styles} defaultValue={content} placeholder={placeholder} onChange={(e) => handleHeight(e)} /> ); }); export default TextArea; </code></pre> </div> Only as an example, I'll show you how to retrieve the value, but you can set this value in a FormData object in your form's submit function, for instance. <div class="highlight js-code-highlight"> <pre class="highlight javascript"><code>// In your parent component. const takeValue = () => { console.log(textAreaRef.current.value); }; takeValue(); </code></pre> </div> If you're working with JavaScript and not using React, you can apply the same logic as the handleHeight() function, and instead of using useRef(), you can take the textarea element by its id with getElementById('your_textarea_id'). I hope the post has been helpful for you, and feel free to ask me any questions or leave comments! </article> </main></body></html>

DEV Community: Facundo Botta

JavaScript - Things

Introduction

true + false === 1

!!"" === false

+true === 1

true == "true" // false

null + 0 === 0

if ([] == false) → true but if ([]) → true

0.1 + 0.2 !== 0.3

NaN !== NaN

'5' - 3 === 2 but '5' + 2 === '53'

'' == 0 -> true

0/0 -> NaN

[1,2,3] + [4,5,6] // -> "1,2,34,5,6"

Conclution

Git 3-3 - Workflows

What is a Git workflow?

Git Flow

main branch

development branch

hot-fix branches

release branches

So where do we actually do the work?

Example

When to Use Git Flow

GitHub Flow

Example

When to Use GitHub Flow

Trunk-Based Development

Core Concepts

But... It seems the same as GitHub Flow 😄

Development Worflow

Handling New features

When to Use

Ship / Show / Ask

1. Ship

2. Show

3. Ask

What about branches?

When to Use Ship/Show/Ask

Conclusion

Git tricks 2/3

Git stash

Git cherry-pick

Git bisect

Git tag

Git diff

Git blame

Git commit --amend

Use Cases

How to Use

Important Notes

Saving Disk Space with git clone --depth=1

Use Case

How to Use

Important Notes

Conclusion

Git tricks 🚀 1/3

Git config

Git checkout & git switch

Git reset

Git rm

Git rebase

Conclusion

Meta Data in React

`true + false === 1`

`!!"" === false`

`+true === 1`

`true == "true" // false`

`null + 0 === 0`

`if ([] == false) → true` but `if ([]) → true`

`0.1 + 0.2 !== 0.3`

`NaN !== NaN`

`'5' - 3 === 2` but `'5' + 2 === '53'`

`'' == 0 -> true`

`0/0 -> NaN`

`[1,2,3] + [4,5,6] // -> "1,2,34,5,6"`

Saving Disk Space with `git clone --depth=1`