DEV Community: Santiago Correa

I built "Never Schlafen"

Santiago Correa — Sun, 11 Jan 2026 16:27:35 +0000

Hey peeps,

I built this site called Never Schlafen. It’s a simple utility that keeps your screen from going to sleep, but I added a few extras to make it more of an experience.

Most wake-lock tools are just a button, but I wanted something that looks good on a second monitor or even in a different window while I'm focused on other things.

What you can do with it:

Choose from several animated themes (Cyber, Aurora, Fireplace, etc.).
Listen to Lofi or paste your own YouTube links.
Play some mini-games (Snake, Flappy Bird, Breakout) when you need a break.
Hide everything except the background and a clock with Zen Mode.

It’s totally free and open for feedback.

Check it out: https://never-schlafen.online/

Let me know what you think or if you have any theme ideas!

Want a cool new theme for VS CODE?

Santiago Correa — Thu, 13 May 2021 01:10:52 +0000

Hey there,

I'm just creating a simple short post for this, if you want to try a new theme I created and let me know what your thoughts are, that would be wonderful.

Theme

Accessibility and testing

Santiago Correa — Sat, 17 Apr 2021 00:17:14 +0000

Disclaimer: This is not going to tell you every single accessibility principle, but what you can start implementing or thinking about as soon as possible in terms of development.

You can read about W3C accessibility principles here.

Now to start off the article, I'm an accessibility lover! and I love to make all things accessible. This is the reason why I'm writing this article.

Let's define what accessibility is:

Accessibility is the practice of making your websites usable by as many people as possible according to MDN.

There is a ton of information about accessibility and I can make this article super super long, but I'm not going to do that to make a couple concepts more digestible.

Quick tips for your accessible website

Use semantic HTML

For example, let's say we need an element to open a modal, which one do you think is the most correct semantic element to use?

<a class="c-modal__open">Find out more</a>
<div class="c-modal__open">Find out more</div>
<button class="c-modal__open">Find out more</button>

The correct element would be a button, because of the following reasons:

A <button> tag is used to perform an action.
Buttons are keyboard accessible.

Why shouldn't you use an <a> tag or <div> tag

An <a> tag should be used for navigation.
A <div>tag is a generic container for flow content.

What if you need to navigate to another page, what would the correct element be?

You got it, an <a> tag because it should be used for navigation.

Keyboard Accessibility

People with motor function impairments use the keyboard (or other non-mouse features) to activate website functionality.

Let's go back to the modal example, I'm just going to mention one feature a modal should have:

User should be able to close the modal through keyboard. Either be it by using the ESC button, tabbing through or clicking on a close button.

If a user only used a keyboard or device that mocks a keyboard, they will be unable to exit the modal if you only implement click events.

Also, here is an example of an accessible modal.

Text alternatives for non-text content

For example:

Short equivalents for images, including icons, buttons, and graphics.
Description of data represented on charts, diagrams, and illustrations.
Brief descriptions of non-text content such as audio and video files.
Labels for form controls, input, and other user interface components.

Font

Size check more here
Color contrast

Testing

How can you test if your website is accessible, there are many tools, but some I use are:

Wave
Axe
Browser DevTools ( Chrome )
- Right Click > Lighthouse > Generate Report
Built in screen readers ( Mac Screen Reader )
ChromeVox Screen Reader Extension
Cross Browser testing, just to make sure same behavior is replicated everywhere
Good old tabbing, enter, spacing and so on
Color contrast checkers

Also, just a general tip, validate your markup and styles.

To validate HTML: https://validator.w3.org/
To validate CSS: http://jigsaw.w3.org/css-validator/

For code organization, make sure you lint your code by using a linter.

What is a linter? It is a static code analysis tool used to flag programming errors, bugs, stylistic errors and suspicious construct.

Popular linter: ESLINT.

Summary

