Stories by Yashika Garg on Medium

Typography Series (Part — 2) — Major challenges

Yashika Garg — Fri, 28 Sep 2018 17:05:16 GMT

Hola folks! This blog series about Typography has two parts

Importance and basic terminology of typography that every frontend developer should know. Check it out here.
Major challenges faced while getting typography right.

If you haven’t already been through basic typography terminology, check it out here. In this blog post, we will be discussing the major challenges we face in order to get the typography right on our websites. So, let’s get started.

Major Challenges

We have been through some terms in Typography world and we are now aware of some fundamentals. Now let's try to solve some problems we face when we try to set typography of pages of our application.

Let’s see a page with bad typography.

Bad Typography Example

We apply our knowledge step by step to improve the page’s typography and make it look like this.

Good Typography Example

Different font sizes for different screen sizes. When we move from large desktops to medium screens or tablets or mobile screen which in themselves have a large range of screen sizes, we want our content to adjust and stay readable. To achieve this we can make use of media queries in our CSS files. Adjust font size for different headings and paragraphs to make them look pretty on different screen sizes. But there are hundreds of screen sizes and it’s entirely impossible to make adjustments for each of those.

CSS world has frameworks like bootstrap and gaining knowledge from them, we can try to find the solution to our problem — Breakpoints! Here are some commonly use breakpoints:

xs - 480px - small screen phones
sm - 768px - Tablets and phones
md - 992px - Desktop
lg - 1200px - Wide Desktop

As clearly visible, the second image looks much better for the small screen as compared to the first one. This is the magic of media queries.

Attaining Vertical Rhythm. Firstly, I would like to put some light on what vertical rhythm is. It is a phenomenon of keeping consistent vertical spaces between different elements on page. Vertical rhythm help us establish hierarchy on page and convey the relation how different content is connected to each other. It gives a very professional look to our page. To achieve vertical rhythm, we need a base line-height value and compute all our vertical spaces, i.e., margins, paddings, line-heights, as a multiple of that base line height. To figure out our base line-height, we need to find the value of a vertical space which gets repeated most on our page. For instance, what is the most common margin or line-height or padding we are using in our page. This value would be our base line-height. We will be repeating this value on our page to bring consistency and this repetition has to vary. We definitely don’t want each of our vertical space to be same. We need to be variable in order to establish hierarchy and relation between different elements of page. For achieving this variation we will use multiples of our base line height. We can use either LESS or SASS preprocessor. I am demonstrating using LESS.

@base-line-height: 24px;

p {
line-height: @base-line-height;
margin-bottom: @base-line-height;
}

h2 {
line-height: @base-line-height * 2;
margin-bottom: @base-line-height * 2;
}

h2 {
line-height: @base-line-height * 1.5;
margin-bottom: @base-line-height * 1.5;
}

With help of some CSS, I add these horizontal lines on our page to see how our content is vertically setup. In the first snapshot, you will notice that its pretty bad and there is no hierarchy at all. But as soon as we apply our varying repetition of baseline height, we noticed everything looks pretty good (Snapshot 2).

Update typography throughout the site. Sometimes you decide for your website a typography in terms of font-size for headings and paragraphs, vertical spaces and so on, and you grow your website on that. But at a later stage, you found that something is missing and it’s not fitting the way you presumed. Now you want to change it all through! Wait a minute! Change typography throughout the site, that’s a large amount of work and tedious. Changing each and every page, each and every element throughout the site. But its important you see. You need your work to match your expectation.

Lets try to think a solution for this. What if we set a base font size for our application and manipulate all other font-sizes and vertical spaces based on that. Now if we think of changing typography to lets say a bigger font-size or a smaller one, adjust vertical spaces, then all we need to do is to change our base font size and tweak our manipulations around it to handle this scenario.

@base-font-size: 15px;
@base-line-height: 1.6; // Unit less value
@computed-line-height: ceil(@base-font-size * @base-line-height);

p {
font-size: @base-font-size;
line-height: @computed-line-height;
margin-bottom: @computed-line-height;
}

h2 {
font-size: ceil(@base-font-size * 2.15);     // 32px
line-height: @computed-line-height * 2;      // 48px
margin-bottom: @computed-line-height * 2;    // 48px
}

