DEV Community: Ilê Caian

Eryn - React Native Template

Ilê Caian — Tue, 26 Jan 2021 15:55:04 +0000

Always starting a project with React Native leads me to make some changes and make choices on how it should be structured. In general, I think in:

Directories Structure
Common Libraries
Libraries Configuration

Even tho some choices can vary between projects, some of them are constant. I noticed then that I could create a template for making life easier and simple, yet still keep offering a place for dealing with the different kinds of projects that could appear.

I also noticed that I could create a "foundation" for all those who also wanted to use this template at this peak, leaving the project and architectural choices with documentation and some more general Q&A about my vision related to the project structure.

So, I present you 🌲Eryn Template! A React Native Template that could be used directly with the CLI and gives you the support to scale your application and let it open to community contributions! Use it with the command:

$ npx react-native init MyProject --template react-native-template-eryn

References

Yarn + NodeJS LTS with Homebrew

Ilê Caian — Fri, 03 Apr 2020 13:34:40 +0000

The last Yarn version in Homebrew uses a non-LTS version (15) of NodeJS as its dependency. If this is an issue for you as it is for me, I just managed to accomplish use Yarn with the latest LTS version of NodeJS.

I created a gist for it and here are the following steps

Uninstall Yarn and Node

$ brew uninstall yarn
$ brew uninstall node

Install the latest LTS version of Node

$ brew install node@12

Create the Symlink for it

$ ln -s /usr/local/opt/node@12 /usr/local/opt/node

Install Yarn without its dependencies

$ brew install yarn --ignore-dependencies

And that's it!

If you want to check the versions of each package, just run

echo "Yarn Version: $(yarn --version)"
echo "Node Version: $(node --version)"

Cover Photo by Sereja Ris on Unsplash

The JS equality comparison issue

Ilê Caian — Mon, 30 Mar 2020 14:25:18 +0000

As a common starting point of learning programming languages, one of the first things to do is discover the basic types of that language. Using them to store information as variables or even creating more complex data types, in general, all languages share some simple data types between them

Numbers: 1, 2, -4, 4.2
Text: "John Doe", "Insert your age"
Lists: ["the list has", 3, "elements"]
Boolean: true/false

There are more basic types considered essential for storing information depending on each choice of language but for now, those types can fill all the needs to the reader.

Another common knowledge that a developer aspires to acquire in a new language is compare things. Compare information during the execution of the program and do things based on the result of the comparision is essential software development. Those comparisons can happen using the so-called if-statement and passing a comparison using one of the comparisons operators

var name = "John"

if (name == "John") {
  console.log("Hi, I'm John!") // output => "Hi, I'm John!"
}

The result of one comparison always evaluates a Boolean value: true or false. The actual comparison can be between anything and will always check if those values respect the comparison operator rule. The == is called the equality operator and compares if both values are equal and result in true if they are, and false if don't.

Photo by Annie Spratt on Unsplash

What can be compared?

JavaScript is a language born with some features (or flaws 🤔). As JavaScript born to be a language to run inside the Browser and used by doing things across the page filled with text in it, one of the == features is

Compare if two values are equal, not considering if they are Numbers or Text.

This feature results in a strange behavior that confuses more than help. An example of this is the following code resulting in a valid comparison

var age = "12"

if (age == 12) {
  console.log("I'm 12 years old!") // output => "I'm 12 years old!"
}

And will log the text "I'm 12 years old!". At first sight, this is not a real problem but this can result in strange behaviors. Check the following code and guess what will be the result

var age = "12"

if (age == 12) {
  age = age + 1
}
console.log(age) // output => ???

The result should be

Number 13
Text "13"
Text "121"

The result is the answer 3: "121". Why?

The + operator behaves like a common sum for Numbers and like a concatenation operator for Text, even if one of the parts is a Number. The following example helps to understand how that works

var firstName = "John"
var lastName = "Doe"
var age = 12

var fullName = firstName + " " + lastName // => "John Doe"
var olderAge = 12 + 1 // => 13

But what about the === operator?

After acknowledging this behavior with the == operator, JavaScript received a new 'comparison' operator: === or the triple equality operator. With this operator, it is possible to compare the value and if both of them are the same basic type.

