DEV Community: Fabio Russo

CSS input checker

Fabio Russo — Tue, 10 Jul 2018 10:28:57 +0000

Easy stuff... cool result

Here we're going to use:

:not()

The :not() CSS pseudo-class represents elements that do not match a list of selectors. Since it prevents specific items from being selected, it is known as the negation pseudo-class.

:placeholder-shown

The :placeholder-shown CSS pseudo-class represents any or element that is currently displaying placeholder text.

Check input with CSS

If we use those together with an input (with a placeholder), like this:

input:not(:placeholder-shown)

we can manage stuff on the page, we want to show, only when there's something in the input form, without using Javascript.

HTML


<input placeholder="My Placeholder">
<div class="text">Now... you can see me</div>

CSS


.text{
      opacity: 0;
     }

input:not(:placeholder-shown) + .text{
      opacity: 1;
     }

(The + selector will catch the .text placed immediately after the input)

With that we're hiding the .text, just to show it when input got no placeholder anymore, so, when we're writing over it!

Fast & easy... React states management in one function

Fabio Russo — Sat, 23 Jun 2018 15:28:33 +0000

Don't repeat the code...

In React, like anywhere else in your code, you must never repeat yourself unless it is strictly necessary (almost never).

Probably what you're going to read, it's easy stuff, but reading some code online, I thought about dealing with the subject ... I "apologize" to the experts for the banality.

Example...

We have to manage a text input tag, and make sure to memorize the value entered by the user, and show It somewhere, till it's changed again!

How do we do it in React?

We insert an onChange that updates the state of the component to the last input value ... and then we pass the value of the state to the input tag, or to any other tag on the page, to show the last input value.

To the code!


//we've a class... with a state defined