h4 {
font-size: ceil(@base-font-size * 1.6);      // 24px
line-height: @computed-line-height * 1.5;    // 36px
margin-bottom: @computed-line-height * 1;    // 24px
}

Now I want to make things look bigger and all I need to tweak is following:

@base-font-size: 20px;
@base-line-height: 1.2; // Unit less value
@computed-line-height: ceil(@base-font-size * @base-line-height);

p {
font-size: @base-font-size;
line-height: @computed-line-height;
margin-bottom: @computed-line-height;
}

h2 {
font-size: ceil(@base-font-size * 1.8);      // 36px
line-height: @computed-line-height * 2;      // 48px
margin-bottom: @computed-line-height * 2;    // 48px
}

h4 {
font-size: ceil(@base-font-size * 1.4);      // 28px
line-height: @computed-line-height * 1.5;    // 36px
margin-bottom: @computed-line-height * 1;    // 24px
}

Responsive designs I know you have stick too long and I swear this is the last challenge. We have read above that we need different font-sizes for different screens. Along with that we need our pages to be responsive, to be fluid as we move from different ranges of devices. We need our vertical spaces and paddings to fit in every scenario.

Thinking about this, we have everything we need to beat this up. We will use media queries, we will make computations on base-font and we will use our scalable unit.

Remember, we talked about them just a few minutes before — Em and Rem.

Lets use rem and we know it is relative base font size of root element. If we adjust the font size for our root element for different screens using media queries and make all are manipulations in terms of rem, we are all set :). Let see

html { font-size: 16px; }

@media (max-width: 480px) {
 html { font-size: 16px; }
}

@media (min-width: 480px) and (max-width: 1200px) {
 html { font-size: 18px; }
}

@media (min-width: 1200px) {
 html { font-size: 20px }
}

@line-height: 1.5rem;

.container {
 max-width: 32rem;              // 75 chars per line
 margin: 0 auto;
 padding: @line-height * 2;

@media (max-width: 480px) {   //smaller screen
   padding: @line-height * 0.8
 }
}

h2 {
 font-size: 2.25rem;
 line-height: @line-height * 2;
 margin: 0 0 @line-height * 2 0;
}

In above example, we set different font size for html tag under different break points and all our computations are rem based. So now the line-heights, margins will differ for different screens based on the base font size our root element html will have. Thus, we achieved responsive layouts.

Typography Tips

Consider size: Currently standard min size is 16px, Very thin weights might not display well in small sizes or vice versa.
Consider contrast: Contrast between text and background should be strong.
Consider space: Give your type some space to breathe.
Consider Hierarchy: Use font size, font weight, line heights to establish a hierarchy and use it throughout your application.

Design Tips

Use professional graphical tools to analyse the designs.
Match your work with given designs as much as possible.
Consider bigger picture. Your part must be a fit in bigger picture and shouldn’t look standalone.
Typography is important and we have talked a lot about it throughout.
Consult your designer if you think something is wrong in design before making the change.
Once you are done, take feedback from Designer.

Here I am ending this blog post. Hope this helps and if you like it, please 👏. Thank you so much 😄

Keep dreaming! Keep Learning! Keep Sharing. Have a great day ahead.

References

Typography Series (Part — 1) — Terminology every frontend developer should know

Yashika Garg — Fri, 28 Sep 2018 17:03:54 GMT

Hola folks! This blog series about Typography has two parts

Importance and basic terminology of typography that every frontend developer should know.
Major challenges faced while getting typography right. Check it out here.

In this blog post, we will be discussing basic typography terminology that every frontend developer should know. So, let’s get started.

In simple words, Typography is an art and technique of arranging type. When we talk about the presentation of content on a page, like its font size, font family, weight, vertical spaces, the hierarchy of content and so on, we are referring to its typography.

Importance

If the typography is right, half of your job is done. It’s typography that helps in conveying the feeling, your content is meant for. A right typography connects with the reader, keeps him energised and focused on content, thus the reader ends up reading the content posted.

Above all, a right typography is the main factor of making your applications/websites look beautiful. If you follow typography rules, each page of your website will look intact and will grab users attention.

So in short, three major things:

