DEV Community: Love Huria

ECMAScript - Past, Current and the future

Love Huria — Tue, 24 Nov 2020 12:51:07 +0000

You folks probably know what is Javascript and how popular it is now, but this was not the case in its early stages, and went through so many troubles to reach where it is now. When I started writing this post, it was intended to only talk about the latest features introduced by ECMAScript but during my research; I felt that it's a little hard to directly jump to features before setting the stage. 🙂 Here you go.

Introduction

History of Javascript

In the early days, Netscape navigator was gaining traction on the web as a competitor to NCSA Mosaic (The first popular web browser).
It was Netscape’s vision that the web should be more dynamic along with interactive animations which led birth to a scripting language called “Mocha”. It was created by "Brendan Eich" in 1995, a language which could be embedded and parsed directly into HTML document without any need for compilation.

The idea behind “Mocha” was plain and simple i.e all it had to do is be fast, dynamic, accessible to non-developers at that point in time.

During the same time, Java was emerging too; but it felt too big for a simple requirement. Hence, the efforts in putting “Mocha” on the runway were justified. And it was clear that “Java” to be used for big enterprises and complex components where “Mocha” to be used for small scripting tasks.

“Mocha" was first bundled with Netscape Navigator in May 1995. After a short period of time, it was renamed “LiveScript”. Later in December 1995, after a deal was worked out between Sun and Netscape communications, it was renamed to JavaScript with a marketing strategy that fits with “Java” for small scripting tasks.

Evolution of ECMAScript

During the initial phase, while Javascript was still evolving, Netscape took Javascript to “ECMA standards organization” in order to have cross-browser support and bring in some standardization which was a wise call.
ECMA also referred to as the “European Computer manufacturers association" formed a technical committee (known as TC39) to evolve the language, and ultimately releasing the first edition in June 1997.

Recap (ES1 - ES6)

ECMAScript 1, 2 & 3 - The beginnings

ECMAScript 1 was the first version released as a JavaScript standard in June 1997, although there were major misses in terms of features such as exceptions, regular expressions, etc.
ECMAScript 2 was released in June 1998 as a fix for inconsistencies b/w ECMA and ISO standards for JavaScript. No new changes were brought in.
ECMAScript 3 was released In December 1999 and it was the most interesting one of the three, as it brought in the first major changes which were long-awaited. It spreader like fire and reached a much wider audience since it was supported by all major browsers in the market.
- Exceptions along with try/catch blocks
- Better error handling
- Regular expressions
- New in-built functions
- Do-while blocks
- ..so on

ECMAScript 4 - The struggles

As soon as the work started on ECMAScript 4 (In 1999), there was a difference of opinions started to appear. Few folks were inclined towards taking the language to large-scale development needs. And few thought that this is not what “Javascript” was intended to do which pushed the release for a while.
The discussion took way longer than expected and days, months turned to years and the set of features grew bigger and bigger.
At that point in time, ES4 had the following features in the scope:
- Classes
- Interfaces
- Namespaces
- Packages
- Optional type annotations
- Optional static type checking
- Structural types
- Type definitions
- Multimethods
- Parameterized types
- Proper tail calls
- Iterators
- Generators
- Introspection
- Type discriminating exception handlers
- Constant bindings
- Proper block scoping
- Destructuring
- Succinct function expressions
- Array comprehensions

In conclusion, ES4 took 8 years of development, and in the end, it was completely scrapped.

ECMAScript 5 - Rebirth

After the long struggles, Javascript finally made it and became the most supported version.
Big giants were supporting it like Mozilla, Chrome, Opera, etc.
ES5 came up with the following features:
- Getter/setters
- trailing commas in an array and object literals
- Reserved words as property names
- New Object methods (create, defineProperty, keys, seal, freeze, getOwnPropertyNames, etc.)
- New Array methods (isArray, indexOf, every, some, map, filter, reduce, etc.)
- String.prototype.trim and property access
- New Date methods (toISOString, now, toJSON)
- Function bind
- JSON
- Immutable global objects (undefined, NaN, Infinity)
- Strict mode
- Other minor changes (parseInt ignores leading zeroes, thrown functions have proper these values, etc.)

ECMAScript 6 - Write less do more

ES6 brought in a completely new way of writing javascript which was pretty exciting and the code felt more readable, new syntaxes helped to do things with small chunks of code. It was a major update after ES5 which was release in 2009. ES6 was released in 2015, that’s why you may see people calling ES2015 and ES6 interchangeably.

ES6 came up with the following features:

Let (lexical) and const (unrebindable) bindings
Arrow functions (shorter anonymous functions) and lexical this (enclosing scope this)
Classes (syntactic sugar on top of prototypes)
Object literal improvements (computed keys, shorter method definitions, etc.)
Template strings
Promises
Generators, iterables, iterators and for..of
Default arguments for functions and the rest operator
Spread syntax
Destructuring
Module syntax
New collections (Set, Map, WeakSet, WeakMap)
Proxies and Reflection
Symbols
Typed arrays
Support for subclassing built-ins
Guaranteed tail-call optimization
Simpler Unicode support
Binary and octal literals

Present and the future

ECMAScript 7 (ES2016)

After the huge gap in the release of ES4, the committee decided to release one version every year even if it's a small update starting with ES6. The idea was not to do humongous releases like ES6 rather have small ones.

So, ES7 came up with only two new features:

Exponential operator: In addition to existing arithmetic operators (-, , +) which already exists in Javascript; they added a new operator (*) called the exponential operator. What it does is raises the first operand to the power of value from the second operand.

// 5 to the power of 2 i.e 25 
console.log(5 ** 2); // 25

Array.prototype.includes(): This returns true if the existing array includes a passed value. As simple as that; but really handy.

let sportsList = [‘cricket’, ‘volleyball’, ‘hockey’];
sportsList.includes(sportsList, ‘cricket’); // true

ECMAScript 8 (ES2017)

As part of the regular update, ES8 was released in 2017, and it came up with some really cool features. So, let’s explore them together:

Object.values(): In order to iterate through objects, this is one of the cool features ES8 introduced. It helps with looping through an object with a single line of code that returns the array with the respective values.

const music = {rock: 'Rock', heavyMetal: 'Heavy Metal', classical: 'Classical Music', jazz: 'Jazz'};
Object.values(music);
(4) ["Rock", "Heavy Metal", "Classical Music", "Jazz"]

Object.entries(): This one help to convert your object to array with key value pair.

 const music = {rock: 'Rock', heavyMetal: 'Heavy Metal', classical: 'Classical Music', jazz: 'Jazz'};