This guarantees that the following code will only execute if the age variable is a Number with the value of 12

var age = "12"

if (age === 12) {
  age = age + 1
}
console.log(age) // output => "12"

And the final log will print just the "12" value, as the age variable is a Text and not a Number, even respecting that age variable has the "12" value.

There are more issues with the == operator that will not be covered here but as a small example of them, there is a comparison of undefined and null and what they evaluate

undefined == null // => true
undefined === null // => false

Photo by Kelly Sikkema on Unsplash

What operator should I use?

Here is the common ground: Always use the === (triple equal) operator.

It is equivalent to == in all other languages like Python, C/C++, Ruby, or Java. And in JS, there's always a good chance of using the == (double equal) operator resulting in hidden bugs that will haunt the future developers as long as the software keeps running.

Did I miss or forgot something? Is there a thing that you think it's not clear or can be better explained? Feel free to reach me at the comment section or by message and discuss it!

References

Cover Photo by Charles "Duck" Unitas on Unsplash
Should I use === or == equality comparison operator in JavaScript? by Panu Pitkamaki
Equality table for == at MDN

Modules vs Classes - How to Manage Privacy in JS

Ilê Caian — Fri, 21 Feb 2020 17:05:53 +0000

The Object-Oriented Paradigm made a huge shake in the way developers think and write code even if you don't like it or don't like its premises. This not so new paradigm of encapsulating data and procedures in form of attributes and methods influenced a lot of recent languages even if some of them are not using it as its main paradigm.

Languages like: C++, Java, Python, and even JavaScript are considered and declared languages that implement the Object-Oriented Paradigm (OOP). As will be discussed, JavaScript has its own way of dealing with Objects with some specificities. But first, there is a starting point that should be discussed: there's one essential fact in JavaScript that goes in the wrong direction of OOP: non-existence of encapsulation.

There's a repo with some tests too! Check it out!

Classes and Objects

Classes are definitions of data-types: what data they will store/hide and how it should behave. An instance of one Class will be able to execute functions as methods and store data as attributes. Those instances are the so-called Objects that lives inside the runtime execution of a program.

Photo by Dan Dimmock on Unsplash

One of the important features in OOP is the fact that the Objects should have the ability to encapsulate(hide) its data. That means that if someone tries accessing some information from the Object, it should not be able to do it if the Class says so. Consider the following example:

Let's say that Elon Musk 🧑‍💼 created an awesome Trash Can that can perform 3 simple tasks:

Throw one 'junk' item into the Trash Can
Clean all items inside the Trash Can, all at once
One button that shows at the display if the Trash Can is fully empty or not

The interface for that TrashCan is something like:

TrashCan {
  throwAway(item);
  clean();
  isEmpty();
}

As JavaScript has the class keyword, it's possible to consider one implementation of this Trash as the following

class TrashCan {
  constructor() {
    this.items = [];
  }

  throwAway(item) {
    this.items = [...this.items, item];
  }

  clean() {
    this.items = [];
  }

  isEmpty() {
    return this.items.length === 0;
  }
}

var elonTrashCan = new TrashCan();

Now the elonTrashCan is empty and ready to start doing its work. But what happens with the execution of

elonTrashCan.throwAway('paper ball');
elonTrashCan.throwAway('empty Starbucks cup of coffee');
elonTrashCan.throwAway('empty package of Cookies');

elonTrashCan.clean();

elonTrashCan.items = ['SpaceX secret project'];

console.log(elonTrashCan.isEmpty()); // --> ???

Elon Musk 🧑‍💼 will be mad at us that we broke his Trash Can
elonTrashCan.isEmpty() will return false, because we defined elonTrashCan.items with 1 item inside
elonTrashCan.items is not accessible, so the elonTrashCan.isEmpty() call will returns true

The answer is option 2. It is possible to access items inside the Object instance even without explicit items declaration outside constructor.

Using that example and considering an ideal Object-Oriented language implementation, the execution of elonTrashCan.items should result in an error of the program trying to access a private attribute. In JavaScript, these calls are possible, valid ones, and results in no error.