Conveys a feeling
Keeps user reading
Helps building beautiful applications/websites

Font and Typeface

A typeface is a set of one or more fonts. Each font in a typeface has a specific weight, style, condensation, width, slant, italicisations, ornamentation and designer, foundry and so on.

Let me explain with an example.

Typeface

Here Robot is a typeface and Roboto Condensed, Roboto Slab and Roboto Mono are fonts belonging to this typeface.

If you notice, in Roboto Condensed distance between characters is smaller, it is condensed. For Robot Slab there is a small line attached at the end of the stroke, whereas for Robot Mono each character takes the same space.

Categories of Typeface

There are different categories of typeface and there are all sorts of myths around when to use what. We will now study five basic categories and it will eventually help us understand which typeface to use when and the reason behind it.

Serif: A small line attached at the end of the stroke of each character know as serif. Each serif typeface will have a distinct style for this mark that makes the family identifiable. It gives a very classic, elegant and confident look to the content.
Sans Serif: Sans in French means “without”. So Sans Serif is without serif. It gives a very simple and precise look. As print has higher resolution serif helps distinguish characters and thus enhances readability. For contents in print media, serif font suits best, whereas, sans-serif is best for the web. This is so because screens do not have an as good resolution as print and serif can blur text. For readability of content on the web, sans-serif suits well.
Display: Display typeface has a decorative style and hence used for decorative and illustrative use of content and majorly in print media, like, advertisements, banners, flexes and so on.
Handwriting: As the name suggests it would be more humanistic depicting a human handwriting. It is usually difficult to read and therefore used in either images or headlines, given the text used is short. It is also called Script or Calligraphy typeface.
Monospace: In Monospace typeface, each character takes equal space. It is mainly used in instructions, code blocks or typewriter text.

To read more about these typefaces and to see more examples, visit Google fonts.

What makes up a character

A brief introduction to some important typography terminology:

Glyph: A single character in a typeface.
Baseline: Invisible line on which all characters sit.
x-height: Height of a lower case ‘x’ character.
Cap Height: Distance between baseline and top of the uppercase character.
Ascenders: Part of lowercase character extend above x-height.
Ascender height: Height of ascender.
Descender: Part of lowercase character extends below x-height.
Descender height: Height of descender.

Size Units

Pixel: A dot on your display is called a pixel. So a grid of 10px height and 10px width will have 100 pixels.
Point: A point is a physical unit of length.

1 point = 1/12 pica
1 pica = 1/6 inch

So for 72 pixels per inch display, 1 pixel = 1 point

Em and Rem: These are scalable units and thus helps in creating mobile friendly screens. Em is a base font size of an application.

div { font-size: 15px; }
1em = 15px
2em = 30px
0.5em = 7.5px

It is relative font-size of current element being styled or if the current element does not specify any particular font-size then it inherits it from parent elements.

REM, on the other hand, is relative to font-size of root document.

html { font-size: 15px; }
1rem = 15px;

Characters per line

Having the right amount of characters on each line is key to the readability of your text. What if we violate this range:

Too Wide: At the beginning of every new line the reader is focused, but this focus gradually wears off over the duration of the line. It may also make it difficult to figure out correct line if its large block of text
Too Narrow: The eyes will have to travel back and forth too often, which also breaks readers rhythm

In order to energise your readers and keep them engaged in reading, it is suggested to follow the range of 60–75 characters per line including spaces.
In web design, we can achieve this by having fixed width containers and using scalable units like em/rem for measuring the width of these containers. So, if we base font size is 15px, then we can have the container of width 40–50 em.

Here, I wind up the discussion about different terms we use when we talk about typography. In next blog post, we will talk about the major challenges we as frontend developers face in order to get the typography of our websites right. Stay tuned!

Hope this helps and if you like it, please 👏. Thank you so much 😄

Keep dreaming! Keep Learning! Keep Sharing. Have a great day ahead.

References

Originally published at kyg-tech-stack.blogspot.com.

React unit testing series (Part 1)

Yashika Garg — Sat, 02 Jun 2018 13:13:29 GMT

This blog is going to have two parts:

Basics about unit testing, testing frameworks and DOM interaction libraries
Bursting myths about Jest testing framework. (Yet to come)

