The .every method i discovered today

Looking on react-redux example i found the following line:

  if (user && requiredFields.every(key => user.hasOwnProperty(key))) {
    console.log('no need to call "fetch"')
    return null
  }

Notice the usage of "every" statement.

Every

So, what is the advantage of "every"?
consider you have the following array:

const arr = [{name:'yoyo', active:true}, {name:'momo', active:true}, {name:'bobo', active:false}]

How can you quickly know if all users are active?
So, you can loop through the array with "forEach", like this

let everybodyIsActie = true;
arr.forEach(user => {
   if(!user.active) { // if even one is not active
     everybodyIsActie = false;
   }
})
if(everybodyIsActie) {
 console.log('everybody dance now!')
}

But, much more awesome is to use "every" statement:

if(arr.every(user => user.active)) {
 console.log('everybody dance now!')
}

No need to use any variables
Unlike "forEach" (which doesnt returns enything) "every" returns true if every array item fills the condition
See you in my next post!

Playing With Css Grid - Part 2

One of most interesting features of CSSGrid - is
grid-template-areas feature. It makes you able to define layout areas and to associate the HTML element with specific layout parts.
Lets try to build following layout with css grid:

First lets divide the layout to the parts that will explain how much rows and columns each element will occupy:

.container{
  ...
  grid-template-areas:
      "nav header"
      "nav main"
      "nav footer";
}

Now We only need to 'explain' to each element - what the area it should belong to:

header{
  grid-area:header;
}

Clear and simple:

Squashing Commits With Vim (On VsCode)

When you about to do your first PR (pull request) it is important to know how to squash commits correctly.

Why? you may ask
- Well i know that you are probably good programmer and organized person, and you always use to give a second look before pushing something - to make sure the things are intact, but, somehow, sometimes, after pushing the commit (you checked before all and over!) - you find yourself looking at embarrassing typo you mysteriously missed while checking.

 So, what to do now? One way is to start all the thing again from the beginning (new branch, merge changes, new PR etc... ), but is it the only way?

 Fortunately (unlike real life) - there is a way to rewrite history - the rebase command!

 So, in case you found a typo - all you have to do is:
1. commit again (git commit -am "fixing typo")
2. run

git rebase -i HEAD~2

(because you want to squash 2 commits)
3. after running this command you will present with following screen: (in windows you need to press 'i' for enter into 'insert' mode)

4. modify the row of latest commit and replace 'pick' with 's'(squash)

5. (windows) press ESC(for exiting 'insert' mode)
6. (windows) type :wq to save changes and quit
8. in linux you just press CTRL + X



After selecting which commit to squash, you will present with screen where you can reformat the message of single commit you about to generate. You can just leave the message of original one and comment the others with '#'

7. run 

git push -f origin your-pr-branch-name

Now, look at your remote repo "commits" log: no traces of embarrassing typo, just one clean commit!

Imagine you could replay this way the world history and, for example, prevent the WW2... could be great, right?


Thats it,
Hope i helped someone in my situation

See you in my next post!