So, isn't it possible to create Privacy in JavaScript? Is there a way of hiding data from outside the Object and exposing just public data?

Photo by Folco Masi on Unsplash

Module Pattern

The good news is there's one behavior in JavaScript that provides something related to privacy: Closures. There's this post written about Closures in case of interest

Closures in JS and Why It Matters

Ilê Caian ・ Feb 6 '20

#javascript #tutorial

Using Closures for hiding variables and functions is a good approach for encapsulate data inside one instance and just expose the desired interface of it.

But how do actually this works?

Let's create the same Elon Musk 🧑‍💼 TrashCan Object writing a Function and returning just the public interface of it as the following code

const TrashCan = () => {
  let items = [];

  const throwAway = item => {
    items = [...items, item];
  }

  const clean = () => {
    items = [];
  }

  const isEmpty = () => {
    return items.length === 0;
  }

  return {
    throwAway,
    clean,
    isEmpty,
  }
}

var elonTrashCan = TrashCan();

And for the new elonTrashCan let's try to execute the same code as above

elonTrashCan.throwAway('paper ball');
elonTrashCan.throwAway('empty Starbucks cup of coffee');
elonTrashCan.throwAway('empty package of Cookies');

elonTrashCan.clean();

elonTrashCan.items = ['SpaceX secret project'];

console.log(elonTrashCan.isEmpty()); // --> ???

Elon Musk 🧑‍💼 will be even madder at us that we broke his second Trash Can
elonTrashCan.isEmpty() will return false, because we again defined elonTrashCan.items with 1 item inside
elonTrashCan.items is not accessible, so the elonTrashCan.isEmpty() call will returns true

Actually something very strange happens:

elonTrashCan.isEmpty() returns false because our internal items are empty
elonTrashCan.items has 1 item in it

Photo by Scott Gummerson on Unsplash

Using this approach, it is possible to 'limit' the outside world on accessing just the desired interface and has hidden content inside it. On the other hand, JavaScript lets the definition of new properties in runtime execution, even with the same names used by its Closure.

The code inside of the Closure will not depend on those new properties, as the original ones are stored inside that Closure, unaccessible. And, the original mission is now accomplished: Privacy. The Module Pattern is viable for attributes and can be used for hiding methods too.

For the side-effect with the creation of new properties, it's hardly suggested not to change the original interface and even make some tests before using those properties like

if(typeof elonTrashCan.items === 'undefined') {
  console.log('No exposed items!') // --> No exposed items!
}

Wrap up

After some discussion about the Object-Oriented Paradigm and the Class implementation of JavaScript, maybe the JS Class is not the best choice for creating Objects with private data if you are not using a transpiler like Babel.

Using Closures and the Module Pattern it is possible to accomplish Privacy in JavaScript in a simple and reusable way. If the class implementation is inevitable, consider using a transpiler or a more robust approach with some use of the Module Pattern. The use of transpilers is hardly incouraged!

Even with some apparent losses like inheritance, there are still valid ways of implementing that benefits even with Modules.

Did I miss something? Is there a thing that you think it's not clear? Feel free to reach me at the comment section or by message and discuss it!

References

Cover Photo by Ciprian Boiciuc on Unsplash
Article at MDN about Class fields(attributes) options
Closures in JS and Why It Matters
Babel
GitHub repo with tests

Closures in JS and Why It Matters

Ilê Caian — Thu, 06 Feb 2020 17:00:40 +0000

One of the main features when a developer writes JavaScript code is maybe the one most unknown by them. Maybe this happens just because no one writes code thinking directly or even knowing that the reason their code doesn't break is related to this feature.

But what is that feature?

Well... it is not a feature actually. It is a side-effect of how JavaScript is built and how it 'compile', run and executes. Let's dig in with an example.

Running the following in the browser dev tools will result in

var age = 14;

function getOlder() {
  var age = 14;
  age++;
};

getOlder();

console.log(`I am ${age} years old.`); // <-- ???

It breaks (🤷)
Print I am 14 years old.
Print I am 15 years old.

The correct answer is 2: I am 14 years old.! But why?