As your web application grows with increasing business requirements, in order to maintain sanity of your front-end code, unit testing is a must. The way we have multiple frameworks in our front-end world, we also multiple testing frameworks and technology. Somebody who is starting with front-end development can easily get confused around all the stuff available. This blog is a small attempt to introduce unit testing in a simpler way. So let’s get started.

Testing Techniques

There are basically two ways using which we can cover the critical functionality of our front-end code.

Unit Testing

In unit testing, we basically tests, independent units of behaviour in order to ensure that the unit performs the set of specific tasks it is meant to perform. Unit tests are written from programmer’s aspect. Consider the following analogy: Imagine a building construction site and a building inspector takes a visit. What he will be most concerned about is internal systems of house, like, framing foundation, electrical, plumbing, etc. He focusses on ensuring that each part of house is working correctly and safely.

Integration / Functional Testing

In functional testing, tests are written to test an independent piece of functionality, to make sure the system is doing what users are expecting it to. Functional tests are written from user’s perspective. Let’s see the same building analogy, we talked about above. Imagine the home owner visits the construction site. His perspective will be entirely different from building inspectors’s perspective. He assumes that internal systems, behave correctly and focusses on what will it be like to live in that house, how the rooms are looking, will it meet family needs and so on.

I hope it gives a clear idea about testing techniques. The scope of this blog is unit testing. So moving forward, lets talk in detail about unit as well as features and benefits of unit testing.

Unit Testing

Lets go in depth and try to understand what actually a unit is.

Unit

A unit test is an automated piece of code that invokes the unit of work being tested, and then checks some assumptions about a single end result of that unit. A unit test is almost always written using a unit testing framework. It can be written easily and runs quickly. It’s trustworthy, readable, and maintainable. It’s consistent in its results as long as production code hasn’t changed. — Roy Osherove’s The Art of Unit Testing book.

Irrespective of whether we are writing our application in object oriented programming or in functional programming, a single method in class or module can be considered as a testable unit. A unit is assumed to return a value for a given set of inputs, handles failures or even call another function/method/procedure from with in. Lets consider this example:

// Person class
class Person {
    sayHello (name) {
        console.log("Hello" + name + "!");
    }
}

// sayHello test cases
// - it should print "Hello JS!” if sayHello is called with “JS” => PASSED
// - it should print “Hello World!” if sayHello is called with no parameters => FAILED

In above example, we can easily consider “sayHello” method as a unit and tests its behaviour individually. Considering we are on same page, lets move further in understanding what are the things we need to consider where we are writing unit tests.

Unit Test

In order to test different aspects of a unit, we will be required to write various unit tests where each of them focusses on testing one aspect of unit.

A unit test should be atomic, i.e., it should be independent of other tests.
Running one test shouldn’t affect the assertions in another.
Each unit test can be executed in any order and can be executed repeatedly or concurrently.

This behaviour isn’t hard to achieve if me make sure either our unit tests is not using any shared variable or if they are using it we must be able to reset the value of shared variable before or after the execution of each test.

Also, a complex unit may have multiple dependencies which it is using in order to complete the task it is mean to do. Consider a react component rendering a form with an input value and a submit button. On submitting the form, an API call is made to save the value of input in database.

class Form extends React.Component {
    constructor(props) {
        super(props);
        this.state = {
            input: "",
        };

        this.onChangeHandler = this.onChangeHandler.bind(this);
        this.onSubmitHandler = this.onSubmitHandler.bind(this);
    }
    
    onChangeHandler(event) {
        this.setState({
            input: event.target.value
        });
    }

    onSubmitHandler(event) {
        Axios.post("some_url", {data: this.state.input})
        .then(response => {
            AlertsHelper.show({
                type: "success",
                message: response.message,
            });
        })
        .catch(error => {
            AlertsHelper.show({
                type: "error",
                message: error.message,
            });
        });
    }
    render () {
        return (
            
                                       onChange={this.onChangeHandler} />
                
            

        );
    }
}