Use semantic HTML.
Make sure your website is keyboard accessible.
Add text alternatives.
Question to ask: Is my font size readable for people with low vision or can this be adjusted?
Test your website or other websites and check if it's accessible.
Validate your HTML and CSS.
Lint your code.
There are so many resources (W3C, Google, MDN) and so on.

React Router - Route ( WTF Moment )

Santiago Correa — Fri, 16 Apr 2021 21:02:54 +0000

Recently I was working on a project which consisted of books, and I realized that my whole web app was mounting and unmounting instead of the components re-rendering.

More details:

The project consisted of 2 pages.

Here's a quick wireframe I whipped up:

Home
Search

I used react-router to create the navigation between pages.

What I didn't know, until I further read their documentation, is that if you use the prop component in <Route> it uses React.createElement to create a new React element from the given component.

That means if you provide an inline function to the component prop, you would create a new component every render. This results in the existing component unmounting and the new component mounting instead of just updating the existing component.

This caused undesired behavior which was when I was on the search page and updated the App state it would refresh everything and I would lose the state I had in the Search page.

Instead, to just make sure the component updates and doesn't mount and unmount when there is an update, use render.

<Route
  path='/'
  exact
  render={() => ( 
   <Home 
    currentlyReading={this.state.currentlyReading} 
    read={this.state.read}
    wantToRead={this.state.wantToRead}
    updateBookShelf={(book, shelf) => 
    this.updateBookShelf(book, shelf)} />
  )}
></Route>

<Route
  path='/'
  exact
  render={() => ( 
   <Search 
    allBooks={this.state.books}
    updateBookShelf={(book, shelf) => 
    this.updateBookShelf(book, shelf)} />
  )}
></Route>

Summary

Component unmounts and mounts a new component.
Render updates components, instead of unmounting and mounting.

JavaScript Scope

Santiago Correa — Mon, 12 Apr 2021 01:45:18 +0000

Scope in a programming language controls the visibility and lifetime of variables and parameters.

Another way of thinking about scope: The part of the program where a particular identifier is visible or accessible such as a variable or function name.

Why am I ranting about scope, well..., it's because of the following reasons:

Security. Variables can only be accessed from a certain area of the program.
Reduces naming collision. We can use the same variable name in different scopes.
Bugs. We all love bugs or do we? Getting to know a little bit more about scope will help you understand variable values or issues.

Before I get in to examples, we have to know what types of scope exist:

Global
Function
Block

Global
Any variable that is not inside a function or block ( a pair of curly braces ) is inside the global scope.

Function
Any variable that is declared inside a function can only be accessed within that function, that means you cannot access them from outside it.

Block
ES6 introduced let and const variables, unlike var, they can be scoped to the nearest pair of curly braces. That means they can't be accessed outside that pair.

Finally, how does JavaScript find the variable value.

Check current scope
Check outer scope
Check global scope

If it's still not able to find the variable, it will either implicitly declare the variable in the global scope or return an error.

Time for examples:

Global

var meow = 'Meow';

function cat () {
 return meow
}

// value returned by cat is 'Meow'
cat()

console.log(meow) // Prints 'Meow'

In this case, the variable meow will not return an error since it is in the global scope and is accessible everywhere since it is not function scoped or block scoped.

Function

function cat () {
  var meow = 'Meow';
  return meow
}

// value returned by cat is 'Meow'
cat()

console.log(meow) // Uncaught ReferenceError: meow is not defined

If we try to access meow outside of cat it will return a Uncaught ReferenceError: meow is not defined since meow is only accessible or visible in the function cat.

Block

if(true) {
  const cat = 'meow';
  var meow = 'Meowwwww!!!!';
  console.log(cat); // Prints 'meow'
}

console.log(cat); // Uncaught ReferenceError: cat is not defined

console.log(meow); // Prints 'Meowwwww!!!!'

So, what is going on here, the variable cat is bound to the if statement because of the curly braces or block scope.