class App extends Component {
  constructor(props){
    super(props)
    this.state={
      myFirstState:"Labrador"
    }

//we're going to manage the changes, and setState() equal to the user input

   valueChange = (e) => {
      this.setState({myFirstState : e.target.value});
    }

//rendering time...we've an Input tag, with the state as value 
//and the function, calling to onChange

render() {
    return (
        <div className="just a class">
          <input placeholder="insertValue" value={this.state.myFirstState} 
                 onChange= {this.valueChange(e)}/>
        </div>
       )
   }
}

That's basic stuff.
And It's just a way to go for It.

But what If we've more than one <input> ?
Not two... not three... we've more than ten <input> doing the same stuff?
(it is an exaggeration useful for the post)

As you can see our handleChange function, changes a specific state in It's setState() ... if we use the same function for other <input> we will change the value of myFirstState everytime.
(And trust me... I have seen people use numerous functions doing the same stuff, like these.)

My idea is...


//we've a class... with a more states defined

class App extends Component {
  constructor(props){
    super(props)
    this.state={
      myFirstState:"Labrador",
      mySecondState:"Akita"
    }

//we're going to manage the changes, and setState() equal 
//to the user input... for all the possible "keys" in the state object

      valueChange = (key) => {
        return function (e) {
          var obj= {};
          state[key] : e.target.value;
          this.setState(obj);
        }.bind(this);
       }

//rendering time...we've more Input tags, with the states as values and one
//function, calling onChange... we're passing the "key" as argument.

render() {
    return (
        <div className="just a class">
          <input placeholder="insertValue" value={this.state.myFirstState} 
                 onChange= {this.valueChange("myFirstState")}/>
          <input placeholder="insertValue" value={this.state.mySecondState} 
                 onChange= {this.valueChange("mySecondState")}/>
        </div>
       )
   }
}

With that, we're calling the method setState() passing an object where the key is the state we want to change and the value is the user input!.
We're also binding this or we're going to receive an error.

(Keep in mind... setState() triggers the render)

I hope I've been useful ... I'm looking for suggestions to manage this kind of case in more efficient ways!

Cya adventurers

There's no "else if" in JS

Fabio Russo — Sun, 20 May 2018 10:12:21 +0000

Grammar is not a joke...

Exactly, in Javascript's grammar there's no else if statement.

How many times have you used it before? Why It's still working?

We always code like this:


function wow(arg){

  if(arg === "dog"){
    return "LOVELY";
  }
  else if(arg === "cat"){
    return "CUTE";
  }
  else return "gimme an animal";
}

wow("cat");
//-> "CUTE"

But what's really happening is this:


function wow(arg){

  if(arg === "dog"){
    return "LOVELY";
  }
  else {
    if(arg === "cat"){
        return "CUTE";
    }
    else return "gimme an animal";
  }
}

wow("cat");

What's happening here?

Literally, we're using some implicit JS behavior about {} uses.

When we use the else if statement we're omitting the {} but Javascript It's still working because It does not requires the parentheses in that case, like in many other cases!

...so what?

I'm not writing this post, just because It's something really curious to know.

I'm writing this to make you think about all the good parts or right ways to code, that forces you to write code in a way, that sometimes It's not really the best way.

There's a lot to discuss about implicit and explicit declaration of stuff like: coercion, parentheses, semicolon...

But the true always stands in the middle!.

If you just follow some specific rules on how to... you're not understanding why those rules were written, and this else if should make you think about It.

How many time have you written code, because someone told you to do so but you were totally blind about It?

I bet, a lot.

I'm not saying that we should not care about ALL those rules, and that we should know ALL the JS documentation.

I'm just saying that right now, your duty is to write good code that can be understood by someone else and to go that way... some rules are ok, but you should know the why.

Because someone is good at code, It does not mean that you have to follow his golden rules.

What's implicit for him, maybe explicit for you and many other people.

If you don't have the same knowledge, about that specific argument (and It's not possible to have exactly the same level of know about It in every single part of the code) you've two options:

Do what he's telling you to do... If It works.
Go out and check the why

Always care about the good parts but first of all, always care about your knowledge and don't code just by rules.

Best-practices must be accepted by many people

Is Javascript a compiled language?

Fabio Russo — Wed, 16 May 2018 09:26:21 +0000

It really Is...

Why do people still look at JS as a dynamic or interpreted language?

There's a lot of misconception about the compiling of JS, and still now, with lots of information on the web, most people still argue with that and still don't know how exactly JS works before the runtime phase.

Javascript is a compiled language...

despite the fact that the compiling of JS works in a different way, if compared to other compiled language, It's still following some rules that reflect the process of compiling

First... we've to quote this from wikipedia:

A compiler is computer software that transforms computer code written in one programming language (the source language) into another programming language (the target language).

We all knows that computers don't speak Java or JS or Python and don't matter which language we're using, we're always translating our code into something that the machine can understand... but that's not the most important thing for now.

Important is... this kind of translation is called code generation and it's input is the Abstract Syntax Tree (AST) that is about some nested elements that represent the structure of the program. The structuring of this tree, happens in the parsing phase of compiling.

Of course we've to provide something to create this AST ... and we do ... we provide an array of tokens, from the previous compiling lexing phase.

let dog = labrador;

will be tokenized like this

let,dog,=,labrador,;

This splitted version of our code, means something for the language and creates that stream of informations to generate the AST.
We now have a variableDeclaration and an assignment and so on... in our tree.

I've been not very specific, because this post is about the fact that in JS all of this, It's happening.

Yes.

Javascript follows all of this compiling phases, in the order:

Lexing
Parsing
Code Generation

The JS compiling It's not happening to make it works on different platforms or stuff like that... but It's happening

This is not something you should know as generic... this is something that can totally change your point of view about lots of JS behaviours.

Just quick examples are lexical scoping and hoisting.

The variable declarations in JS happens during the lexing phase, while the assignement happens on runtime and that's why hoisting It's happening in a more technical and correct point of view.
The scope, in JS, It's defined in It's lexing phase and that's why JS has got the lexical scoping definition.

What about closures ? More complex... but still something that happens because of scope reference and lexical scoping.

So, people, JS is quickly compiled, everytime... and there's lot of optimization included in the engine to make it possible without any collateral problem in performances, that you can break if you're not conscious about this stuff.

Have fun, looking for more info!

What the... error handling! (try...catch)

Fabio Russo — Tue, 08 May 2018 13:53:38 +0000

Please check your code!

Bugs exist... and they always will.

No matter how good we are at code, or how focused is our mind while coding... there will be bugs like Coding bugs or Input bugs or whatever.

we have a duty ... to do our best to control them

A very basic way to control our code, is something really smart and easy.

Is there an error? Do this.
Not an error? Do this.
Anyway... do also this.

We can see this kind of stuff, in code like this:

const breeds = ["labrador","chow-chow","samoyed"];

try
    {
        //is there an
        akita;
        //?
    }
catch(e)
    {
        console.log("Ouch, no Akita here " + e);
        }
finally
    {
        console.log("At least there's a labrador");
    }

//-> Ouch, no Akita here ReferenceError: akita is not defined
//-> At least there's a labrador

So, what's happening here?

We created a simple:
try{} catch{} finally{}

try{}

Here we're trying to execute the code

const breeds = ["labrador","chow-chow","samoyed"];

try
    {
        //is there an
        akita;
        //?
    }

As you can see there's an akita variable, but nothing in the program has to do with that, so there's an error

catch{}

When an error occurs the catch{} statement is called.

catch(e)
    {
        console.log("Ouch, no Akita here " + e);
    }

All the stuff inside the statement will be executed and we will console out the String and that strange e.
That one is an Error Object a built in Object that JS provides us to capture what's happening when an error occurs.

There are lot of stuff that can be done with It. If you use e.stack It will return where in the stack the error occurred.

We can also define our custom error, later we'll see It.

finally{}

This statement, always happens.
No matter if there's an error or the code is good ... the finally{} will always be executed.

our custom error...

Sometimes, It can be really important to create our custom error.

Why?

Maybe we want give a name to that kind of error.
Maybe we want a better code, more understandable.
There are lot of good reasons.

Here It's the throw

const breeds = ["labrador","chow-chow","samoyed"];