Now, this submit handler is a unit and its task is to make an API call to save data, alert success message on success and error message on failure. This handler is making use of few dependencies like “Axios” library to make an API call, “AlertsHelper” library to show alert messages. But when we are going to write unit test for this particular unit, we are not supposed to test the behaviour of “Axios” and “AlertsHelper” as these are dependencies used by unit under consideration. It is not scope of this unit test to test whether the POST request made it through or whether “AlertsHelper” were able to show alert message or not. Thus we can mock these dependencies to perform as required and can test different aspects of the unit under consideration.

We can mock Axios.post to be successful in order to test success case or to be a failure so as to test failure case. We are not concern about what happens in “AlertHelpers.show” but all we care about is that the “onSubmitHandler” should call it with different data based on success and failure case. I hope this gives an idea about how to differentiate dependencies from actual unit and make unit test independent of functionality of those dependencies. Moving ahead, lets talk about unit testing frameworks.

Unit Testing Framework

Testing framework is an execution environment for tests. When we test the behaviour of our application using a source code call unit test, in order to make application behave same way as it would have done in a browser, it is required to provide an environment to the application for the execution of tests. This environment is established using a testing framework, which is responsible for the mechanism to drive application under tests.

A testing framework defines the format for expressing expectations, executes tests and generates reports of test results. When we write a unit test for a unit, we make some assertions or expectations on the output of the unit given different conditions. Different frameworks support different assertion libraries as well as reporting tools. Testing framework should be application independent, easy to expand, maintain and perpetuate.

Let’s explore some of the unit testing frameworks. I am going to talk about majorly two of them — Mocha and Jest.

Mocha

It is the most famous and used testing framework in JS world and has a very active community support. As they says, it is “simple, flexible and fun”. It can run tests for both browser as well node applications. It gives user various options in terms of choosing assertion library, mocking library, spies and so on. This gives the user power to create a package based on one’s needs and customise it on the go. When writing tests for React component, you will also need to setup virtual DOM using JSDOM library. Here is a great article that helps you set up mocha for a React application.

Jest

It’s the recommended way of testing React applications developed by Facebook, painless javascript testing framework. It is based on famous Jasmine testing framework which has its own setup for assertions, spies, stubs and mocks. Jest doesn’t give options to select assertion or mock library of your choice but it comes with everything pre-setup. This has its own pros and cons. If you want flexibility and choice in your setup, definitely Jest is not the one but if you need quick setup to get started with writing your tests, Jest is definitely a good option. Moreover, it sets up fake DOM for you too, thus no need for JSDOM library. You can setup Jest using Getting Started guide from Facebook.

The major change that came with Jest and the one I super liked was it offered auto mocking of all the dependencies of your unit. If you remember we talked few minutes before about unit’s unit test should test unit’s behaviour independent of its dependencies. Now if everything is mocked all ready, we don’t expect dependencies to run their logic when we are testing the unit and thus we achieve correct behaviour testing of the unit.

Lets understand it with an example:

import {add} from "helpers"

const calculator = (a, b, op) => {
  if (op == "+") 
    return add (a, b);
}

/*****************************************************************
When we unit test calculator, we are concerned with whether
calculator calls add helper or not if `op` is `+` and not with
whether calculator returns sum of `a` and `b` if op is `+`

When we test this with Jest, `add` from helpers is automatically
mocked to return undefined and we shouldn't be concerned about it.
And as it is auto mocked, we can easliy spy on it as below
*******************************************************************/

describe("Calculator", () => {
  it("should call 'add' helper, if op is '+'", () => {
    // Given
    let a = 10;
    let b = 2;
    let op = "+";
    
    // When
    const result = calculator(a, b, op);
    
    // Then
    expect(add).toBeCalledWith(a, b);
  })
});

DOM Interaction Libraries

Moving ahead, lets talk a bit about DOM interaction Libraries. As the name suggests, DOM interaction libraries helps to access components with given class name, tag name or type. They make it really easy to test React components by simplifying manipulation, traversal or access of elements from React Component’s output.

Facebook provides ReactTestUtils library for DOM interactions. Another great library is Enzyme by Airbnb, which basically use jQuery API for DOM manipulation and traversal. These libraries are independent of test runners, which means we can use any combination — Jest + Enzyme / Jest + TestUtils / Mocha + Enzyme / Mocha + TestUtils. Both libraries support Shallow rendering and Full DOM rendering.