Object.entries(music);
["rock", "Rock”],  ["heavyMetal", "Heavy Metal”], ["classical", "Classical Music”],  ["jazz", "Jazz"]

Async Functions: Assuming that we already know what is asynchronous programming, Async functions basically work as syntactic sugar on top of promises, making it easy to read/write. So there are two parts to it:
- Async keyword: This keyword, we put in front of a function to make the complete wrapper asynchronous. It expects an await keyword to invoke the asynchronous code.
```
let helloWorld = async () => { return "Hello World" };
helloWorld() // returns a promise
```
- Await keyword: The real advantage of using the async keyword is to combine with the await keyword. It halts your code until the promise fulfills, then ultimately coming up with the resultant and it can only be used inside an async function.
```
const handleVersionUpdate = async () => {
  const getValueFromStore = await AsyncStorage.getItem(‘your_key');
  // do you handling
  console.log(’This will trigger once we have the value from storage, i.e the promise fulfills')
}
handleVersionUpdate();
```
String padding: This is kind of similar to what we have in CSS, with some padding left and right. Likewise, we have got a function in JS that can add some padding either at the start or at the end of the string making the output having the desired length.
- padStart(targetLength, string): As the name suggests, it adds up the padding at the start of the string.
```
'world'.padStart(20, 'hello'); // "hellohellohelloworld"
```
- padEnd(targetLength, string): This one is applied at the end of the string.
```
'hello'.padEnd(20, 'world’); // “helloworldworldworld"
```
Object.getOwnPropertyDescriptors(): This is an added tool that can help to return the property descriptors of a given object. The most useful use case is for cloning an existing object thoroughly.

const obj = {
  hello: 'hello',
  world: 'world'
}
let value = Object.getOwnPropertyDescriptors(obj);
console.log(value);
{
  hello: { value: 'hello', writable: true, enumerable: true, configurable: true },
  World: { value: 'world', writable: true, enumerable: true, configurable: true },
}
const clone = Object.create(
  Object.getPrototypeOf(obj), Object.getOwnPropertyDescriptors(obj)
);
console.log(clone);
// {hello: "hello", world: "world"}

Trailing commas (Also called final commas): This update was mostly to improve the dev experience to allow trailing commas in the params list. The intention is to have a practice in a place where if we need to add a new property, we don't need to modify the last added value with a comma ending up in cleaner version control.

let arr = [
  ‘car’, 
  ‘bike’,
  ’truck’, 
];
console.log(arr); // [‘car’, ‘bike’, ’truck’];

ECMAScript 9 (ES2018)

ES9 was released in June 2018; coming up with a lesser number of features than the last two years but maintaining a consistent yearly release cycle. Without further ado, let go through them one by one:

Regular Expression changes: In regular expressions, it takes a test method that expects a string and pattern to search against. If you have used regular expressions in the past, you may know that the dot operator is used to match a single character. But the issue we generally face is it skips line break characters like \n, \r, etc. So it introduced:
- DotAllFlag (\s): This operator can be used to match line breaks.
```
console.log(/Hello.World/.test('Hello\nWorld')); //false
console.log(/Hello.World/s.test('Hello\nWorld')); // true
```
- Unicode property escapes: To match any unicode character/number etc, we can now use ‘\p{type}’. For example:
```
const str = '40';
console.log(/\p{Number}/u.test(str)); // true
```
- Lookbehind Assertions: There are two types of assertions in this: positive and negative.
- Positive (?<=..): This one says that the word must start with % and replace the word with *****
```
'@hello %hello'.replace(/(?<=%)hello/g, '*****’); // "@hello %*****"
```
- Negative (?<!..): This one says that the word must start with % and replace the rest of words with *****
```
'@hello %hello'.replace(/(?<!%)hello/g, '*****’); // "@***** %hello"
```
- Named capture groups: In some cases, referencing a group in terms of numbers can be a bit confusing, ES9 came up with a better syntax to divide things into groups.
```
// How it used to be
const re = /(\d{4})-(\d{2})-(\d{2})/;
const match = re.exec('2020-11-21');
console.log(match[0]);    // → 2020-11-21
console.log(match[1]); // → 2020
// With new syntax
const re = /(?<year>\d{4})-(?<month>\d{2})-(?<day>\d{2})/;
const match = re.exec(‘2020-11-21');
console.log(match.groups);          // → {year: "2020", month: "11", day: "21"}
console.log(match.groups.year);     // → 2020
```
Promise.finally: We used to see the promises in terms of .then and .catch, but since the ES9 release; we seem to be able to have .finally in place which executes always at the end of promise execution. This is usually helpful in case you want to do some clean up at the end of your promise call.

doSomething(‘xx’).then().catch().finally(() => console.log(‘I am executed always’));

Rest/Spread Operator: ES9 came up with two new operators i.e Rest and Spread operators.

Rest operator: This one is used for object de-structuring.

let object = {
  hello: 'hello',
  world: 'world',
  blabla: 'blah blah',
}
const { blabla, ...rest } = object;
console.log(blabla); // "blah blah"
console.log(rest); // {hello: "hello", world: "world"}

Spread operator: This helps to insert its own properties of an object into a new one. Basically combining multiple objects.

let object = {
  hello: 'hello',
  world: 'world',
  blabla: 'blah blah',
}
let object2 = {
  blablaagain: 'blah blah again'
}
let object3 = {…object1, …object2};
console.log(object3); // {hello: "hello", world: "world", blabla: "blah blah", blablaagain: "blah blah again"}

Asynchronous Iteration: As Synchronous iteration was already introduced with ES6, people felt the need to have iterations possible in asynchronous as well. As they can not be iterated using for…of loop since they return promises. ES9 came up with a new for await..of the loop.

async function hello() {
  for await (const val of [‘hello', ‘world']){
    console.log(val)
  }
}
hello(); 
// hello 
// world

ECMAScript 10 (ES2019)

ES10 was not as big as ES6, but it did introduce some really powerful features which made our lives a bit easy. This version was released in June 2019.

Object.fromEntries(): This one takes a list of key-value pair and transforms into an object.

const blaObj = new Map([
  ['bla', 'blah'],
  ['bla2', 'blah2']
]); 
const obj = Object.fromEntries(blaObj);
console.log(obj); // {bla: "blah", bla2: "blah2"}

Optional Catch Binding: Earlier we had this parameter which had to be passed to the catch block. But now, it has been made optional.

try {
  throw "Some error";
} catch {
  console.log("Don't care what it is about!")
}

Array: In ES10, there were a couple of additions Array bucket. Here you go:
- Array.flat(): As the name suggests, it basically helps to flat down the subarray elements as per the specified depth.
```
const blahArray = ['hello', ['world']];
blahArray.flat(1); // (2) ["hello", "world”]
```
- Array.flatMap(): This one is kind of on the same lines as flat() along with map() features. It map through the array of items and then flatten the result in one go.
```
const blahArr = [1, 2, 3, 4];
blahArr.flatMap(value=>value*2); // (4) [2, 4, 6, 8]
```
- Stable Array.sort(): Earlier, it used to have the Quicksort algorithm as a base for arrays containing more than 10 elements. But that is no longer the case, now it uses the stable TimSort algorithm.
Changes in toString(): In ES6, when this was introduced, it used to give a string like a representation of the function in the result when run. This has been made much more cleaner now.

Function blahFunction() {
  //do your magic here
}
console.log(blahFunction.toString());
function blahFunction() {
  // Hello, I'm an ordinary function
}

Changes in Symbol data type: As we know, “Symbol” is a primitive data type and it returns a value of type “symbol” when declared. Earlier to get the symbol description, we used to use “toString”, but now we have a getter for it to access.

const symbolExample1 = Symbol("Symbol description");
console.log(symbolExample1.description); //Symbol description

String: In ES10, there were few updates made to string methods as well.
- String.trimStart(): It helps to remove whitespace from the beginning of the string. As simple as that.
```
const blahStr = '   Hello world!   ';
blahStr.trimStart(); // "Hello world!   "
```
- String.trimEnd(): It helps to remove whitespace at the end of the string.
```
blahStr.trimEnd(); // "   Hello world!"
```

ECMAScript 11 (ES2020)

ES11 was released this year recently, coming up with several native features as well as few other correspondings to its yearly release.

Promise.AllSettled(): This returns a promise once all the promises passed are resolved does not matter if they were fulfilled or rejected with an array resulting in the status of each promise.

var p1 = Promise.resolve('hey');
var p2 = new Promise((resolve, reject) => setTimeout(reject, 2000));
const p3 = new Promise((resolve, reject) => setTimeout(resolve, 5000));
Promise.allSettled([p1, p2, p3]).then(values => console.log(values));
(3) [{…}, {…}, {…}]
0: {status: "fulfilled", value: "hey"}
1: {status: "rejected", reason: undefined}
2: {status: "fulfilled", value: undefined}

BigInt: Till now, the maximum number in javascript was 9007199254740991, but now we can go beyond this number using BigInt. It is done by adding “n” at the end of the string.

const biggestNumber = 9007199254740991n;
const biggerNumberThanBefore = BigInt(biggestNumber);
console.log(biggerNumberThanBefore); // 9007199254740991n

Nullish Coalescing: It works as a logical operator and helps us in checking if the left-hand operand is either null or undefined and returns the right-hand operand value.

var v1 = undefined ?? 'Hey there!';
console.log(v1); // "Hey there!"
var v2 = 'Come here first' ?? 'Hey there!';
console.log(v2); // "Come here first"

Dynamic Import: You may have used dynamic import using JS frameworks but now this feature is available natively. This means, that now we can import modules dynamically through variables in core-js.

// File 1
export blah() => console.log(‘Blah Blah’);
// File 2
import * as sayThings from ‘./file1.js’;
sayThings.blah(); // Blah Blah

globalThis: In Javascript, there are different ways to access global objects which makes it a bit tricky to write code which works cross environment. So, globalThis is here to rescue us all.

// In browsers.
console.log(globalThis); // window {...}
// In nodejs
console.log(globalThis); // Object [global] {...}

Optional chaining operator: This one is my personal favorite and it's really really useful when you have a long nested chain of objects and the checking is pretty much prone to error and not readable as well.

Let cricket = null;
Let getCricketTeam = cricket.teams;
// Uncaught TypeError: Cannot read property ’teams' of null
// How we can make this better
Let getCricketTeam = cricket?.teams;
console.log(getCricketTeam); // undefined

Note: It's possible that I may miss a feature or two which was introduced. However, all major features which are widely being used should be covered here.

ECMAScript 12 (ES2021)

Now with ES12, there can be features that may not go till the final stage of the proposal. So, here we will discuss the features which have actually made it till Stage 4 of the proposal.

Promise.any: This helps in returning the first fulfilled promise of the lot. In case, all of the promises were rejected; then it ends up with an error message saying all promises were rejected.

const p1 = Promise.reject(‘Fail’);
const p2 = Promise.resolve(‘Passed’);
const p3 = Promise.reject(‘Fail 2’);
const aggregatedPromises = [p1, p2, p3];
Promise.any(aggregatedPromises).then((value) => console.log(value)); // Passed

Numeric Separators: We usually have a hard time read large numbers, numeric separators help with that giving us an option to separate it out by “_”.

let n = 100000000000000 
console.log(n); // 100000000000000
let readableN = 100_000_000_000_000; 
console.log(readableN); // 100000000000000

Logical operators and assignments: With ES12, they are trying to combine logical operators and assignment operators such as ??, || and &&.
- ?? Operator: We already covered the use-case of the null coalescing operator in this post, now this one combines with the assignment operator as well. What it does is assigns the right-hand side value of the variable to the left-hand side incase the left-hand side variable is either null or undefined.
```
let hello;
let helloWithValue = ‘hello’;
hello ??=helloWithValue;
console.log(hello); // ‘hello’
```
- || Operator: It is basically somewhat similar to ?? Operator but this one also works with falsy values.
```
let hello = false;
let helloWithValue = ‘hello’;
hello ||=helloWithValue;
console.log(hello); // ‘hello’
```
- && Operator: This one assigns right hand side variable value if the left hand side value is truthy.
```
et hello = true;
let helloWithValue = ‘hello’;
hello &&=helloWithValue;
console.log(hello); // ‘hello’
```
String.replaceAll: Early we had replace() method which used to replace only the first instance of the string; so this feature was a little too obvious required to replace all the matching strings.

let helloWorld = 'Hello world Hello world';
let hellosOnly = helloWorld.replaceAll(‘world’);
console.log(hellosOnly); // 'Hello Hello'

Intl.ListFormat: It is an constructor for objects which formats as per the passed language code in the parameter list.

const Arr = [‘Hello', ‘World’];
let deObj = new Intl.ListFormat(‘de', { style: 'short', type: 'conjunction' })
console.log(deObj.format(Arr)); // Hello und World

Similarly, we have Intl.DateTimeFormat available which works in the same way as the list format.

That's all I had!

Some references:

Visit Auth0 to get to know a little bit more about JS history.
Standard JS documentation, click here to visit.

Thanks for reading. 😃
Visit my blog for the original post.

How to plan and execute your first mobile app using React Native

Love Huria — Sat, 24 Oct 2020 17:08:42 +0000

To give some background, I steered a project this year which was a hell of a challenge for me. "A corporate B2B2C mobile application". In this project, I understood the meaning of contributing not only from a programming point of view but also thinking through all aspects of it i.e. planning, setting up a foundation, asking the right questions to business, identifying tools, development/deployment practices along with keeping in mind that app also needs to be delivered on time.

So, I thought about penning this down, because initially, I had to do a lot of exploration, at some places I got lost as well; therefore I am optimistic that this post will help someone who’s trying to achieve the same.

Before we get into the tech side of it i.e any of the groundwork; it's essential that the scope and designs are clearly communicated to Business stakeholders considering what are we going to cover in a defined time-frame.

Getting started with the "Discovery and Design" phase

For any project, or to be specific mobile-application in our case; laying down different features required in the system like offline capability, barcode scanners, background streaming, user's privacy & standard business requirements should be discussed and sorted out in its initial phase.

I have seen it happen that in the mobile world; one thing could be obvious to your stakeholder but not to you.

That's what this discovery and design phase includes.

Listing down requirements

This included:

the list of features we were going to deliver to the client with all possible workflows and getting their approvals on it keeping in mind any kind of change requests asked by the business during this phase.
the list of devices we were going to test mentioning different resolutions, OS, etc.
the list of devices that would be tested on simulators or on a real device.

Focusing on user experience

We believed in total transparency of showcasing the designs, having weekly demos, getting feedback from the stakeholders pro-actively. These meetings were important for everyone to understand how the mobile application will look and behave like; ultimately coming to a consensus.

Important stakeholders who should participate during this activity

Design Lead
Technical Lead
Project Managers
Business stakeholders

NFRs

Along with the features list and scope, we also thought about NFRs from a mobile app perspective. NFRs should also be discussed and prioritized amongst your stakeholders, there is a need sometimes to put the perspective in place; otherwise, it will be just a clone of your web application.

Some examples of NFR may include

Responsiveness: In this case, handle any kind of interruption usually by calls, text messages, switching apps, etc, and reverting back to the same state which you were doing before the interruption without losing your progress.
Screen Adaption: With different mobile devices, we get various screen sizes and applications should be able to adapt to it.
Slow Connection / Handling n/w coverage: Here, need to take care of the slow connection, show a proper message in case the app is not able to perform certain operations.
Performance: This covers app startup time, quick scrolls, switching b/w operations, etc.
Security: This means mostly using an encrypted data store (e.g. keychain), enabling ATS for secure communication, etc.

Get your Style-guide ready

Once you are sorted with designs, getting them approved; the next task for the designer would be to get the style guide ready for the developers to reference. It's highly important in order to start any of the development work or strategize your components.

Usual aspects of style-guide are

Font sizes, family to be used
Error/success message variations
Toast messages variations
Type of buttons
Color palette (Branding)
Form fields variations (Text, Checkbox, Radio, Switch, etc.)
..so on

Technical Phase

Bootstrap

What gives me the confidence to execute anything, in general, is breaking down things into smaller chunks and that is the case even with new tech or tech which I am confident with. If I have to give advice to someone on how to start a new project, I would say, sit down alone, think through and prepare a rough list of how would you want to break and execute. Define tasks and their outcomes.

And this is the first step I did!!

Setting up React native on local along with code versioning

As choosing a technology or a framework was a pre-requisite, setting up React native on local made sense. You might be thinking, what’s the big deal with that. There is NOT.
It just gives a sense of achievement we kickstarted and it's not like you are not going to need it. 😉

Tasks to be done as part of setting up RN on local

Set up a Github or Gitlab or bitbucket (Whatever you may like to use) with standard environment branches like development, staging, UAT & Production
Setup the minimalistic React native application using RN CLI or Expo (I am not here to help you choose the one). But as a matter of fact, we chose RN CLI just because of the simplicity.
Setup environment files (We used React native config package to use inside the application, it's pretty good).
Add a basic Readme file with instructions for the team on how to run the app on local.

Next step was...Enforcing linting using Pre-commit hooks, editor configurations

This was really important, because when reviewing code; you will see a lot of indent issues, basic standards not being followed in the team. So, it makes sense to set it up in the first place and enforce it.

Tasks to be done as part of enforcing standards

Setup Linter and Prettier rules for the application
Add a pre-commit hook with ESlint rules in place
Define an editor config to be used by the team (Assuming we’re using VS code) 😉

Decide on the directory structure

When you have a team working remotely, it's hard to have them follow the rules w.r.t structuring your components, files, directories, etc since React does not enforce any. So, sitting with the team and hear our how would they like to structure the application and why. Consolidate things, and define rules on what to call what, what to put where, etc. This worked perfectly for us and it went super smooth.

I have a short post specifically for this. Check it out

Analyse essential libraries/packages to be used

When you are working on React/React-native or any other JS framework, one of the important decision is to decide on the libraries. From my experience, a single bad decision on choosing a library that is going to be widely used can end up as a complete app refactor. That’s something that happened to me, so I’d argue that you take your time, check the pros and cons of the library, compare it with others, and then decide.

What we look for in a library

Regular updates
Open issues
Community adoption & support
Size
Documentation

Examples of most common use-cases for analysis

Forms Library or Custom forms
Styled components or SCSS or a mix of both
Choosing Storybook
File upload/picker
UI library or Custom components/theme

Setup basic Typography

Assuming that we have a style guide provided by the UI designer, the next step would be to analyze and come up with the list of re-usable typographies that will be used throughout the application.
This is necessary since you don't want the team to create the styles again and again when they feel the need.

Example of Typography components

Heading
SubHeading
Section
Body
Paragraph
Link

Setup Theme

When you are working on a mobile app, there is a good chance that you will need to take care of dark mode as well.
For that, it's essential that we keep the strategy of plugging in modes as and when required.

Tasks we did to make sure our app is ready for dark mode requirements

Setup a theme provider
Create both light.js and dark.js theme
Setup the branding colors, fonts, basic spacers, etc.

QA Phase

Setup beta application

In order to set up the distribution means or link the application to a business entity, we would need an application setup in the App Store. Using which we will be able to get our application tested via Testflight or exporting an IPA/APK file respectively.

Tasks to do here

Setup test application for different environments
Enable QA’s to download the app via Testflight
Automate the build & distribution process via CI/CD service (e.g. App Center)

Choose a Profiling tool

A profiling tool is necessary in order to look for potential bottlenecks during development. And this process should come as a part of your development cycle without worrying about the impacts/problems that might show up later.

Business Phase

Involve stakeholders for app submission info

Now, when you are in the phase of submitting your application, Apple will ask you a good amount of business information which you probably would not have the information handy. I’d suggest starting this conversation a bit early in the phase so there are no surprises or delays. That's something we did and which I feel was a smart decision.

Example of what type of information would be required

Name of the application
Support URLs
Category of the application
Screenshots
Keywords
Description
Age Rating and so on...

That's all I had!

Thanks for reading. 😃
Visit my blog for the original post.

What is IAM? (A beginner's guide)

Love Huria — Mon, 25 May 2020 14:01:18 +0000

Ah, it feels good to be back into blogging days 🤩. So, a little bit about what I’m up to these days; I am currently engaged in helping build an identity and access management solution for one of the projects. Now in IAM, there are a lot of things to cover but we will focus on the basics of it. While working on this piece, I have realized that the core concepts are often a gap in understanding with respect to what it actually means. So, I am here to share the learnings in this post as per my experience.

What is IAM (Identity and access management)?

If we wanted to understand in simple words, let's break it down:

The first word is Identity ~ This, we can relate to the punch card attendance system. It's usually a flat and stiff paper and contains digital information, people just need to wave near a reader, and then ensures whether the correct person is logging in/out. Similarly, here it also means verifying the user who they claim to be.
Second is Access ~ This determines what level of access is provided to an individual. An easy way to understand is if you go to a nightclub/Casino, and there are guards taking care of who is allowed to come in, who can access the VIP area.
Third is Management ~ All of this falls under IT (Security) departments to manage the access control, policies, reporting, etc.

A little more about it:

Identity and access management also called Identity Management system (IDMS) in the enterprise is as crucial as anything these days and it's all about setting up standards and addressing the needs around enabling the right access at the right time for individuals to access not only IT resources but the hardware and applications employees require. It's often required to meet rigorous and complex security compliance requirements.

IAM’s pretty popular especially with enterprises as there is a critical need to manage information that is spread across internal and external applications with data security in mind.

IAM’s core objective is to assign one identity per individual and have the ability to control it from one place which would help reflect in all systems. It also helps the ability to monitor user’s activities, permit user roles, enforce policies at org level which is an on-going process (basically handles authn (Authentication) and authz (Authorization)).

How IAM works?

IAM is designed to perform three things -

Identify
Authn (Authentication)
Authz (Authorization)

A lot of people gets confused b/w Authentication and Authorization, ill try to explain in a simplistic way:

Authentication: When you enter a username/email & password into an application, the app tries to authenticate by checking the database and if the information which you entered matches; that means you are authenticated.

Authorization: This simply means the level of access. For example: If you log in to Facebook, you are allowed to see other’s profiles but not modify it.

That being said, here are the core components of any IAM system:

Identity Management: As the name suggests, it means managing every aspect of an individual’s identity. This includes managing Onboarding (provisioning), offboarding (de-provisioning), and on-going sync from the source to target systems/directories. And there are multiple identity protocols being used such as OAuth2.0, OIDC, SAML, LDAP, etc. For Identity management to happen, there are few building blocks required:
1. Source: The origin of the individual (from where the identities originate) i.e kind of a directory of the personal data used to define individual users. This is usually done by looking at the applications which contain staff data to be the source of truth.
2. Central Repository: For user’s information to be consistent b/w source and target system, syncing is essential. And for syncing to happen, it's important to have a central store that presents a logical view of the identities of an enterprise. It usually works by identifying a unique identifier basis to ensure that the provisioning, de-provisioning, updates are happening accurately.
3. Target: These systems can be defined as any application being used which requires authentication and authorization. For example, company portals, mobile apps, etc.
Authentication: Today, authentication does not only mean entering credentials and logging into a system but also making it secure by adding MFA, adaptive authentication.
Authorisation: After authentication, the next step in any Identity and access management system comes is authorizing the users for assigned access to specific apps, resources based on the user’s provisioning.
Reporting: This is all about recording, capturing user activities, auditing, monitoring, etc. This ultimately helps enterprises prove compliance with regulations, identify and address any potential security risks, and improve it further down the lane.
SSO: This is my favorite, one the best ones. Keeping security in mind, it enhances the user experience a lot since the number of credentials an employee requires to access is automatically reduced. And it's much easier to control the user’s access from one place. I read somewhere, SSOs become SPOFs if not implemented correctly, and here too a centralized IAM system allows to control access more efficiently.

Why do we need IAM?

Security: This is one of the core motives for any organization introducing IAM i.e controlling access which ultimately results in preventing identity theft, illegal access to sensitive information. It can also prevent unauthorized logins, protect against phishing attacks (and other cyber attacks). It also incorporates proper reporting, regardless of the application, platform, decide (Including BYOD options), helping with Location flexibility.
Compliance: IAM is not just about keeping things secure; intact following certain regulations according to the region is also crucial. So, compliance like HIPAA, PCI, GDPR, etc can be ensured since IAM specify strict protocols to control what and how of n/w and resources users can use.
Cost Reduction & Maintainability: If there is any change to the organization-wide followed policy e.g. “Password Policy”, then with IAM, it can be done in one go. Hence reducing the workload of requests to the IT team to do it. Furthermore, it reduces Identity management costs like Onboarding, offboarding, implementing policies, processes, etc
Improves User Experience: IAM helps with implementing the “Single sign-on” feature which is really trending especially in enterprises. With SSO, the user does not need to enter passwords to access multiple systems.

Must-haves before/during IAM implementation:

I was reading one article about the concept of putting all your eggs in one basket is a bit scary. A centralized system may seem tempting but its also usually an opportunity for hackers and by putting dashboards, monitoring user’s activity closely will help prevent it.
Working with legacy systems since most of the enterprises try to work it out but sometimes that’s not how it works with newer tech. Keeping the legacy systems alive with redundant workloads/tasks should be avoided as much it’s possible.
Collaboration is important across different departments is necessary. Working with our stakeholders step by step with everyone’s buy-in help in the long run for taking crucial decisions.
Multiple sources of identity information creates issues as well sometime, but the IAM system should be able to take care of that beforehand; synchronizing the identity across different systems.

That's all. If you would like to read more about it, I'd refer a few good links to go through:

Thanks for reading. 😃
Visit my blog for the original post.

Structure a React Native App

Love Huria — Sat, 11 Apr 2020 10:34:08 +0000

Heads up! The structure proposed in this post is not official, it just worked nicely for me and hopefully, it will help someone else on this earth. 🙂

Here we are, writing my first post around React Native after successfully launching an app in the App Store. Not at all showing off. It was a Team effort.

But it really gave me insight with respect to "How to work around mobile apps" after being in web stack for so long. Fantastic change and am really in love with "React Native". 🤩

This post is specifically about how to structure your React Native apps/projects in terms of folders/files.

Background of "Why this is even helpful"

React is created by Facebook and being used by a variety of organizations. So, Instead of being opinionated on the folder/file structure of the application, its left to the individuals to decide how they would like to build it.

This further leads to different approaches proposed by either community or individuals solving different problems.

Structure we follow

Below Structure assumes the following (But not mandatory in all projects):

You have Redux in your architecture
You have support for dark mode as well

If you look at the above structure, most of it is self-explanatory. However, I would like to focus on some of the aspects.

src/api
- helper.js - This file will have helper methods w.r.t any code related to APIs. Like get, post, put, etc.
- utils.js - Here we could add usual utility functions.
assets
- icons - Keep all of your icons (SVGs) or any other format you usually use.
- images - Keep all of your images (background images), logos, etc.
- themes
- light.js - Have all of your light theme styles here such as color palette, fonts, etc.
- dark.js - Have all of your dark theme styles here.
- themeProvider.js - This will contain the logic of deciding which theme to use based on the User's preferences.
components
- common - This will contain re-usable isolated components like button, input, tabs, etc.
- sections - This will contain reusable sections like navigation i.e sidebar, bottom navigation, etc.
config - I find this particularly very useful, we keep all the configurations with respect to say forms, static lists, action messages, validation messages, etc.
features - A lot of people call this directory as components as well, which seem confusing to me as we can have more components inside features as well. This will have standard modules/features, the basic functionality of the site.
global - This will have global functions that can be reused throughout the application.
routes - This will have site-level navigation defined.
- routes.navigator.js
store - This will contain the app level state management which will serve the app current state.

Keep in mind, that this structure is not specific to react-native, we could use in "React" projects as well. That's up to us.
Furthermore, the structure does not include core files such as package.json, babel, eslint, etc as they are mostly going to be at the root anyway.

That's all. If you would like to read more about it, I'd refer few good links to go through:

Best Practices for React native apps

Thanks for reading. 😃
Visit my blog for the original post.

Understanding Time complexity - Big O Notation

Love Huria — Sat, 26 Oct 2019 09:39:25 +0000

Lately, I have gotten an interest in algorithms, the first one I chose to understand deeply is how sorting algorithms work and their time complexity. However, this post is not to explain sorting algorithms, instead, we will take a step back and understand time complexity [Big O Notation] in the simplest way possible.

Before we go any further, let's understand what is an Algorithm:

An Algorithm is a step by step instruction, telling a program to execute in a certain way to solve a particular problem. And it's pretty obvious, that when we run a program in any language, it will have its own execution time depending on various factors such as input, operations being performed, etc.

Now the next question would "What is Time complexity"?

Time complexity is the execution time it takes for your algorithm to solve a problem. Simple, right?.

To explain it a little further, the time complexity is driven by two things i.e. execution time & the space required by the program.

Why do we need to measure the time complexity?

As programmers, when we write a program, it's kind of important to understand the different operations we are performing which can be checked by measuring the complexity. Normally, the execution time is taken for granted, we don’t care about mi-nute calculations which are happening behind the scene. So, overall, time complexity helps us to improve the efficiency of the code we’ve written.

How do we measure time complexity?

The answer is Big O Notation when the letter O means Order of the program.

Big O Notation (a mathematical expression) helps to measure the time complexity by classifying how your program behaves with varying input and taking in different operations.

Let’s understand the common types of notations, we will use Javascript here to explain with examples, although the idea is similar for different languages.

Types of Big O Notations:

Constant-Time Algorithm - O (1) - Order 1: This is the fastest time complexity since the time it takes to execute a program is always the same. It does not matter that what’s the size of the input, the execution and the space required to run this will be the same. For example: Take a case of simple array lookup or getting the last item of the array. The above example will always go through the array once and finds the salary of an employee called Joe. That means, constant (fixed) iteration is involved i.e O(1).
Linear-Time Algorithm - O(n) - Order N: Linear Time complexity completely depends on the input size i.e directly proportional. One of the examples could be just printing the elements from an array OR finding a particular match in an array. While calculating, we should always think of both the “best” & “worst” scenario. For example: If we were to match a specific element in an array, then it can be the very first one or the last one, so in that case, we can assume its O(n). Let’s take an example here:
Quadratic-Time complexity - O(n2) - Order N Squared: As the name suggests, the time to execute a program is proportional to the square of the input size. That means, in our program, when we are trying to perform two operations which are kind of a combination of Linear and Constant time complexity, then those are called Quadratic-time complexity. This type of complexity is commonly used with sorting algorithms. Let’s try to understand by taking an example: In this example, it is clear that we first have a single filter loop at the top iterating over an array once, then we have a nested loop that is looking for similar salaries of the employees by iterating through the array again.
Logarithmic-Time Algorithm - O(log n) - Order log N: This is considered the most efficient way to deal with a large number of data in a set. The idea behind this approach is to divide the data into chunks and then perform operations. A logarithm is basically a quantity that represents the base power, that means if the data grows logarithmically then it's literally being divided. For example, if we want to find a salary of a few employees from 50 records, then that means we usually have to go through each record and look for it. Assuming if we use log base 2, we would be able to find it in log2(50) = ~6 iterations. That is a lot of power! Its commonly used with different sorting algorithms such as QuickSort, Merge-sort which is usually used to find an element or sort a list. Or binary Search is a good example.

I think we've covered most commonly used notations. If you would like to read more about it, I'd refer a few good links to go through:

Thanks for reading. 😃
Visit my blog for the original post.

Creating your own React Boilerplate - For Beginners

Love Huria — Sun, 20 Oct 2019 08:47:35 +0000

Well, It's been a while working on React, still learning and it feels pretty awesome. We all understand how important it is to interpret the basic concepts before we set our path to work with any framework or library.

Usually what happens, even as a beginner we tend to jump on things without understanding how it works, to see the practical usage, fancy stuff etc and hey You are not alone!

But sometimes, it's good to come back on time and try to understand the underlying pieces. There are tons of boilerplates available which are really helpful to kickstart the project as a solid foundation and the plus point is most of these boilerplates are built by Industry experts.

Taking my past experiences into account, there have been multiple React projects I have worked upon; so sooner or later we get to overcome the fear of setting up our own package.json and webpack configurations.

So, here we will try to set up our own boilerplate or you can say our own way of React project set up with some interesting packages which normally get used at some point.

Now in order to build our boilerplate, the very first thing we need to understand is package.json.

What is package.json and why do we need it

The package.json file is an essential part of the Javascript (Node) eco-system. It’s like one of the very first baby step developers takes while starting development in Node.js. Also, It helps in streamlining the process, managing packages for your project. You can say, its essentially a manifest file that contains the metadata like name, description, package versioning etc of the project (All in one place).

Setting up package.json

Defining the metadata by typing it out i.e creating a package.json is always an option, but we don't have to do it in case you are setting up a new project. Instead, there are existing ways to commandify it. We can use standard package managers such as NPM, YARN as they help interactively in creating/updating a package.json file.

You must have heard about NPM, YARN, but in this post, we will be using Yarn to setup our react boilerplate. In case, you would like to read about the differences, check this out here.

Continuing, Let’s try to explain Yarn in the simplest way possible

Yarn is a package manager that lets you use code developed by the community from around the world which eventually makes things easier to build the solution.

This collection of functionality is something called package.

To set up package.json, Yarn provides an initialize command, which will give you a kind of a questionnaire about the project and that tends to be your project’s metadata.

// Run `yarn init` in terminal.
> yarn init

After filling in all the required information, it will create a package.json file at the root of the project’s directory. It should look like:

What does this mean to us?

Let’s talk about it one by one:

name: This contains our package’s name and it does not allow spaces and instead it should be lowercase separated by hyphens/underscores. For example: react-boilerplate. 😊
version: This is the standard metadata for any kind of module, it should be in the format 'x.x.x' (Usually starts with 1.0.0). It follows semantic versioning (semver). Read more about it here.
description: This is just a human-friendly description of your project/module. It helps developers to understand quickly regarding the intentions of the project or module.
main: This can be taken as the bootstrap file i.e an entry or lookup file when application boots up. Usually index.js, but it's upto us to change it or not.
author: This is generally a piece of information about who’s writing the project/module, could be name, email address, etc.
license: This explains about the license the project/module belongs to. It could be MIT, ISC, etc.

While can be few other questions which you probably won't see in the package.json file, but can add such as:

repository URL: Here we can mention the URL where the code is being hosted, so developers can check more details.
private: If set to true, then you won’t be able to publicly release your project/module to the community. Prevents accidental publication.

Now that we understand the basic metadata of the package.json file, let’s go ahead and set up our boilerplate (for which the post was intended for 😉).

Setup minimal React boilerplate

Quicktip: To add packages using YARN, we can use yarn add <package_name>, yarn add --dev <package_name> (To add as dev dependency) similarly to remove; use yarn remove <package_name>

Installing React and ReactDOM: React (Javascript Library) package contains just the code required to define react components, state, props (All that is React) where React DOM works as a React renderer for the web, it works as a glue between React and the DOM. If you see your package.json file, there should be React and ReactDOM listing under the dependencies of your project. It indicates, that now your project depends on React and ReactDOM. You might have noticed that there is a new directory created node_modules at the root of your project. This is where your installed packages will be kept. If you check there should be a React directory under node_modules which helps run React for the application. To use the React functionality, you might want to import it in your .js(x) file like:
Webpack: In simple terms, its a bundler which helps bundles your files, images, assets, scripts, styles, module dependencies. It takes in modules with dependencies and spits bundled code which browsers can understand.

We can install web pack using Yarn as a dev dependency:
Babel: While working on React, we usually follow ES6. Since older browsers can not understand the syntax say Class keyword, import statements. For these to be converted to ES5 which browsers can understand, we need Transpiler. That’s how Babel comes in picture.

You are probably thinking, then what is the use of Webpack?

Webpack does not have the capability to transpile the code from ES6 to ES5, but it has this concept of loaders which helps in transforming the code and outputs the browser-compatible code.

Loader, which we will use is babel-loader which internally used Babel and requires a certain level of configurations/presets i.e babel preset env (Used for transpiling code from >=ES6 to ES5) & babel preset react (Used for transpiling .Jsx code to ES5).

Let's install and configure babel and the required dependencies:

To complete the setup, we would need to create a file called .babelrc and define the configuration as below:

To set up the babel-loader and make it work as a web pack loader, we would need to define the configuration like below in a file called webpack.config.js at the root of the project:

If we want to decode the configuration, then it's just telling Webpack to take in js, jsx code and use babel for transpiling and output the ES5 browser compatible code.
HTML Webpack Plugin: This plugin helps to generate HTML files which ultimately serves Webpack generated bundles. That means, when webpack creates a new javascript bundled file, then it also needs an html file to serve on the client-side with the latest changes.

Let's install the plugin and the loader as a dev dependency:

Wait, we are not done with the HTML plugin yet, we would need to configure it with Webpack as well. Earlier we defined, babel-loader to transpile the code, now we would need to define html-loader for generating the HTML.

// Load the plugin in your webpack.config.js file.
const HtmlWebPackPlugin = require("html-webpack-plugin");

module.exports = {
  module: {
    rules: [
      {
        test: /\.(js|jsx)$/,
        exclude: /node_modules/,
        use: {
          loader: "babel-loader"
        }
      },
      // Add HTML loader to serve HTML files.
      {
        test: /\.html$/,
        use: [
          {
            loader: "html-loader"
          }
        ]
      }
    ]
  },
  // Call the Plugin here.
  plugins: [
    new HtmlWebPackPlugin({
      template: "./public/index.html",
      filename: "./index.html"
    })
  ]
};

The setup is almost complete, but there is a downside to this. Whenever we will make any change to the code, we would need to manually refresh the page to see our changes. In order to overcome this problem, we can install another package called webpack-dev-server as a dev dependency.

To make this work either webpack command directly or its best that we modify our package.json and add:

// Open flag is for opening the browser as soon as we run `yarn start`.
// Hot flag is for hot reloading i.e refresh the page as soon as you make any change to the code.
"scripts": {
  "start": "webpack-dev-server --config webpack.config.js --open --hot",
  "build": "webpack --config webpack.config.js"
},

Running the React Application

Start by creating a folder called src/ which will contain a couple of files such as index.js (Rendering the app) and App.js (Contents of the App).

This is just a dumb component which is exposing some static text:

This is importing the dumb component we just created and rendering on the page, basically injecting on the element ID react-app-container.

Now, you can start your application using:

> yarn start

Should get something like this in your terminal:

And we're all set here.

You can check out the boilerplate for the complete folder structure here.

Thanks for reading. 😃
Visit my blog for the original post.

Time to level up Code Reviews

Love Huria — Sun, 29 Apr 2018 18:50:51 +0000

This is a follow up of my previous blog post on code standards.

So, Being part of a Code review process is very important for me and trust me I take it very seriously. This is required not just for the team but for an individual learning as well.

Code reviews are very crucial for knowledge transfer and to avoid making small/common mistakes and of course maintaining best practices throughout the dev team. So Let’s take my team for example: we are around 12-15 developers in the team, all producing code which needs to be reviewed. So basically yeah that’s a whole lot of code!

Why It’s Important

Pushing code to production is easy. Anyone can do it, right? What concerns us that what pieces we are going to deploy.

The code can be completely fine or it can be a piece which can make everything fall apart. To maintain high code quality, we all need to have Peer code reviews. There is nothing negative here, we all are on the same team and we have a common goal that is to deliver the highest quality product.

You must be thinking, Is it worth it? No? Yes?

Definitely yes, Not having code review integrated into projects can result in big problems. You may have heard of the disaster happened long back: Here you go.

There was a lot of reason why this incident happened and one of the reasons was an absence of a peer code review. After reviewing their source code they found – possible bit flips, task deaths that would disable the fail-safes, memory corruption, single-point failures, inadequate protections against stack overflow and buffer overflow, single-fault containment regions, thousands of global variables. The list of deficiencies in process and product was lengthy.

How we roll things

General Development Process

FYI ;)

Green line: Determines pass status.
Red line: Determines fail status.

This is our general flow which is being followed in most of the projects, of course, columns may vary depending on the different aspects, clients, and projects. Hope it’s very clear 😓, if not I tried my best!! Haha 😄

Github Code review flow

Now it’s really easy maintaining your code review process just a few clicks away on GitHub (And it’s really awesome!). We can create new projects on our repo and use it as we want.

Generally, we have around four columns which are usually enough:

Ready for review: You can add cards (Pull requests) to this column if your code is ready to be reviewed.
In review: Now its code reviewer’s responsibility to move the card to "In review" column so that it gets updated on the branch and the concerned dev understands that his/her ticket is currently being reviewed.
Change Requested: Again this is code reviewer’s responsibility to move the card to this column if the review has failed standards. Then concerned dev will do the required fixed and need to push the ticket back to “Ready for review”.
Closed/Done: If the card is lying there in “Closed” column, that means the PR has passed standards it should have.

What to look for when reviewing

There are certain aspects which we consider while reviewing code and some of them are the following:

Best practices pertaining to Drupal standards. Can be found here.
JS specific coding standards. Can be found here.
SCSS specific coding standards. Can be found here.
Anything developed which is adding technical debt. For instance choosing an easy solution making it harder to implement changes later on.
Security issues
Potential Impacts which can introduce performance issues/threats to existing solutions
Solutions being developed which are already available in the codebase and can be reused.
General standards like formatting, linting issues, comments, naming patterns etc.

Who is responsible

We have set few guidelines on who will be responsible for the code review process. Here are the points:

There will be one Senior and one Junior Code Reviewer for each ticket.
Reviews will be done right after the daily standup. (Depending on how long it will take.)
One person will review at least one ticket in a day (If there is any ticket assigned on the board)
Tickets should be in respective columns according to the latest update. (Code reviewer & dev's responsibility)
If there is any feedback from Senior code reviewer, its Junior code reviewer's responsibility to look what he/she has missed.

Making sure the process being followed

We regularly come back and observe how we are doing according to set process and if there is any way how we can improve to make sure it's being followed and not a burden/blocker for any one’s work.

The process is clearly defined and maintained on different platforms depending on client and teams. We usually use Confluence and highly recommend it to anyone who is reading this post.

Learning from our mistakes

We have maintained a code feedback sheet where we mention common mistakes we need to avoid. Everyone has access from the team and can add points on where we can improve, new techniques to achieve certain functionality, strictly avoiding certain coding patterns.

Our goal is to
Enhance the learning of individuals to become better programmers.
Improving the quality of codebase, it gets complex to manage as it grows.
Not to deliver just quantity but quality throughout.
Maintaining discipline within the team and understand the seriousness of spaghetti code.

That’s about it! Few things I may have missed for sure in this. Connect with me at lovehuria@gmail.com if you would like to know more OR just comment down here and save me all the trouble on checking my emails. :D

Visit the original post here. Thanks for reading :)

Keeping It Clean: Coding Standards That Matter

Love Huria — Sun, 22 Apr 2018 12:35:05 +0000

A year back, I was working on a project that taught me how to keep my code clean, modular, reusable, and all those terms that seem fancy, but are actually good for you in the long run. Interesting? Yeah a bit.

But what did I do after getting into those practices?

I made mistakes. Believe me, a lot of them. But with every mistake, I learnt a lot of stuff that I had never considered before. It helped me in my thinking process, on how we should build things, what steps we need to consider when we are developing/extending a feature. And most importantly, these learnings were not just personally helpful, but also crucial for team growth.

At first we used to get frustrated because we had to follow the additional process like adding documentation, maintaining changelog files, following the code standards, and keeping them consistent throughout the team. These extra steps seemed cumbersome and we were not able to relate how this can be useful for us (team). And we are still learning/improving everyday in this respect. But after few months we started loving and improvising the process.

So here I am, sharing my what I have learnt. And trust me when I say, after getting this into practice you can’t live without following this.

This post is focused on what practices we follow everyday to make our lives easier (More focused on PHP/Drupal but can be followed, we follow pretty generic practices).

Let’s start off with simple things:

Commenting and Documentation Standards

Commenting doesn’t mean adding a bunch of comments and random documentation anywhere while coding. There are things which you should mention to make your colleagues’ lives easier, and yours as well.

Start with writing a description of your component, why you are creating it, and what is the aim you would like to accomplish here, what does it do etc.
If there are modifications being done, then those should be logged by creating a Changelog.md file attached to your component. Maintain a specific format to have consistency throughout.

This is something we follow, hope this is pretty clear:
CHANGELOG.md file sample:

It’s good practice to add @see, referencing the class, which will help easily navigate to that class definition by using IDE like PHPStorm, or editors like Sublime etc with just one click.

Add @TODOS wherever necessary. It’s very important if you feel your code can be improved in future and you have the ideas on how to do it, but not enough time at the moment. Mention what needs to be improved above that code snippet. One good example could be:

Create README.md files so that others can easily understand what is the working of the module. For example:

A “Docblock” is a special code comment that offers an explanation of the purpose, arguments, return values, and throw exceptions for a block of code.

Something very informative in a simple tweet I found:

// Detect dark theme var iframe = document.getElementById('tweet-539547553608761344-400'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=539547553608761344&theme=dark" }

Formatting

This might include indenting, whitespace, brace positions, and new lines and this can be different according to different languages. In our case, this is specific to PHP (Drupal). There are a lot of plugins available in editors to beautify your code.

Naming Conventions

Of course naming conventions depend on the language you are using ( examples: Zend, Google style guides for PHP, CSS, Javascript, Java, etc ) but the main idea is to use descriptive and meaningful words. So, you should avoid calling your variables: xx, yy2, test1, test2 and so on.
For example, lower_case for PHP variables and functions, camelCase for JS variables and functions, lower-case-hyphenated for CSS ID's and classes, UPPER_CASE for constants.
We should name our variables in a way which easily explains the type of data they contain. Similarly in case of functions, they should describe what kind of functionality they are providing. This is called self-documenting code. Functions should tell what they do, not how. This is called abstraction which allows the underlying implementation to be changed without changing the function name.

Portability

Keep your code as loosely coupled as possible. It is "portable" in that the amount of work required to move it from one platform to another is low. There are few things we should have in mind while coding:

Avoid using hardcoded values like absolute file paths, URLs etc unless it’s a matter of life and death (:P)
Avoid using magic numbers in your code. Basically it’s a hard-coded value that may change at a later stage, and hence become hard to update. Almost all numbers other than 0, 1 or 2 should be assigned to a constant at the top of the file. This provides a single point of change if the value changes, rather than a search-and-replace that could affect many files and potentially introduce bugs.

Linters

There are different types of tools available to find syntactic discrepancies in general, especially in interpreted languages like JavaScript, PHP, Python etc. They can also be used as simple debuggers for finding common errors. Here’s a look at the common linters:

PHP:
- We use PHP Code Sniffer with Drupal integration. One can easily configure it with your editors such as Sublime which will show common PHP errors on save, which saves a lot of time and prevents errors before committing your changes.
Javascript:
- We have Drupal JavaScript coding standards (note - these vary in several ways from Mavericks standards) in place but we use JSHint for listing our JS related code checks.
- Wherever Drupal's JS formatting conventions conflict with JSHint, JSHint supersedes.
SCSS:
- We do not have any SCSS related documentation on Drupal.org but we do have Drupal CSS coding standards (these can be applied to SCSS code).
- You can find some documentation related to SCSSLint here.
- Also it’s good to checkout Compass best practices as well.

Reusability

This is something we are working on quite extensively. We are building reusable components which can be used in across different websites (which have almost the same purpose). These components will provide the basic functionality and styles which can be overridden in different websites according to their own requirements. The most important thing here is to identify what functionality can be turned into a component.The degree to which your code is reusable is largely based on how tightly it’s coupled with the rest of your code base. A good example can be building a banner slider which can be used in most of the websites.

Modular

This basically means keeping your code independent of others, so that one bad change to your code does not break everything else. This is similar to the concept of coupling in object oriented programming. It’s like breaking the website into its basic independent parts of a more manageable size.

Use Continuous Integration Tools

We use Travis CI. It’s a distributed continuous integration service used to build and test projects on github. The service is free for open source projects. You might be wondering why you didn’t you use it before! 😛 Don’t worry, It’s never too late and pretty easy to setup with your github repositories.

First step is to register Travis-CI, which you can also do with your github account.
Setup the .travis.yml file, This file handles the build of your environment and also the execution of the phpunit files.

You can check the simplest basic configuration here:

When you have the phpunit test in place and if it is passed, it will show something like this on your commit:

You can check the simple Travis setup here:

This .travis.yml should be at the root of the project.
Travis only runs builds on the commits you push after you’ve enabled the repository in Travis CI.

Code Reviews
We have pretty awesome code review process in place. But this blog is already too long, so I shall cover that in my next blog. Stay tuned.

Visit the original post here. Thanks for reading :)

Cool things you can do with Sass - Part 1

Love Huria — Fri, 20 Apr 2018 13:13:08 +0000

I have been using Sass for like past two years and now I’m a huge fan. Even though we were doing pretty much alright with writing CSS but it never gave us that kind of flexibility that Sass provides like one of the things could be managing the complexity in stylesheets as our apps get more and more substantial. Anyways, Enough about my experience already as today we have got a bunch of cool things to cover!

What is Sass?

It's a CSS preprocessor, that’s what you will get if you start googling and its true but hold that thought as there’s more to it.

Sass lets you use features like variables, nesting, inheritance and all with a CSS-compatible syntax. This is really obliging when you want to reduce repetition and make your massive stylesheets more organised.

Important: It's not a replacement for CSS, its kind of an interpreter/transpiler which spits out CSS in the end actually.

You must be thinking, then what is the difference between Sass and Scss?

Sass is itself carved into two types of syntaxes/file types: .sass & .scss.

Sass (Older syntax) was not quite accepted by a large audience. The reason was mostly because it's indent based instead of braces and it didn’t require semicolons, which increases the probability of human errors while writing.

Where Scss (New syntax) was widely accepted because it's quite similar to the way how we write CSS. Its kind of a win-win using Scss as we get to write stylesheets like CSS but we still get the benefits of Sass. Awesome!

From now on, this article will assume that you understand Sass and well versed with its basics and practical usage, if not refer to this for more information.

Without further ado, let’s hop on the cool things we can use while writing scss:

Using variables as a selector

We can define our selectors and use it in our stylesheets.
For example:

// Define your base selector.
$header-base-class: '.header';

#{$header-base-class} {
  background: white;
}

// Compiles to css
.header {
  background: white;
}

Or, there could be a whole lot of use-cases where this can be super useful! Like umm.. in Media queries? Let’s go through it:

$small-only: 640px (Define somewhere else like maybe in _settings.scss)

@media (max-width: #{$small-only}) {
  // Here do your thing, the styles will only be applied to viewport < $small-only breakpoint.
}

Easy-peasy right? 😃

Now you don’t have to define a hardcoded value in each of the media queries. Just change at one place like in this case _settings.scss and get the results everywhere.

Parent referencing using a prefix

You must be familiar with & ampersand prefix we generally use. This syntax generally allows you nest nested selector modifiers with reference to its parent.

For example - You would like to change a div's background colour on hover.

.highlight {
  &:hover {
    color: red;
  }
}

// Compiles to css
.highlight:hover {
  color: red;
}

But & can also be used just as a prefix to reference its parent.

Let’s say you have a base selector and want to apply particular style only when there is some specific class selector exists, usually, we tend to do something like this:

$base-item-selector: '.base-selector';

#{$base-item-selector} {
  &--conditional-selector {
    #{$base-item-selector} {
      &__details {
        display: none;
      }
    }
  }
}

