DEV Community: Abdelrahman Yousry

Keys for You to Become a Better Frontend Web Developer

Abdelrahman Yousry — Thu, 25 Jun 2020 16:51:32 +0000

I keep getting asked from a fair amount of people who happen to have a good experience in learning Web Development but got stuck in making tens of UI templates and dummy projects, this is really frustrating, seriously, how could they move to the next level?
This one will be more like a cheat sheet or a checklist than an article.
I assume that it's like if we were talking in a friendly chat, and you'll take my words, write notes, then go search for what these terms actually mean if you don't know some of them.
Let's dive in, we have no time to waste!

1. Know your Programming Language:

This part will be the longest, it could've taken a separate article by itself, but it's good to have it with the other parts.
Mostly, people have mistaken programming languages with their native-spoken languages.
In contrary to problem-solving, in order to use a programming language you don't need common sense, it's a set of rules written by someone to help you communicate with your machine, in our case, we used to use it to communicate with our browser, and nowadays, we use it everywhere.
JavaScript has specs and rules that should be respected, not to go out of it, and expect it to be written the same way as another language.

These are my notes:

1. Types:

Learn how JS is value-typed and know the different types the language offers to access and use memory, store data, not to mention defining your code parts.

2. Scopes & Closures:

How variables and pieces of code you have in a function will communicate with other pieces in the outer scope or another scope.

3. Hoisting:

The language offers solutions to read and execute your code, in a very unique way and order, you should know about that.

4. OOP in JS:

How JS was developed over the years to provide solutions and empower engineers to use well-known programming paradigms.

5. Async JS:

You're a developer that targets to build dynamic, single-page apps, real-time apps, you should gradually learn how to write code that waits for something then does something else.
Cover Callback Functions first, then move to Promises, have fun with async-await solutions, and maybe get to know Generator Functions, blend all of these topics into fetching data with XHR Requests, wait for the data and use it to update your HTML content and make operations on it.

6. Array's Higher-Order Functions:

Instead of making for loops and using conditionals inside of it to target or restructure array elements, why not introduce yourself to "map, find, filter, reduce", these are all handy functions that you won't pass a day as a skilled JS developer without using them.

7. How JS interacts with the browser:

Using global objects like window, document, and how JS accesses HTML elements and subscribes to events and actions happening to it.

8. Object Destructuring and Spread Operator:

Very handy especially when you need to access a part in your data structure or state, or changing it without losing immutability approaches.

2. Git Version Control:

Hopefully, you'll be working in a big company, even if it's a small one, we all aim for using good Code Delivery Systems and well-established ones, you'll handle multiple environments: production, staging, etc.
So, you really need to have confidence in Git branching commands, git checkout, checkout -b, git merge and its different types "what does it mean fast-forward vs no-ff vs squash", you'll need to cherry-pick a feature in order to release it, there's a command for that, you may need to revert something you did, reset another thing, not to mention pushing, pulling and other basic ways to interact with your colleagues to add awesome features to your codebase.
Be bold, don't be shy to ask, seek reviews, and get into experience-sharing conversations.

3. Don't get satisfied with one Framework or Library:

Better than the skill of acing one frontend JS framework, is to have transitioned between two of them, not to get lost or confused, but gaining the experience when you go to the second one and ask it: "I used to do this thing in that way in the previous one, in what way do you offer to do it?", this skill, in my opinion, is by far the most important skill and what separates a person who's shy and can't move from being a junior to a person with high potential to deal with senior level problems, who don't have a problem to hop in with one of his teammates and solve a problem, even if he's working with different technology and/or didn't use this technology before.

4. Don't be stingy with yourself in Backend Topics:

As the consumer of BE produced APIs and the one responsible for showing it to the user, also responsible for collecting data from user and delivering it to BE, you'll need to have some knowledge about how they design the system you're presenting, not in a complicated or a detailed way, of course, just have a fair knowledge about ERD "Relational Diagrams" and how Entities and Models "Ex: In a social network app: Posts, Comments, Users" are talking and related to each other in databases, especially relational database, Learn basic SQL "Structured Query Language", just try CRUD operations "Create a model we mention in a Table, create a record, read from it, updated it, delete it", maybe create another table and apply relations and joins to it "use foreign keys", go search for all of these terms!

5. Get your hands dirty with Module Bundlers:

