DEV Community: Marek Dano

Closure in Javascript

Marek Dano — Mon, 18 May 2020 00:00:00 +0000

The closure in javascript is one of the main concepts which each javascript developer needs to grasp. It is also used in the interviews for frontend developers.

So, what's the closure?

We can understand it by great definition from MDN documentation where stays:

A closure is a special kind of object that combines two things: a function, and the environment in which the function was created. The environment consists of local variables that were in-scope at the time that the closure was created.

In other words, the closure is created when a function is returned from another function and that returned function has access to the outer function's scope. The closure is created at the function creation time.

Let say we have a function of

function getFamily(familyName) {
  return firstName => `${firstName} ${familyName}`
}

We can create a family function by calling the function getFamily and passing familyName into that function. Calling the function getFamily returns a function. The closure is created with the scope defined. The scope contains familyName. If we call that returned function (closure) from getFamily, in our case family and passing firstName into that function we can get the full name. The reason we can get familyName is that we have access to the outer scope of the returned function where familyName exists. Remember the variable familyName was created when the function of family was created. Hopefully what I said now makes sense when we execute the following code

const family = getFamily('Smith')

const fatherFullName = family('John')
const motherFullName = family('Emma')

console.log(fatherFullName) // John Smith
console.log(motherFullName) // Emma Smith

The closure is also used when we want to keep the variables defined in the function private, not to be accessible outside of the scope. The variables can then be modified inside of the scope. Consider this extended code

function getFamily(familyName) {
  const familyMembers = []

  function addMember(firstName) {
    familyMembers.push(firstName)
  }
  const listOfFamilyMembers = () => familyMembers.toString()
  const getFamilyName = () => familyName

  return {
    addMember,
    listOfFamilyMembers,
    getFamilyName,
  }
}

The variable of familyMember won't be accessible. It can be called or modified in the functions which are defined in the scope when the function of getFamily is created. If we want familyMember to be accessible from getFamily we can add it to the object returned from that function, but in this case, the variable won't be private anymore.

Now please follow the code and let me know what will be logged. Try to execute the code in your head first before testing it in your preferred javascript console.

const family = getFamily('Smith')
family.addMember('John')
family.addMember('Emma')
family.addMember('Josh')

console.log(family.listOfFamilyMembers()) // ???
console.log(family.getFamilyName()) // ???

What platform (website) should I use to show my amazing project(s)

Marek Dano — Wed, 06 May 2020 15:46:03 +0000

I'd like to find if there is a platform or website somewhere, for frontend and even backend developers where they can show what they've created/built at work or during their free time.

Many developers are not known very well, because they can be just out of a college, just out of dev bootcamp or they have lost their jobs. They haven't had enough time to build their personal brand and be widely seen on social media or outside of their personal network. But they can still be amazing as developers/engineers. how would you recommend for them to be seen? Where they should go to promote themselves?

Please share this article and left a comment below to help others to be seen ✋.

Automate build process with the build script

Marek Dano — Fri, 01 Nov 2019 00:00:00 +0000

The process of building applications for production usually involves executing several steps and building angular applications is no different. The repetitive steps are in the following sequence:

Get a tag and branch name from git
Build the application for production by using ng build --prod command
Update the configuration file of config.json
Zip the build and release it

Prerequisite

As I already mentioned we have the angular application. We keep the configuration settings of our application in the config.json file. If you want to find out more about how we use the configuration file in our app, please check here.

To update the config.json file for production we decided to use the jq tool which had to be installed on a build machine. We build the application on OS X, so we installed it through brew, like

brew install jq

Description

In the script below you can see that we followed the required steps.

We read the latest git tag and current branch name from git and assigned it to variables.
We build the application by executing ng build --prod and placed the build to the wwwroot folder.
Updating config.json under wwwroot/assets folder with using jq tool. We read the config.json file, find a field, assign a new value to it, redirect the output content to the newly created temp.json file, and finally replace the content in config.json within the content in config.json within the content in temp.json. Something like:

jq '.field = "new_value"' config.json > temp.json && mv temp.json config.json

We zipped the build with the updated config.json file and moved the zipped file to the root of the project.

And here is the full build script that we used:

#!/bin/sh
CONFIG_PATH=wwwroot/assets/config.json
CURRENT_TAG=$(git describe --tags `git rev-list --tags --max-count=1`) # the latest tag
CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD)
ENV_TYPE=${1:-"production"}

echo ""
echo "app version \"$CURRENT_TAG\""
echo "building in branch \"$CURRENT_BRANCH\""
echo "environment type \"$ENV_TYPE\""