  try
      {
          if(!breeds.includes("Akita")) 
          throw new SyntaxError("no Akita here");

      }
  catch(e)
      {
          console.log(e);
      }
//-> SyntaxError: no Akita here

See? We've just created a new "SyntaxError".
When the try meets an error the throw will immediately call the catch and a new Error will be created.

We can go deeper with this.

What If we want to create a totally new Error Object so that, the Error will be thrown only if It's an instance of that kind of Error?

We can do this:

class noDog extends Error {}

function findDog(arr) {
  if (arr.includes("Akita")) {
    return "Here you are";
  } else {
    throw new noDog("No Akita here");
  }
}

function doggy(arr) {
    try {
      return findDog(arr);
    } catch (e) {
      if (e instanceof noDog)
        throw e.message;
    }
}

console.log(doggy(["labradors","chow-chow"]));
//-> No Akita here

Hm... this is really not that easy like our previous examples.
So If you dunno what's happening here, don't be scared, It's ok.

We're defining a class that extends the built in Error.
We're just extending that class. Nothing more.
This new class has got no special properties, It's inheriting everything from the Error Object.

In short... we've created a new instance for our errors.

With that in mind, we can now catch exceptions only if those are instanceof noDog, and we can separate this kind of error, from standard one.

COOL

What the... generators!

Fabio Russo — Sun, 06 May 2018 08:49:40 +0000

Want to know about generators?

FIRST you need to check iterators

That's not something you can skip, because, generators work through iterators. We can say that generators are a simpler way to write our own iterators.

This is a generator:


function* breeds(){
    yield "labrador";
    return "chow-chow";
}

const iterator = breeds();

console.log(iterator.next())
//->{value: "labrador", done: false}
console.log(iterator.next())
//->{value: "chow-chow", done: true}
console.log(iterator.next())
//->{value: undefined, done: true}

Let's see what's happening here.

First, we need to create a generator function, and we can do that by using a * between function and the function name.
No matter if it's:
function* breeds()
function *breeds()
const breeds = function *()
const breeds = function*()
This will work anyway!.

(But, It's a standard to use the * just after the function ... so try to always use the syntax function*.)

Inside that function we're using that yield ... what's that?
yield It's something listening to the next() calls.

Everytime we use the .next() on the iterator, the generator will use the next not yet used yield.
That's the same idea behind iterators and we're checking that, with the done key the iterators returns!.

If It's value is false the .next() will call the yield AFTER the previous one.


console.log(iterator.next())
//->{value: "labrador", done: false}
console.log(iterator.next())
//->{value: "chow-chow", done: true}
console.log(iterator.next())
//->{value: undefined, done: true}

When the done:true will happens?
When there's no more to yield out that generator.

But we need to be more precise about this.

We all know that a function, in JS, always returns something.
If you do not define a return, JS will do It for you, by returning an "undefined" at the end of It.


function* breeds(){
    yield "labrador";
    yield "chow-chow";
}

const iterator = breeds();

console.log(iterator.next())
//->{value: "labrador", done: false}
console.log(iterator.next())
//->{value: "chow-chow", done: false}
console.log(iterator.next())
//->{value: undefined, done: true}

By taking away the return from the function, calling .next() will force JS to return a {value: undefined, done: true}

So JS still returns It for you, also with generators, because, we're still talking about functions here!

If you want to force a return you can use the .return() method on the iterator and finish the generator.


function* breeds(){
    yield "labrador";
    yield "chow-chow";
}

const iterator = breeds();

console.log(iterator.return("we <3 dogs"))
//->{value: "we <3 dogs", done: true}
console.log(iterator.next())
//->{value: undefined, done: true}
console.log(iterator.next())
//->{value: undefined, done: true}

As you can see, we're immediately returning and finishing the generator with the .return() method!.

generators are not magic!

We're really not executing stuff by calling the generators ... indeed, we're using the iterator interface every time we're calling generators with the .next() method.

We can see the .next() as a remote controller to START (calling yield) and PAUSE (checking the done: value) the generator function

That's why, we need to define:


const iterator = breeds();

and call the iterator.next()

(iterator It's just the variable name, not the iterator object itself)

lot of stuff can be done

In real life work, we can do really lot of stuff with generators.

We can use generators values with variables.
We can fetch, spread and use the for...of loop.

At the moment we're using generators to call one single yield at time, we can say, that we're using It in synchronous way.

But, generators can be also used in asynchronous way.
I'm not going to cover It now... you can check about Promises or async/await, and maybe, we we'll talk about that, another day.
Promises
Async

HAVE FUN WITH CODE

objects? No... array, please!

Fabio Russo — Fri, 04 May 2018 17:44:37 +0000

I don't like objects...that much!

This is an object:

const obj = {breed:"labrador",age:9}

But sometimes I prefer to work with arrays.

Why? Because they really look better to me... and there are really a lot of methods or loops that work just with [arrays]!

These are some tools used to "convert" objects to arrays.


//Object.values() will give you an array of all the object "values"

const obj = {breed:"labrador",age:9}

const values = Object.values(obj)

console.log(values)

//-> ["labrador", 9]



//Object.keys() will give you an array of all the object "keys"

const obj = {breed:"labrador",age:9}

const keys = Object.keys(obj)

console.log(keys)

//-> ["breed", "age"]



//Object.entries()  will give you an arraysh version of the object. 
//Where the key and the value will be paired into an array... 
//and all of those arrays will be "pushed" into another array.

const obj = {breed:"labrador",age:9}

const entries = Object.entries(obj)

console.log(entries)

//->[["breed", "labrador"], ["age", 9]]

This is easy peasy stuff, but very often, at the beginning of my journey in JS, objects were very often a problem for me.

If only they had told me before ...

![img](http://static.yourtango.com/cdn/farfuture/6HjAhU1pGFNDKoarYIDtEGMvpAPpSjYWMm6xn0ZlrJw/mtime:1475815278/sites/default/files/notyourfault.gif)

P.S: These tools are ok... if it’s ok to work with arrays instead of objects.
Sometimes you’ve to use objects... because of performance or long term maintenance.

What the... iterators?

Fabio Russo — Thu, 03 May 2018 18:26:35 +0000

ITERATORS are not that scary...

According to the MDN web docs:

The for...of statement creates a loop iterating over iterable objects, , invoking a custom iteration hook with statements to be executed for the value of each distinct property of the object.

Ok... hm... but what's that Iterable object?

We use iteration almost every time we code... with stuff like: map, filter, for, forEach, ecc...

But the for...of statement is special, because:

Iterators (...) bring the concept of iteration directly into the core language and provide a mechanism for customizing the behavior of for...of loops.

So you can think that the for...of loop knows how to iterate over an array... but that's not true!.
We need the iterator object as "interface" to loop over it:

for...of <------> ITERATOR <------ array

Now that we know this... let code it:

const dogs = ["labrador","chow-chow","cavalier"];

for (let breed of dogs)
    {
        console.log(breed);
    }
//-> labrador, chow-chow, cavalier

Behind that... we've the iterator object that looks like this:

const dogs = ["labrador","chow-chow","cavalier"];

let iterator = dogs[Symbol.iterator]();

for (let breed of iterator )
    {
        console.log(breed);
    }

//-> labrador, chow-chow, cavalier (the same result)

wait... WHAT?

Yes... that seems really strange, but It's not that bad.
Let's quote, again:

In order to be iterable, an object must implement the @@iterator method, meaning that the object (or one of the objects up its prototype chain) must have a property with a Symbol.iterator key. This function should return a new iterator for each call, however, this is not a requirement.

That Symbol.iterator is the property every iterable object needs, to loop over It.

Iterable objects can be:

String
Array
Map
Set
nodeList
...

and all these possess that property, behind the scene.

Symbol.iterator

The property provides us, the next() method, that works like this:

const dogs = ["labrador","chow-chow","cavalier"];

let iterator = dogs[Symbol.iterator]();

console.log(iterator.next())

//-> {value: "labrador", done: false}

Every time we call the next() method, we loop over the iterable object.

Now we've got two keys:
value: "labrador"
(the current value of the iterable object)
done: false
(will be false until we've values inside of it!)

const dogs = ["labrador","chow-chow","cavalier"];

let iterator = dogs[Symbol.iterator]();

console.log(iterator.next())
//-> {value: "labrador", done: false}
console.log(iterator.next())
//-> {value: "chow-chow", done: false}
console.log(iterator.next())
//-> {value: "cavalier", done: false}
console.log(iterator.next())
//-> {value: undefined, done: true}

done:true is the ending point for the iterable object.

There are some other powerful tools in JS that need the object to be iterable

//TAKE A LOOK AT THE SPREAD OPERATOR...

const number = 31;

let count = [...dogs];

//-> TypeError: dogs is not iterable

const dogs = "labrador";

let doggy = [...dogs];

console.log(doggy)

//-> ["l", "a", "b", "r", "a", "d", "o", "r"]

You've to be always careful about this, and use only iterable objects with tools like these!.

I want to say byebye adding a bit of spice:

Symbol.iterator is a property... so... you can create your own iterable object if you want to!

For more info:

The mighty MDN guide

Have fun with it!

Array reference... and how to not!

Fabio Russo — Sat, 28 Apr 2018 15:56:48 +0000

Sometimes it's sticky...

Look at this code... what do you think is going to happen to the breeds array?

let breeds = ["Labrador","Akita","Siamese"]

// Let's make an array of only Dogs Breed... splice out Siamese.

let doggy = breeds;

doggy.splice(2)

console.log(doggy)
// -> ["Labrador", "Akita"]

console.log(breeds)
// -> ["Labrador", "Akita"]

So... we just wanted to change the doggy array, and not the breeds one.

We told JavaScipt:

I want a new array;
Call It doggy;
Give doggy the same values of Breeds;

let doggy = breeds;

But Javascript with the "=" has created a REFERENCE.

With our declaration doggy and breeds are pointing at the "same object" by reference... the same memory, and by changing one, you're changing both!

evil TWINS

Let's make a list... how not to create a reference

If we want to pass just the values of an array into another, and at the same time create a "new object".
We can use this useful methods.

//1. Create a copy with slice.
let doggy = breeds.slice();

//2. Create a concatenation with an empty array.
let doggy = [].concat(breeds);

//3. Spread an array into another one.
let doggy = [...breeds];

//4. Use the Array.from() method, to create an array, with the same value of //another one
let doggy = Array.from(breeds);

All the methods, up here, are creating a totally NEW doggy array, without any reference to the breeds one.
You can now take off the Siamese without any collateral effect.

let breeds = ["Labrador","Akita","Siamese"]

let doggy = breeds.slice();

doggy.splice(2)

console.log(doggy)
// -> ["Labrador", "Akita"]

console.log(breeds)
// -> ["Labrador", "Akita", "Siamese"]

Now they're in different arrays... but can still love each other!

What the... hoisting?

Fabio Russo — Fri, 27 Apr 2018 20:47:35 +0000

Hoisting in Javascript... has always been a really bad behavior of the language itself.

Why are you doing this for me?

If you dunno what I'm talking about, that's what (in short words) the hoisting is:

console.log(test)
// -> undefined
var test = "I'm not here";

As you can see, when I'm calling the console.log(test) the variable itself, has not been declared at all!.

But Javascript is a bad guy that chooses to declare it for you.
Here's what happened:

//javascript will declare the variable, moving it at the TOP of it's scope
var test;
console.log(test)
// -> undefined
test = "I'm not here";

this is really confusing, and should not happen at all!.

And we've not finished yet, because this also happens into function's scope.
Like this:

function test(){
  return test;
  var test = "I'm not here";
}

console.log(test())
// -> undefined

And also happening with a function itself!.

If we move the call to console.log(test) at the top of the call stack, the
function test() should not exists...

console.log(test())

function test(){
  var test = "I should not be here";
  return test;
}

// -> "I should not be here"

Nothing to do... Javascript is moving the function to the top of the Scope... so you can call a function, before you declare it...

But wait:

console.log(test)
// -> undefined
var test =function test(){
   var test = "I'm not here";
   return test;
}

Why there's an undefined if we can call a function, before we declare it?

Because, in this last code, only the var test declaration has been moved to the top, and not the function assigned to It.

Let's RECAP!

Everytime you declare a var into a scope or write a function declaration, Javascript HOISTING moves those at the TOP of their scope without their value.

No way... I'm leaving!

So... "Let" and "Const" ...they are our salvation!

Let's look at what happens with Let and Const if we try to do the same dirty stuff:

function test(){
    return confusing;
    let confusing = "Finally!";
}

console.log(test())
//-> ReferenceError: can't access lexical declaration `confusing' before         initialization

AH AH! so, here you're!

and the same happens with const:

function test(){
    return confusing;
    const confusing = "Still Safe!";
}

console.log(test())

Can you guess, what happens with "let" and "const" in the global scope?

Because let is a "block scope local variable" and you need to put it into a block to unleash it's power...

_But this is another story_