Webpack, Parcel, and other tools that use node and npm's ecosystem to host your development experience or empower your framework of choice, dig deep into documentation and know how it works, how it tracks your files and deals with them as trees of imported files inside of imported files until you get to your main index.js, knowing how using code-splitting and optimization options can boost your performance, how does a bundler build your code into just a classic set of files needed for your server to respond with just an HTML file, a CSS file, and a JS chunk, just that simple.

6. Have your working tools personalized for you:

Your text editor, your terminal, should help you to be in control of the development process, monitor your Git branches,
Ex: using Gitlens extension in VSCode helps you to know who made which change in the code, and when.
Your terminal can be helpful, not just for writing commands but for knowing about your branch status, what changes did you do, are you ahead or behind, use your text editor before you push to compare changed files and to make changes as less as possible.

I really hope this was helpful, you'll find previous articles I wrote that'll help a lot with the first part of this one, also, if you have any question, please don't hesitate to reach out.

Covering these topics makes you a JavaScript Interview Boss - Part 2

Abdelrahman Yousry — Thu, 14 May 2020 13:33:24 +0000

In the first part of our series, we were introduced to some basic but really important topics that are vital to understanding how JS works, in fact, the topics in this article depend a lot on what we discussed before, check it now.

So what are we waiting for? let's dive in.

4. Closures "The elephant in the room":

Last time we talked about how JS benefits from and arranges Scope Chains, so let's think about an interesting case, if we have a function inside another function, imagine a "console.log()" statement inside the nested one, what can it access in terms of variables?

Variables defined inside of the nested function at the same level as the statement.
Parameters passed to the nested function "which technically are just variables that get values when running the function".
Variables and Parameters in the parent function.
Down to "Check the stack of plates theory in last part's Scopes" what's in the global scope.

When you try to return the nested function when running the parent, something cool happens, in order to work, the nested function makes its own copy "not copy" from the scope we've mentioned in point 3, not all variables there, only ones that are needed for the inner function to work.

With that said, now when we return a function inside a function we have access to the layer in the middle that we couldn't access before, the return function is now armored with a box of variables to use, that we can't get elsewhere, we now have a state in that box, we can make processes on this variable, only the process we need and we specified in the returned function, in this example check how we can access "count" outside its local scope and increment it, only incrementing, not deleting, not changing, "count" is still private to the outside world!

In fact, wrapping this logic with something like modules and IIFE "Immediately-invoked Function Expression", now we can write our own packages and modules, and share it with others with useful states but only according to our specifications.

To sum up, if you get a question like What do you know about Closures? A very good and decisive start should be like: It's the process of returning a function inside a function, benefiting from Scope Chains and providing state and privacy to a certain scope. Neat!

5. Object-Oriented JS:

Once I was asked a question: Tell me about how Object-oriented JS is? What do Classes provide in JS? How Inheritance works?

To answer this one we should dive in our language's timeline, if we have an object, an object literal declared with "{}", it has properties, pairs of keys and values, then you need to add properties as functions to it, well, they're called methods, but this is too straight forward, we can use functions to be our constructors, instantiate an empty object in the beginning, and pass properties' values from the function parameters, return this object at the end of our function, now we have like a boilerplate that takes values and assign it to the same properties.

Actually, when making a new instance of your constructor function, you can replace both first and last steps of instantiating and returning the object, by using the "new" keyword when defining a new instance, it will create a "this" object and you can add properties to this, then it will be returned at the end.

What if we wanted to add another object with extra properties, extra methods, without losing the original ones? If you have to define an object you can use an object literal or another cool feature like "Object.create", you can use it to extend your original object if you pass it inside create "const newObject = Object.create(originalObject);" now all original properties are delegated to the new object, you can now build on top of it.

Back to our constructor function, you can use this feature to store all your methods inside an object, then using "Object.create" you can move these methods to your constructor, but our function actually has a builtin point inside of it called "prototype", you can hold all your methods inside of it, and that's exactly what "new" keyword does, you imagined it as "this" will be an empty object in the beginning, but it's actually an "Object.create" that holds all methods using "prototype".

Road to Inheritance: Now it started to be clear that we can take care of passing methods from a constructor function to another once they're in one place "Aka prototype", we call that prototypal inheritance, then how can we pass the properties itself? a constructor function has a cool method "call", while you're in the child function you can use it as "Parent.call(this, ...list of properties you want to extend)" this will copy properties instantiation from the parent but now will give it values from where the "call" method was called, Inheritance achieved!