echo ""
echo "Start building the app..."
ng build --prod
echo "End building the app!!!"

if [ $CURRENT_BRANCH == 'master' ]
then
    CURRENT_BRANCH=""
else
    CURRENT_BRANCH="-$CURRENT_BRANCH"
fi


jq ".version = \"$CURRENT_TAG$CURRENT_BRANCH\"" $CONFIG_PATH > temp.json && mv temp.json $CONFIG_PATH
jq ".ops_environment = \"$ENV_TYPE\"" $CONFIG_PATH > temp.json && mv temp.json $CONFIG_PATH
jq '.authentication = true' $CONFIG_PATH > temp.json && mv temp.json $CONFIG_PATH
jq '.authorizationHeader = ""' $CONFIG_PATH > temp.json && mv temp.json $CONFIG_PATH
jq '.apiUrl = "http://10.0.0.84:60820/ws"' $CONFIG_PATH > temp.json && mv temp.json $CONFIG_PATH
jq '.tenant = ""' $CONFIG_PATH > temp.json && mv temp.json $CONFIG_PATH
jq '.authenticationType = "windows"' $CONFIG_PATH > temp.json && mv temp.json $CONFIG_PATH
jq '.signalr.url = "http://10.0.0.84:60820/ws/signalr"' $CONFIG_PATH > temp.json && mv temp.json $CONFIG_PATH
jq '.signalr.hubName = "OPSHub"' $CONFIG_PATH > temp.json && mv temp.json $CONFIG_PATH


echo ""
echo "Config file has been set up !!!"
echo ""

cd wwwroot

zip -r Apps-$CURRENT_TAG.zip .
# move file to the root of this project
mv Apps-rc-$CURRENT_TAG.zip ../

echo "Release folder zipped."
echo ""

Executing script

The build is saved as release_script.sh and is placed under the root of our project. Before executing the script we added the permission to the file by running following command in the folder where our script exists:

chmod 755 release_script.sh

The file permission can be different in your case.

Executing the file, navigate to the folder where script file exists and execute the script

./release_script.sh

If everything is set up correctly in the script, the zip file with build and the updated config.json file will be created under the root of the project.

Conclusion

Hopefully sharing this can encourage others to think and move from repetitive tasks to fully automated ones.

One configuration for multiple servers

Marek Dano — Sun, 01 Sep 2019 00:00:00 +0000

Have you ever asked yourself how to deploy the same application onto different servers with different settings? We asked the same question when we started developing our frontend application.

Requirement

In my company, we develop web applications. One of the applications is written in the Angular 8 and had to be deployed to our several customers, on their local in-house server or Azure one. The application had to be configured to communicate with our web API and also to have global settings defined. The place where web API is live is different for each application. Therefore we decided to have one local configuration file with all settings required in the app. Those settings should have been used in our application.

The similar file that we have is like:

{
  "version": "v1.0.0",
  "ops_environment": "production",
  "authentication": true,
  "authenticationType": "azure",
  "apiUrl": "https://sample-app.azurewebsites.net/ws",
  "tenant": "sample-tenant.com",
  "signalr": {
    "url": "https://sample-app.azurewebsites.net/ws/signalr",
    "hubName": "SampleHub"
  }
}

Where

authenticationType can be azure or windows depending on where the app is deployed - options are to Azure or IIS on the Windows server.
apiUrl and singlar.url is the URL of the required web API.

Our implementation

After researching we found that the best solution for us was to build and do a release of the application once for all our clients and have a configuration file of config.json somewhere in the app with the settings already defined above.

We decided to put the config.json file under assets folder rather than having it under the build root or somewhere else. If we didn't have it under the assets folder then we would have had to create the web API for getting the configuration file and reading settings at the start of initializing the whole application. Since we had it under assets, the config.json file loaded every time into the browser when the app started and we could set the required settings in our application.

The setting of apiUrl is used in angular services, authenticationType in the authentication process and signalr to set signal-R client in our app.

The part of our application structure with the location of config.json file is:

...

├── SampleApp
|   ├── src
|   |   ├── app
|   |   |   ├── pages
|   |   |   ├── shared

...

|   |   ├── assets
|   |   |   └── config.json
|   |   ├── environments

...

|   |   └── index.html

...

|   ├── package.json
|   └── angular.json

...

└── README.md

Conclusion

We believe that there might be a better solution to handle our problem. If you think we could have done it in a different way, please let us know ;)