// Compiles to css
.base-selector--conditional-selector .base-selector__details {
  display: none;
}

With Parent referencing prefix, we can modify it to be:

#{$base-item-selector} {
  &--conditional-selector & { // See the usage of ampersand here
    &__details {
      display: none;
    }
  }
}

// This will also compiles to similar css.
.base-selector--conditional-selector .base-selector__details {
  display: none;
}

Cool, right? Saved one depth and looks more organised.

Defining variables as defaults

Using Sass, we can set variable precedence & scope with the help of !default flag.
Placing !default at the end of declaration actually does the following things:

If you have defined a variable as null, it will be considered unassigned and will be assigned with !default.
If the variable is assigned some value already, then it will not be re-assigned.

Confused? ok, Let's talk it out.

For instance, we have defined a text color as red, the normal process follows like this:

// _my-component.scss
$text-color: red !default;

a {
  color: $text-color;
}

// Compiles to css
a {
  color: red;
}

Makes sense so far, right? ok, let's continue. So, now you can override the colour while importing the component styling.

$text-color: blue;
@import ‘my-component’;

// Compiles to css
a {
  color: blue;
}

What this means is !default flag will only work if the values have not been already assigned/instantiated beforehand, otherwise it will be overridden.

This is an important way of writing modular CSS. That’s why we tend to define most of our variables in a file for better accessibility. The !default flag is very useful when using with mixins and plug-in type code.