Explaining the Execution

There is a lot of important information about AST (Abstract Syntax Tree) and how JS was conceived that will not be the case of study here but for the reader (check the References!), think like this:

When the Virtual Machine that runs inside your Browser (V8 in Chrome for example) executes the code it makes the naming resolution of each variable. This process of resolving the variables is required so while using a variable that is declared and defined it doesn't break your code. If the code tries to access some function or variable that is not properly defined yet it will output the famous:

Uncaught ReferenceError: yourVariable is not defined.

Photo by Mark de Rooij on Unsplash

Resolving Variables by Hand

If the result after naming resolution is accessible, the original code will be converted to something roughly similar to:

var global__age = 14;

function global__getOlder() {
  var getOlder__age = 14;
  getOlder__age++;
};

global__getOlder();

console.log(`I am ${global_age} years old.`); // --> 'I am 14 years old.'

Now it makes sense that the output is I am 14 years old., right? This prefix added is related to the Closure of each variable and method when the naming resolution happens. As can be observed, there are 2 Closures in this code:

global
getOlder

It can be noticed that the getOlder Closure is inside the global Closure but the variables inside the getOlder() original function are only accessible inside those brackets.

So, it makes much more sense saying that the getOlder__age variable only exists inside the global__getOlder() function. A good example to validate is trying to log the variable from inside the function, outside of it:

var global__age = 14;

function global__getOlder() {
  var getOlder__age = 14;
  getOlder__age++;
};

global__getOlder();

console.log(`I am ${getOlder__age} years old.`); // --> Error!

The resulted output is Uncaught ReferenceError: getOlder__age is not defined and the reason is that there is no variable with the naming resolved to global Closure valid for getOlder__age.

But what about the Scopes?

In the creation of a function, a Closure is created the same way as a Scope. All variables and functions inside that both are accessible to all child functions and not outside of it (except if they are exposed like it'll be discussed ahead).

Scope and Closure are almost equal but the second one has some 'super-powers': Variables and functions created inside the Closure and exposed will still work outside of it, even without the existence of Scope. This is a very tight line between those two concepts.

This is true even if those exposed items depends on other variables/functions inside the Closure but are not exposed.

Closures vs. Scopes

Using almost the same example as above with little changes in order to explain differences between these two concepts, the following code is a starting point

function main() {
  var age = 14;

  function getOlder() {
    age++;

    console.log(`I am ${age} years old now.`); // --> 'I am 15 years old.'
  };

  getOlder();
};

main();

With this example, the function getOlder() will be called inside the main() function and it'll print I am 15 years old now., correct? The variable age is inside the main scope and can be accessed by getOlder() function.

Returning the getOlder() function to the outside 'world' and executing it 3 times as the following example, what will be the result?

function main() {
  var age = 14;

  function getOlder() {
    age++;

    console.log(`I am ${age} years old now.`); // <-- ???
  };

  return getOlder;
};

var getOlder = main();

getOlder(); // <-- ???
getOlder(); // <-- ???
getOlder(); // <-- ???

Nothing. The code will break.
3 times I am 15 years old now.
The value of the age variable will still increase from 15, to 16, and then to 17.

The correct answer is answer 3.

But why this happens?

Every time a Closure is created, all the variables and functions are stored inside its state. Even after the end of execution of the main() function, the respective Closure state is still alive storing variables and functions!

Maybe the most awesome part of it is: the age variable is lost inside that main() Closure and is not accessible outside of it! If the next part of the code tries accessing that age variable, it'll result in the already discussed Uncaught ReferenceError: age is not defined error, as this variable doesn't exist outside the main() function!

Photo by Maria Teneva on Unsplash

Wrap up

Some awesome differences between Closure and Scope concepts were discussed:

Closures always store state about its variables and functions
It is possible to expose some, all or none of those variables/functions by returning them at the end of the function that creates the Closure
It is possible to even redefine some outside variables/functions inside the Closure with the same name and the Virtual Machine compiler will take care of it, avoiding errors in runtime and name collisions

Is this article useful for you? Did I miss something while explaining? Please, let me know in the comment section or send me a message!