In ES6 instead of making a constructor function, you can use classes, inside of it you have a constructor where you can list your properties, adding methods was never more straight forward, all it does under the hood is adding them to prototype.
A subclass can inherit from a class by just using "extends MainClass" when defining it, which, as you expected, all it does is using "Object.create" for passing prototype methods and using "call" to take care of our properties.
In the end, Classes are only, as we call it, a syntactic sugar, a predefined way that makes it easy to mimic constructor functions' functionality, which down the road represents how we boilerplate our objects, to reach inheritance and but as we said earlier in JS it's just prototypal inheritance.

I hope this one was helpful for you, see you in the next one.

Covering these topics makes you a Javascript Interview Boss - Part 1

Abdelrahman Yousry — Fri, 08 May 2020 11:56:13 +0000

You graduated from a Boot Camp or started taking CS classes, you find this thing in you for Web Development, and you knew that JS is the language of the web.

You've been working for almost a year as a Frontend Developer, everything is good, JS is a little scary, you have a bug, you go to StackOverflow "which by the way, what does this even mean?" you say to yourself, you've successfully put your pieces together and it's working fine now. You're asking yourself: When will I have the confidence, to work, and get through a JS interview in a bigger company like a boss?

Covering these topics, even knowing for now that they're there, means you're in a good direction, not just for your daily job's sake, but for sexy interview questions that one may say the interviewers are using them just to show off.

1. Scopes:

A Scope is just the variables that you can access and use depending on where you're standing now in your code.
Your scopes are built on top of each other, like a stack of plates. When you start a JS file that's a scope, you may call it global scope, now you defined a function, this has a local scope, and a plate is added on top of the stack.

An instruction "ex: console.log()" that lives in the function's local scope "AKA on top of the stack" can access what's beneath it in the global scope, but if you defined a variable inside your function, you can only access it from the function's scope.

If you have a function inside a function, and you requested a variable's value, JS will first search in your current scope and if not there will move down in the stack one plate by another back to the global scope, if it didn't find your variable it will through "Uncaught ReferenceError: ... is not defined", that's what we call Scope Chain.

2. Hoisting:

JS works like magic, well, it doesn't, like any programming language, it has steps to do, a compiler that reads your code and turns it into machine code.

JS runs through phases, it creates a copy of all your variables declarations without values, gives it "undefined" for now, then there's an execution phase where variables are given values, that's why variables in JS are value typed, var could be a number, a string, an object, or any other type.

You can visualize hoisting as if each time you write: "var foo = 5;" you will have "var foo;" on the top of your page then you will assign it to 5 later, that's why you can write "console.log(foo);" before the line and it won't through "ReferenceError: foo is not defined". It will just say it's "undefined", which means it doesn't have a value yet.
Function declarations hoist to the top too, test it by running a function with a "()" before you declare it, it will work.

3. Var vs Let vs Const:

Now that we were introduced to Scopes and Hoisting concepts, we can go to one sexy JS interview question you can get asked, What's the difference between Var & Let & Const for a variable definition?
Let's break it first to var vs let & const:
var is the classic way, that was there from the beginning before let and const were introduced in ES2015 "AKA ES6", the updates that happen to our lovely JS each year.

So what's the difference? var does hoist, if you called a var variable before defining it, it will be undefined, while let & const will through the ReferenceError. That's one part, luckily we got through hoisting first!

Another difference is that var is function "or local" scope, a great example to show that is if you have a function and a for loop inside of it,
if you define your iterator "i" with "var i = 0;" in the for loop head, you will find that you can still get "i" as "undefined" if you called it outside the for loop.
let & const don't behave that way, they're block-scoped, means every curly bracket, including ones in for loops or conditionals like if/else, is a scope that you can't call these variables outside of it.

Now that we covered the differences between the two teams, why let vs const?
"let" lets you define a variable with a name first then assign a value to it later, even if with a value you can change it later, the thing that "const" prohibits you from doing.
It gives you the functionality of having a constant that can't be overwritten later, very handy if you forgot while coding a big file that you already named a variable with this name before, and spending your day asking why your variable has a different value.

I hope this was helpful for you, don't hesitate to reach me out for feedback or any question.

To be continued...