In this case the variable cat if accessed outside the if statement will return an error as defined above but since meow is not block scoped it will return the expected value. Remember const and let variables are block scoped.

Summary

A scope is an area where a variable is visible and accessible.
Just like functions, scopes in JavaScript can be nested and the JavaScript engine traverses the scope chain ( how JavaScript looks for the variable ) to find the variables used in the program.

JavaScript Hoisting

Santiago Correa — Sun, 11 Apr 2021 02:58:16 +0000

JavaScript before executing your code parses it, and adds every function and variable declarations it finds to its own memory. This is called hoisting.

There are some different behaviors that occur when using a function declaration vs a function expression.

With function declarations, we can call a function before it’s defined, and our code will work. In the other case, we’ll have errors.

A general rule of thumb is to always define functions, variables, objects and classes before using them.

Suppose we have a function:

function cat() {
  alert("I'm a cat that meows!")
}

Due to hoisting, we can invoke cat() before it is declared:

cat()
function cat() {
  alert("I'm a cat that meows!")
}

This only happens with functions and not function expressions.

When you assign a function to a variable, that is a function expression:

cat()
var cat = function() {
  alert("I'm a cat that meows!")
}

In this case, the var declaration is hoisted and initialized with undefined as a value, something like this:

var cat = undefined
cat()
cat = function() {
  alert("I'm a cat that meows!")
}

Running this code will give you a TypeError: cat is not a function error.

const and let declarations are hoisted, too, but they are not initialized to undefined like var.

const cat = function cat() {
  alert("I'm a cat that meows!")
}

const cat = function () {
  alert("I'm a cat that meows!")
}

let cat = function cat() {
  alert("I'm a cat that meows!")
}

let cat = function () {
  alert("I'm a cat that meows!")
}

In this case, if you invoke cat() before declaring it, it will give you a ReferenceError: 'cat' is not defined error.

The same will happen for any other expression that assigns an object or class to a variable

Class declarations work like let and const declarations: they are hoisted, but not initialized, and using a class before its declaration will give a ReferenceError: is not defined error.

A simple tip:

If you are not re-assigning a variable value, it's better to use const, otherwise use let.

Example:

Don't do it

const meow = 'meow'
meow = 'meow, Angry cat!!!

This will not work - It will give you a SyntaxError: Invalid or unexpected token

Instead:

let meow = 'meow'
meow = 'meow, Angry cat!!!

Summary:

All function declarations are hoisted to the top of the current scope before any Javascript is executed.

We can call a function declaration before it’s defined, and our code will work.

function expressions are hoisted and initialized with undefined as a value, so this will give you an error.

If you are not re-assigning a variable value, it's better to use const, otherwise use let.

Core web vitals

Santiago Correa — Sun, 28 Mar 2021 22:51:56 +0000

In 2020 the Core Web Vitals are three metrics: Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS).

Each metric measures a different aspect of user experience: LCP measures perceived load speed and marks the point in the page load timeline when the page's main content has likely loaded.

FID measures responsiveness and quantifies the experience users feel when trying to first interact with the page; and CLS measures visual stability and quantifies the amount of unexpected layout shift of visible page content.

Each Core Web Vitals metric has associated thresholds, which categorize performance as either "good", "needs improvement", or "poor"

Largest Contentful Paint:

Good: <2500ms
Poor: >4000ms
Percentile: 75

First Input Delay:

Good: <100ms
Poor: >300ms
Percentile: 75

Cumulative Layout Shift:

Good: <0.1
Poor: >0.25
Percentile: 75

Additionally, to classify the overall performance of a page or site, google uses the 75th percentile value of all page views to that page or site. In other words, if at least 75 percent of page views to a site meet the "good" threshold, the site is classified as having "good" performance for that metric. Conversely, if at least 25 percent of page views meet the "poor" threshold, the site is classified as having "poor" performance. So, for example, a 75th percentile LCP of 2 seconds is classified as "good", while a 75th percentile LCP of 5 seconds is classified as "poor".