One more interesting example you can find here

Mixins and Custom Functions

Mixins and functions both exist in the same family because both accept variables as arguments but have somewhat different responsibilities. Let’s discuss one by one.

Mixins: Mixins can accept arguments and do the required calculations you need but the output of a mixin would be a CSS rule.

It will unfold itself when called with @include.

For example, suppose we need to defined different typographies in our app. Then creating mixins would make more sense:

// _my-typography-rules.scss
@mixin my-typography-small {
  font-size: .75rem;
  font-weight: 300;
  letter-spacing: .01em;
  line-height: 1;
}

// _my-component.scss
#{$base-selector} {
  @include my-typography-small;
}

// Compiles to
.base-selector {
  font-size: .75rem;
  font-weight: 300;
  letter-spacing: .01em;
  line-height: 1;
}

Functions: Its very much similar to mixins but in case of output it returns a single value. Just like we have custom functions in every other language, using custom functions in sass can be very healthy for your application.

The Return value from a custom function can be of any data type. e.g. number, string, bool etc.

One of the best example we have here is calculating rems based on a base unit size. We are using this quite extensively in our application and this is something which can be used anywhere. Very generic!

Let's say, we are using rem unit with font sizes and everytime we use rem unit, we had to do manual computations. Sucks!! Isn't it?