Following is a simple React Component and its test using Jest and Enzyme:

export const Form = ({name, age, onSubmit, onUpdate}) => {
  return (
    
      
        Name
        
                           className="input-md form-control" 
                 id="name" 
                 name="name"
                 value={name} 
                 onChange={onUpdate.bind(null, "name")}/>
        

      

      
        Age
        
                           className="input-md form-control" 
                 id="age" 
                 name="age"
                 onChange={onUpdate.bind(null, "age")}/>
        

      

      
        
      

    

  );
}

// Form.test.js
describe('PageForm', () => {
  let form;
  const props = {
    name: 'Xyz',
    age: 20,
    onSubmit: jest.fn(),
    onUpdate: jest.fn()
  }

  beforeEach(() => {
    form = shallow();
  });

  it('should exists', () => {
    // Given

    // When

    // Then
    expect(form.length).toEqual(1);
  });

  it('should render name input', () => {
    // Given

    // When
    let nameInput = form.find('input[id="name"]');

    // Then
    expect(nameInput.length).toEqual(1);
  });

  it('should render age input', () => {
    // Given

    // When
    let ageInput = form.find('input[id="age"]');

    // Then
    expect(ageInput.length).toEqual(1);
  });

  it('should render submit button', () => {
    // Given

    // When
    let submitBtn = form.find('button[type="submit"]');

    // Then
    expect(submitBtn.length).toEqual(1);
  });

  it('should call "onUpdate" on change of input', () => {
    // Given

    // When
    let nameInput = form.find('input[id="name"]');
    nameInput.simulate('change');

    // Then
    expect(props.onUpdate).toHaveBeenCalledWith('name');
  });

  it('should call "onSubmit" on form submit', () => {
    // Given

    // When
    let submitBtn = form.find('form');
    submitBtn.simulate('submit');

    // Then
    expect(props.onSubmit).toHaveBeenCalled();
  });
});

Shallow Rendering

Shallow rendering is a concept of rendering component only “one-level” deep which means you do not have access to child component’s behaviour. You make assertions on what render method returns. Child components are not initiated or rendered. Also, it doesn’t need a DOM which makes test quicker to load and run.

Here is a simple Page Component which renders Form and Output components as it’s children.

import React from "react";

import { Form } from './Form';
import { Output } from './Output';

export class Page extends React.Component {
  constructor(props) {
    super(props);

  this.state = {
      name: '',
      age: undefined,
      output: '',
    };
  }

  onSubmit(event) {
    event.preventDefault();
    const {name, age} = this.state;
    const output = `My name is ${name}. I am ${age} years old.`;
    this.setState({output});
  }

  onUpdate(key, event) {
    const state = this.state;
    state[key] = event.target.value;
    this.setState(state);
  }

  render() {
    const {name, age, output} = this.state;

    return (
      
                      age={age}
              onSubmit={this.onSubmit.bind(this)}
              onUpdate={this.onUpdate.bind(this)} />
        
      

    );
  }
}

When we are writing unit tests for above Page component, we are only considered to test whether this component is rendering Form and Output components or not and the concept of shallow rendering allows us to test this real quick. Below is code for Page.test.js where I am using Shallow Rendering API of enzyme.

import { shallow } from 'enzyme';

import { Page } from '../../src/components/Page';
import { Form } from '../../src/components/Form';
import { Output } from '../../src/components/Output';

describe('Page', () => {
  let page;

  beforeEach(() => {
    page = shallow();
  });

  it('should exists', () => {
    // Given

    // When

    // Then
    expect(page.length).toEqual(1);
  });

  it('should render Form component', () => {
    // Given

    // When
    let formCmp = page.find(Form);

    // Then
    expect(formCmp.length).toEqual(1);
  });

  it('should render Output component', () => {
    // Given

    // When
    let outputCmp = page.find(Output);

    // Then
    expect(outputCmp.length).toEqual(1);
  });

This is where I am ending this post and soon I will be writing Part2 of the series where I will be bursting different myths about Jest unit testing framework.

Hope this helps and if you like it please 👏. Thank you so much 😄

Keep dreaming! Keep Learning! Keep Sharing. Have a great day ahead.