An HTTP cookie is a small piece of data that a server sends to the user’s web browser. The browser may store it and send it back with later requests to the same server. Typically, it’s used to tell if two requests came from the same browser, keeping a user logged-in, for example. It remembers stateful information for the stateless HTTP protocol.

Lifetime of a cookie

• Session cookies - They are deleted when the current session ends.
• Permanent cookies - They are deleted at a date specified by the Expires attribute or after a period of time specified by the Max-Age attribute.

Cookie security

A cookie with Secure attribute is sent to the server only with an encrypted request over the HTTPS protocol. A cookie with HttpOnly attribute is inaccessiblt to the JavaScript Document.cookie API, it is sent only to the server.

Cookie scope

The Domain attribute specified which hosts are allowed to receive the cookie. If unspecified, it defaults to the same host that sets the cookie, excluding subdomains. If Domain is specified, then subdomains are always included. The Path attribute indicates a URL path that must exist in the requested URL in order to send the Cookie header. The SameSite attribute lets servers specify when cookies are sent with cross-origin requestes, which provides some protection against cross-site request forgery attacks.

Third-part cookies

A cookie is associated with a domain. If this domain is the same as the domain of the page you are on, the cookie is called a first-party cookie. If the domain is different, it is a third-party cookie.

Cookies and web performance

When a browser sends a HTTP request, the HTTP request headers are usually 400-500 bytes. Adding a cookie to that will increase the size of the request header. If we add more than 1KB of cookies to that request, then we exceed 1500bytes, which is the standard maximum transmission unit (MTU) used by TCP. This means that the HTTP request would span multiple TCP packets, which may result in multiple round trips and increase the risk of retransmission. This can potentially increase the time to first byte (TTFB) of the response since it would take longer to make the request. Because of impact of cookie size on the first flight of requests and responses, it is beneficial to use smaller cookies. 900 bytes seems like a good budget for a total cookie size, which leaves room for other headers such as user-agent.

References:

• A re-introduction to HTTP cookies
• Using HTTP cookies
• An analysis of Cookie Sizes on the Web

A side effect is any application state change that is observable outside the called function other than its return value. For example modifying any external variable like global variable, logging to console, writing to file, writing to network, calling other functions with side effects.

function printSomething(foo) {
    console.log(foo);
}
// printing to console make this function to have a side effect.

Side effects are mostly avoided in functional programming, which makes the program easier to understand and to test.

References:

• Master the JavaScript Interview: What is Functional Programming?
• 3 common approaches to side-effects in Redux apps
• Redux side effects and me
• Preventing Side Effects in JavaScript
• HOW TO DEAL WITH DIRTY SIDE EFFECTS IN YOUR PURE FUNCTIONAL JAVASCRIPT
• Dealing with side effects and pure functions in javascript

Monorepo, is a single repository which contains more than one logical project like a web application and its iOS application.

Benefits:

• Single build system
• Easy to refactor
• Code sharing

Disadvantages

• Tight coupling and unclear ownership boundaries
• Source control system scalabity issues

References:

• Guide to Monorepos for Front-end Code
• Monorepos: Please don’t!
• Monorepos in Git
• Awesome Monorepo

Dependency Injection is a pattern where instead of creating or requiring dependencies directly inside a module, we pass them as paramaeters or reference.

// foo.js
export default class Foo {
    print() {
        console.log('Hello world!');
    }
}

//baz.js
import Foo from './foo.js';

export default class Baz {
    constructor() {
        this.foo = new Foo();
    }
}

//app.js
import Baz from './baz.js';

let b = new Baz();

// Using Dependecy Injection
// Updated baz.js
export default class Baz {
    constructor(foo) {
        this.foo = foo;
    }
}

//app.js
import Foo from './foo.js';
import Baz from './baz.js';

let b = new Baz(new Foo()); // Foo instance is passed as parameter to Baz

Benefits

• Unit testing - Avoid need for stubbing
• Flexibility - Freedom to change implementation at any point

References:

• Dependency Injection in JavaScript
• JavaScript dependency injection in Node.js – friends or foes?
• Dependency Injection & Inversion Explained
• Handling dependencies

Component composition is where a more “specific” component renders a more “generic” one and configures it with props.

function Button(props) {
    return (
        <button>{props.label}</button>
    )
}

function SignupButton() {
    return (
        <Button label="Signup"/>
    )
}

Higher-Order Components

A higher-order component is a function that takes a component and returns a new component. It composes the original component by wrapping it in a container component. Its a pure function with zero side-effects. The wrapped component receives all the props of the container, along with any new props from the container comopnent. HOCs are similar to pattern called “container components”. Container components are part of a strategy of separating responsibility between high-level and low-level concerns. Containers manage things like subscriptions and state and pass props to components that handle things like rendering UI. HOCs add features to a component. They shouldn’t drastically alter its contract. It’s expected that the component returned from a HOC has a similar interface to the wrapped component.

const EnhancedComponent = higherOrderComponent(WrappedComponent);

References:

• Higher-Order Components
• Composition vs Inheritance