How we really calculate rem is by dividing the target size/base size = your result. So the below function will give us the desired results and we can use it throughout our application.

//_utility.scss
/**
 * Calculate rems based on a base unit.
 */
@function remCalc($size, $base) {
  $remSize: $size / $font-base-size;
  @return #{$remSize}rem;
}

// _my-component.scss
a {
  font-size: remCalc(20, $font-base-size);
}

I hope that now you get why Custom functions are really helpful as they help us avoid repeated computations. SCSS gives us a ton of inbuilt functions which you can have a look here

It’s always best to check in-built function first rather than creating your own every other time.

Default Arguments

This is high time we talk about default arguments as we just wrapped up mixin and custom functions. They're kinda related.

Mixins and custom functions both support arguments and icing on the cake is we can define default arguments as well.

For example:

@mixin abc-with-margin($x, $y, $z, $margin: 20px) {
  // Do your stuff with x, y, z.
  margin: $margin;
}

// _my-component.scss
#{$selector} {
  @include abc-with-margin(12, 23, 34);
}

// Compiles to css
.selector {
  // Stuff we did with x,y,z.
  margin: 20px;
}

We can also override the default value. e.g.

// _my-component.scss
#{$selector} {
  @include abc-with-margin(12, 23, 34, 10px);
}

// Compiles to css
.selector {
  // Stuff we did with x,y,z.
  margin: 10px; // Overridden.
}

