I will start this article by saying that  State Management is not easy.

You might think "c'mon, state management is just a bucket that holds data. Not a biggie". And yes, I....agree(?) It's a bucket that we have to split in slices, to think what data to add and in which slice, how and when to get data from the slice, how to deal with the side effects, how to construct the actions and the functions that handles those actions, aka reducers. Well, it seems that it's not that easy after all.

A great feature that Angular has is to dynamically load component in a Higher Order Component by using the ComponentFactoryResolver. Apart from this, we can also lazy load a component using ES6 import. 

Did you know that a wrong SCSS usage can increase the bundle size of your Angular application? And you know what this issue is, right? A performance issue!! The bigger the bundle size the more time the browser requires to download all the files and the more time it takes to paint the page. 

A side note here: The CSS is render blocking which means that the browser won't render anything until all the CSS is downloaded and the CSSOM is constructed. 

Having this in mind, we have to take extra care of our CSS. Don't we? :) 

The majority of the products I worked on was/is B2B and they consisted of many (MANY) web forms. You know how this goes.

• You have to create the form model in the component (especially if you use reactive forms)
• Create the HTML elements
• Create the HTML elements
• ...
• Create the HTML elements

Those HTML elements more or less have a wrapper <div> element, a <label> tag, an <input> field, elements for error messages. This goes on and on. 

Who is our best friend for situations like this? ctrl+c & ctrl+v :) Yeah I know. I've been there.

Someone might say that this "best friend" helps us in many different cases. Here a bell rings. What do you do when you have to re-use the same code again and again? The answer is Abstraction. 
​
You know how to abstract your code in JS, in TS in C# and in many other languages. What about HTML though? Continue reading to find this out :) 

In the release of ES6 (ECMAScript 2015) a new way of declaring variables in JavaScript has been introduced. Actually 2 new ways. let and const. With these two, we now have 3 different ways to declare variables. var, let, const

What are the differences? The main difference is the scoping 

• let
  Block scope
  
  
• const
  Block scope
  
  
• var
  Function scope

In nutshell, block scope is the code that is enclosed in curly braces

The javascript engineers have been troubled often with the callbacks and the callback hell. The rescue are the promises: an easy and convenient way to handle the asynchronous calls.

A promise is an alternative way which allows us to handle asynchronous operations in a more elegant way than callbacks

Let's assume a simple story which will help us understand this. (well OK, I know that its not the best example you've ever read)

A father asks his son to go and buy a newspaper. The father is awaiting for the newspaper and will start reading it when his son returns back. On the other hand, the father knows that his son, who loves playing out in the yard, has some possibilities to fall down and start crying. In this case he won't read his newspaper and he will have to care of his son.

There are two cases in the story; the father will read the newspaper. The father won't read the newspaper.

• What happens on a single part of JS code?
  
• Is the code interpreted or compiled?
• What is the variable shadowing?
• What is the variable hoisting?
• What are the closures

In the following slide presentation I will try to answer the aforementioned questions by showing what the JS engine does on a simple part of code
​
Javascript compilation - execution

* In the company that I work for, we have a ceremony, called DOJO, in which any employer can present his/her ideas about any subject he/she wants to share (though we are trying to be focused on technological stuff). As such, this slide presentation was one of our DOJOs