Extending your selectors

Using Scss, you can combine your selector's styles in the CSS output. As we inherit properties from the parent class or whatever, this is quite comparable to other programming languages but the process is very different. Again, the aim is to reuse different selector’s styles so that we do not have to rewrite the code which is already being used.

.menu {
  background-color: white;
}

.header-menu {
  @extend .menu;
  color: black;
}

// Compiles to css
.menu, .header-menu {
  background-color: white;
}

.header-menu {
  color: black;
}

As we can see now .header-menu has all the properties of .menu plus the properties it already had. Traditional inheritance right? Now, whatever .menu will define it will be inherited by .header-menu and can be easily overridden as well.

You must be thinking, why can’t we just use mixins here and just get it over with, why another logic. I'll show you why not.

If we go along with mixins:

@mixin menu {
  background-color: white;
  font-size: 1rem;
  font-weight: bold;
  color: grey;
  padding: 20px;
}

.header-menu {
  @include menu;
  color: black;
}

.footer-menu {
  @include menu;
  color: black;
}

// Compiles to css
.header-menu {
  background-color: white;
  font-size: 1rem;
  font-weight: bold;
  color: grey;
  padding: 20px;
  color: black;
}

.footer-menu {
  background-color: white;
  font-size: 1rem;
  font-weight: bold;
  color: grey;
  padding: 20px;
  color: black;
}

See how the last property is different and as soon as the amount of menu types increases will result in more and more repeated styles with each type of menu keeps on growing. This problem can be overcome by extending your selectors.

Another advantage is it can be used with UI libraries such as foundation, bootstrap etc. One interesting read is how we can extend complex selectors here.

Placeholders

We will take the help of a previous example, we just created a .menu selector just so that child selectors can inherit styles. But what if the case is that this selector does not even exists or not being used anywhere but only through its child classes. We might as well get rid of it.

Just to clarify few things before we move ahead:

.menu is considered as a class.
#menu is considered as id.
%menu is considered as a placeholder.

Just so we don't get confused between these.

This will result in same output as it was with the previous one.
For example:

%menu {
  background-color: white;
}

.header-menu {
  @extend %menu;
  color: black;
}

.footer-menu {
  @extend %menu;
  color: gray;
}

// Compiles to css
.header-menu, .footer-menu {
  background-color: white;
}

.header-menu {
  color: black;
}

.header-menu {
  color: gray;
}

The only difference is that the menu has disappeared from the output as it was just a placeholder selector. This is really helpful because you are using the things which should only be outputted into the resulting CSS. For more information, read about placeholders here.

Ok, Let’s wrap up. I wanted to cover Control directives in this as well, but that's a vast topic in itself. We will figure it out in my next blog. Stay tuned!

Thanks for reading. 😃

Visit my blog for the original post.