Forem: Kriti Rai

The Big O Notation

Kriti Rai — Mon, 05 Aug 2019 20:35:04 +0000

Let's say you have an array and you need to come up with a function that checks if the array has a given number n.

You then write a simple function such as this:

const linearSearch = (array, n) => {
  for(let i = 0; i < array.length; i++) {
    if(array[i] == n) {
      return console.log(`${n} is at index ${i}`)
    }
  }
  return console.log(`${n} not found`);
}

...and you are done or are you?

Well, you might be in the best-case scenario where the given array is small enough and the function executes swiftly.

But life ain't always that easy!

What if the given array is huge? And, say, n is not equal to the first element in the array but somewhere in the middle or not even there? The linear search function we wrote above still works but what about the execution time to go over each element in the array until it comes across the element we are looking for?

Make it work. Make it right. Make it fast!

Following this cliched mantra for programmers, one should really consider the different scenarios -- the best, the worst and the acceptable one, before implementing algorithms.

That's when the Big O comes into play.

Big O notation in Computer Science is used to explain how the runtime or the space used scales with respect to input variable(s) and is essential in understanding the efficiency of an algorithm. In this post, I will mostly focus on the time complexity so let's go over some common runtimes.

O(N) - Linear

O(N) describes the performance of an algorithm that scales linearly with the input size. Say, you have an array of 100 element. It would take 100 iterations through the loop to console.log() all the items. Similarly, with one million elements it would take one million iterations. Hence, the time complexity is directly proportional to the data input size.

O(1) - Constant Time Complexity

With constant time complexity, the time taken to execute is constant regardless of the size of the data input. Let's say you have a file to transfer over from one city to another. Normally, you'd attach the file to an email and send it over or decide to do a FTP transfer. In either case, the bigger the file size, the longer it would take for you to transfer the file over. Hence, the runtime would be linear, i.e. O(N).
However, let's say you come up with an ingenious idea of transferring your gigantic file to a flash drive and sending it over to the recipient via a pigeon (because mailing is boring) that you trained to do so. Now, think about the relationship between the file size and the transfer time. Would it matter if the file was 1GB or 1TB? Our pigeon friend would still take the same amount of time to fly over and deliver the flash drive. So, here our runtime would be O(1), meaning our algorithm will always execute at the same time regardless of the size of the input data. In that case a pigeon would be faster than the internet.

It's not to say that O(1) is always better than O(N) or vice versa. It really depends on the size of the input variable. The figure below demonstrates how at some point O(N) algorithm will surpass the runtime of an O(1) algorithm, thereby making O(1) a better choice for data of the size that is greater than that which corresponds to the interception point. However, prior to the interception point, O(N) is more efficient.

O(N^2) - Quadratic

O(N^2) describes an algorithm whose performance is directly proportional to the square of the size of the input data set. This commonly involves nested iterations over the data set, like:

let arr = [1,2,3,4,5];

for(let i = 0; i < arr.length; i++) {
  for(let j = 0; j < arr.length; j++) {
    console.log(i +"" +j);
  }
}

Some other examples would be bubble sort and comparing elements in two arrays of the same size.

O(2^N)

Another common runtime you might see is O(2^N). Algorithms with this runtime are often recursive algorithms that solve a problem of size N by recursively solving two smaller problems of size N-1. The growth curve of an O(2^N) function is exponential - starting off very shallow, then rising sharply.

A good example of O(2^N) algorithm is the recursive calculation of Fibonacci number.

function calculateFibonacciNumber(N) {
  if (N <= 1) {
     return N;
  } else {
   return calculateFibonacciNumber(N - 2) + calculateFibonacciNumber(N - 1);
}

O(logN) - Logarithmic

With logarithmic notation execution time increases, but at a decreasing rate. Performing Binary Search on a sorted array is a good example of O(logN) runtime. Such algorithm traverses the input data once and then on every subsequent iteration the size of the input data is halved. Below is the growth curve depicting a logarithmic runtime. You can tell why Binary Search is a good choice when it comes to working with a large data.

Note:

There are couple of things to note while calculating Big O notation.

1) Drop the constant and the non-dominant terms

Big O takes the worst case into consideration so we are trying to predict what happens to our algorithm's efficiency when the data input size is ridiculously big. In that sense, if N's value is ridiculously huge, any other constant compares almost non-existent to N. Hence, we drop the constants. So, O(2N) is simply O(N). Likewise, we also drop the non-dominant terms. For instance, O(N^2 + N) becomes O(N^2), O(N+logN) becomes O(N) and so on.

2) Multiply v. Add

If we do A chunks of work then B chunks of work, the total amount of work is O(A+B)

arrayA.forEach(el => console.log(el))

Similarly, if we do B chunks of work for each element in A, the total amount of work is O(AxB)

arrayA.forEach ( a => {
   arrayB.forEach ( b => {
    console.log(a+" " + b);
   })
})

And, finally here's a graph I pulled from this post showing how different runtimes compare.

Conclusion

If you are new to programming, Big O notation might not be your primary focus. However, as you embark on your journey to becoming an awesome programmer you will want to understand the complexities of your algorithms and how they will behave when the input size grows. This is the real world we are talking about and you never know what size of data you might have to work with. Hence, Big O lets us prepare ourselves for the worst-case scenarios, helping us make a sound decision when it comes to devising and implementing algorithms.

# State Hook in React

Kriti Rai — Sun, 28 Jul 2019 00:46:35 +0000

For some time we had been referring to function components as stateless components and would have to write a class every time we needed to make use of a local state. However, with the introduction of hooks in React 16.8, one can now use the inbuilt hook called useState or otherwise called State Hook that lets one add local state to function components.

As per React.js docs,

State Hooks are basically functions that let you ‘hook into’ React state and lifecycle features from function components

Let’s see how we can rewrite a class component using the state hook. Let's say we have a Like component that renders the number of total likes as well as a like button and an unlike button. When a user clicks on the like button the likes go up by 1 and conversely, when a user clicks on the unlike button the likes go down by 1.

Since our component needs to remember the number of likes to be able to update and display it, it will need to make use of state.

Prior to the introduction of hooks we'd normally write a class in order to use state.

import React, { Component } from 'react';
import ReactDOM from 'react-dom';

class Like extends Component {
  constructor(props) {
    super(props);
    this.state = { likes: 0 }
  }

  handleLike = (e) => {
    e.preventDefault();
    this.setState({ likes: this.state.likes + 1})
  }

  handleUnlike = (e) => {
    e.preventDefault();
    this.state.likes > 0 ? this.setState({ likes: this.state.likes - 1}): null;
  }

  render () {
    return (
      <div>
        <h4>Likes: { this.state.likes }</h4>
        <button style={{ backgroundColor: '#99ccff' }} onClick={ this.handleLike }> Like </button>
        <button style={{ backgroundColor: 'red' }} onClick={ this.handleUnlike }> Unlike </button>
      </div>

    )
  }
}

const el = <Like />

ReactDOM.render(el, document.getElementById('root'));

This would give us something like this:

If we zero in on the snippet below, we see that we initialized the likes state to 0 with this line this.state = { likes: 0 } in the constructor.

 constructor() {
    super();
    this.state = { likes: 0 }
  }

Now, with state hooks we can re-write the code above using useState.

import React, { useState } from 'react';
import ReactDOM from 'react-dom';

function Like() {
 const [likes, setLikes] = useState(0);
 ...

What’s happening here?

First, we imported useState from React. Then, we converted our class component to a function component Like(). Finally, inside the function we have this one liner:

const [likes, setLikes] = useState(0);

useState returns a pair of values -- the current state and a function that updates it. So, with the array destructuring method we are declaring and assigning values to a state variable likes and a function setLikes, which is similar to setState() method in a class. You can also see that useState() takes in one argument which is the initial state of the component and that'd be 0 in this case as we haven't got likes from anyone yet :(

Updating State

Since, we have our hands on setLikes function that we declared above, we can now directly call the function to update the state. Let's re-write our handler functions handleLike and handleUnlike.

  const handleLike = (e) => {
    e.preventDefault();
    setLikes(likes + 1)
  }

  const handleUnlike = (e) => {
    e.preventDefault();
    likes > 0 ? setLikes(likes - 1): null;
  }

See, how we can easily call setLikes to update our likes? So, instead of writing this.setState({ likes: this.state.likes + 1}) like we'd do in our class we can just write setLikes(likes + 1).

Let's also update the return value of our function by replacing { this.handleLike } and { this.handleUnlike } with just { handleLike } and { handleUnlike } , respectively. Finally, here's our Like component re-written using the state hook.

import React, { useState } from 'react';
import ReactDOM from 'react-dom';

function Like() {
  const [likes, setLikes] = useState(0);

  const handleUpClick = (e) => {
    e.preventDefault();
    setLikes(likes + 1)
  }

  const handleDownClick = (e) => {
    e.preventDefault();
    likes > 0 ? setLikes(likes - 1): null;
  }

  return (
    <div>
      <h4>Likes: { likes }</h4>
      <button style={{ backgroundColor: '#99ccff' }} onClick={ handleUpClick }> Like </button>
      <button style={{ backgroundColor: 'red' }} onClick={ handleDownClick }> Unlike </button>
    </div>
  )
}

const el = <Like />

ReactDOM.render(el, document.getElementById('root'));

So, here you go! With React hooks, function components can now have some state without you having to write those clunky classes. However, this does not mean that you have to go back and convert all your existing class components. And also, hooks are totally optional and there is no intent of them replacing classes. However, from now on you at least have the options to use hooks in case you need to use state inside your function components. Note that hooks come with React 16.8, so if you want to use them make sure to upgrade React and ReactDOM.

Media Queries For Responsive Apps

Kriti Rai — Mon, 20 May 2019 18:38:31 +0000

For our school projects we are not quite concerned about making our apps look pretty but rather meeting the requirements and hitting the core concepts. Eventually, though, you would and should want to deploy one or all of your apps to showcase your work. That is when you might want to work on the way your app looks as this could be one such case where looks matter. So, I decided to work on deploying my app that I built for the final project at Flatiron School - the first stop being its responsiveness.

With the increasing variety of devices we use nowadays to access contents on the web, it makes sense to architect our app's design to adjust to varying media types, screen/viewport sizes and such, providing a good user-experience that we as developers strive for. I used Chrome's Responsive Web Design Tester Tool to simulate different viewport dimensions of devices such as iPhone 5/SE, iPad and laptops, to get the idea of how my app looks on different screen sizes. However, everytime I switched between viewports other than a laptop's, I cringed at the way my app looked. For instance, on iPhone 5's viewport, my search form that otherwise so nicely stretched across the page now broke into two rows with the input boxes unattractively stacked on top of each other. The letters in the navbar were gigantic in proportion to the viewport size, and my app just did not look neat and finished anymore. So, I decided to turn to media queries.

Media queries are powerful tools lent by CSS3 to alter the way the content of the app adjusts to the device type, viewport/screen size and orientation.

These tools allow us to tell our program to apply certain CSS rules if the specific conditions are met.

The basic syntax for media queries consist of the keyword @media followed by media type and expression(s).

@media < media-type > and (expression) {
     /* CSS rule for styling ...*/ 
}

Media Types

The available media types are:

all - includes all devices
print - used for displaying content in print-preview mode
screen - includes mobile, tablet, and desktop devices
speech - intended for speech synthesizers We are usually concerned with screen. So, to target screen media types we could write something like:

@media screen and (expression) {
/* CSS rule */
}

Logical Operators

Logical operators can be used to separate or combine more than one condition.

and - Using and requires media feature expressions on both sides of the keyword to return true in order for the media query to return true. It is also used to join media type with media features.
or - Also, written as a comma (,) only requires one of the comma-separated conditions to return true for the entire media statement to return true, thereby triggering the media query to apply.
only - Requires the entire condition to match in order for CSS to apply. It comes in handy during situations where you want to hide media queries from older browsers and like not, must come at the beginning of the declaration followed by media type.
not - Negates a media query, returning true if the query would otherwise return false.

Expression

We use this part of the code to target media features, such as width, height, resolution, etc.
For example, the query below will target the width media feature and for any device with viewport width of 425px, the content inside p tag will be red.

@media and screen and (width: 425px) {
    p {
     color: red;
    }
}

We can also use min-width and max-width variants to query minimum and maximum values, respectively. For example, the query below will apply to any device with viewport width between 0 and1024px.

@media screen and (max-width: 1024px) {
    p {
     color: blue;
    }
}

And, voila!! there you have a responsive app. Of course, you can build complex media queries depending on the complexity of your app but hopefully this basic knowledge of media queries will get you started on your journey to master building responsive web apps.

Finally, here's a snippet of what my app looks like now in varying viewport sizes:

What is State in React?

Kriti Rai — Fri, 03 May 2019 15:34:45 +0000

In English, state refers to "the particular condition that someone or something is in at a specific time" and that holds true in React as well. State is basically a JavaScript object that stores a component's data that are prone to changes, enabling a component to keep track of the changing information in between renders. That's what makes components reactive in nature.

The Why

If you have a static app, don't use state. However, if you want your app to be interactive, like for example a clock widget that shows and updates time at a set interval or an app where one can log in and out, add, delete and update resources - it will involve state.

But, wait a minute don't we use props to store data in components? Yes, but the crucial difference here is that props are immutable (read-only) in that the components can not change their props as they are passed down from parent components. In contrast, component has a full control over its state and can modify it.

The How

Let's look at an example (inspired by the ticking clock example in React docs) to see how state works.

We will build a simple Countdown component that renders the final countdown to the New Year's day.

Keep in mind,

state is a feature only available in classes

So, let's start by building an ES6 class for our component and write some pseudo code inside to show what it should do.

import React from 'react'
import ReactDOM from 'react-dom';

export default class Countdown extends React.Component {

 timer () {
 // some function that updates the  countdown
 }

 render () {
  return ( 
  // shows the countdown 10 through 1 and renders the message HAPPY NEW YEAR!!
  )
 }
}

const element = <Countdown />

ReactDOM.render(element, document.getElementById('root'));

Now, in order to manipulate the state, you ought to have something to begin with, right? Yup, an initial state. So, let's do that - let's declare the initial state of the component and give it an attribute of secondsLeft. We'll start with 10 secondsLeft and do a countdown until it's 0 secondsLeft. Now, where shall we declare the initial state? Constructor function it is! Because that's what fires before our component is mounted, making it the perfect candidate for setting up defaults including the initial state. Let's add the following block inside our component class.

constructor() {
  super();
  this.state = { secondsLeft: 10}
}

Make sure to pass in props as an argument to constructor() and super() if you wish to use this.props within the class.

Now, let's work on our timer() function that updates our component's state of secondsLeft by subtracting 1 from it.

timer = () => {
 if (this.state.secondsLeft > 0) {
  this.setState({ secondsLeft: this.state.secondsLeft - 1 })
 }
}

We use this.setState() to update a component's state rather than doing something like this.state = someValue

Calling this.setState() tells React that the component's state has updated and that the component needs to be re-rendered.

Also, notice that I used an arrow function to define timer. This is to bind the keyword this to the instance of the component we are working with.

Moving on, let's add a lifecycle method componentDidMount() which will run after the component output has been rendered in the DOM. This is also a good place to call timer(). So, starting with the initial state, with every second the state of the component updates as timer() fires, thus re-rendering the component every second.

componentDidMount() {
 setInterval(
  () => this.timer(),
   1000
   );
 }

Here's the final code:

import React from 'react';
import ReactDOM from 'react-dom';

export default class Countdown extends React.Component {
  constructor() {
    super();
    this.state = { secondsLeft: 10 }
  }

  componentDidMount() {
    setInterval(
      () => this.timer(),
      1000
    );
  }

 timer = () => {
  if (this.state.secondsLeft > 0) {
     this.setState({ secondsLeft: this.state.secondsLeft - 1 })
  }
 }

  render() {
    const message =  (this.state.secondsLeft === 0 )? <font color="red">Happy New Year!!!</font> : this.state.secondsLeft 
    return <h1>{ message }</h1>
  }
}

const el = <Countdown  />

ReactDOM.render(el, document.getElementById('root'));

...aaaaand Action!!

TL;DR

If you want interactive components use state
State is a feature only available within class components
React maintains state as an object which can be accessed through this.state
State is similar to props, but is private and fully controlled by the component and can not be accessed and modified outside the component (think encapsulation)
Don't set the state directly like this.state = someValue but use this.setState() instead

Resources:

My React/Redux portfolio project

Kriti Rai — Mon, 15 Apr 2019 18:26:10 +0000

For my final project for Flatiron's online fullstack programming course, I built an app called Trailista, which pulls a list of trails from Hiking Project Data API by location. You can watch a short demo of my app here or proceed to read as I briefly touch up on the setup and few roadblocks I came across during the process.

This app is definitely a WIP but so far here are the available featues:

One can search for trails by city and country

One can login or sign up

One can add trails to their favorites list and then delete them as they wish

The way it works

My app pulls trails from Hiking Project API endpoint that looks something like this

www.hikingproject.com/data/get-trails?lat=40.0274&lon=-105.2519&maxDistance=10&key=APP_KEY

The client supplies the values for lat, lon and maxDistance alongside a key that is provided by Hiking Project
The app then takes the user inputs and plugs them into a fetch request, and sends it to Hiking Project API for a response back

Sounds pretty straightforward except that the user supplies the app with an address, e.g. a place's name, whereas Hiking Project API endpoint wants the address in the form of GPS coordinates, i.e. the lattitude and the longitude. So I had to find a way to convert the location input to GPS coordinates. After rummaging through Hiking Project' FAQs forum for some time, I found a thread where someone had mentioned using MapBox to carry out, what they apparently call, "forward geo-coding", i.e. the process of converting an address to coordinates (the opposite would be reverse geo-coding). I also looked into Google maps API but apparently they charge? So, I decided to stick with MapBox.

And, boy was this fun? Yes, it involved some hair-pulling episodes but I'm fairly proud of this part the way I got it working. My two functions, the heroes of my app, getCoordinates() and fetchHikes(), work in coordination to make this happen.

getCoordinates() takes the user input and sends a fetch request to MapBox API, like so:

getCoordinates= (e) => { 
    e.preventDefault();
    axios.get(`https://api.mapbox.com/geocoding/v5/mapbox.places/${this.state.city}.json?country=${this.state.countryCode}&access_token=APP_KEY`)
      .then(resp => {
        this.setState({
          longitude: resp.data.features[0].geometry.coordinates[0],
          latitude: resp.data.features[0].geometry.coordinates[1]
        })
                ...

The response data is then used to set the values of longitude and latitude in the state, which is then used to make a fetch request to Hiking Project's API via the dispatch action fetchHikes()

getCoordinates= (e) => {
...
   this.props.fetchHikes(this.state.latitude, this.state.longitude, this.state.maxDistance, this.state.maxResults)
  })
}

The Set Up

This article does a great job of guiding one through setting up a React app with Rails API. I had a rough idea of what resources I will be working with so I started with my models and controllers first and then set up (API) routes (in '/config/routes.rb') to which I could send fetch and/or post request.

Important!

One thing to look out for is your CORS (Cross Origin Resource Sharing) set up. Since my front-end and back-end were running on different domains, I had to find a way to tell my back-end server that the requests my front-end was sending were not harmful. If you initially set up your Rails API with the command $ rails new myapp --api, you get a cors.rb file already set up and you will just have to uncomment the following:

#Gemfile

gem 'rack-cors'

#app/config/initializers/cors.rb

Rails.application.config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins 'localhost:3000'

    resource '*',
      headers: :any,
      methods: [:get, :post, :put, :patch, :delete, :options, :head]
  end
end

Once all this was taken care of, I then moved onto my client side, i.e. the front-end part. Also, before pulling data from Hiking Project, I created some seed data to test how the data is rendered on my front-end.

Routes

I set up my routes in App.js. One interesting thing I found on the internet was that I could create a helper PrivateRoute to lock down a route if one is not logged in, like e.g. my '/user' route. This article talks about how one can set up a PrivateRoute.

Components

I started with presentational components that were mostly stateless and had DOM markups. As I progressed further I ended up adding props, state, connecting to the store and so on, which all led me to think about dividing up my components based on their functionality - containers and presentational. Containers are concerned with how things work, contain logic and the most of the times are stateful. The latter, on the other hand, are just "dumb" components that are concerned with how things look and has no logic or knowledge of state whatsoever.

However, as Dan Abramov points out in this article, this pattern should not be enforced as a hard rule and if there is no necessity. So, you may see that some of my components act as both container and presentational or some of my presentational components have logic inside them and are not purely presentational.

Reducers

Speaking of separation of concerns, instead of having one giant reducer, I decided to have one reducer managing only one independent slice of the state. So, I ended up with three reducers, alertsReducer, hikesReducer and userReducer. All of these reducing functions are then combined into a single reducer, rootReducer, using combineReducers helper function provided by redux. This reducer is what gets passed to createStore.

Conclusion

I had a lot of fun building this application. And, like with all other projects, this one came with frustration but I've learned that that's what makes the accomplishment at the end so much worthwhile. However, this is not over yet and I still want to keep working on the app, adding some more features like comments, users being able to rate and create hikes and so on. For all I know, sky is the limit and there is always room for improvement. As of now, I'm happy that I'm ready for my final assessment. The journey has just begun!

Combining Reducers

Kriti Rai — Thu, 14 Mar 2019 00:02:14 +0000

I was recently working on a lab in building a Yelp-like application that uses React and Redux to add and delete restaurants and their reviews.

While working my way through the lab I found that my reducer function, manageRestaurants, was dense. So, I naturally sought to split my giant reducer function into two children reducer functions so that each function was responsible for only one resource's state. Using combineReducers, I then combined the children reducers in one parent reducer function, rootReducer, which is what gets passed to the store. This not only made my code cleaner but also much easier to debug.

Finally, I got the app working in the browser just as the lab wanted and before I could take that big sigh of relief I found that the tests were failing. The lab just wanted us to create one reducer function and put all reducer logic in there. Ugh!

Regardless, I decided to create a separate branch and push up my clean and amazing code there and reverted my master branch to the old way to pass the tests. In so doing, however, I realized that now I had a greater understanding of how combineReducers works. Additionally, now that I had seen both scenarios I could use that knowledge and experience to decide when I could use combineReducers. If you are just working with one or two resources, maybe you don't quite need to use this helper function. However, imagine a big app with multiple resources and soon enough you will find yourself tangled up in a number of switch statements and a big, fat state with multiple key-value pairs.

Refactoring with combineReducers

All talks aside, lets look at my giant reducer manageRestaurants first, which is maintaining the state of both restaurants and reviews.

Now, let's split our giant reducer into two child reducer functions, say restaurantReducer and reviewReducer. The former manages the state of the restaurants whereas the latter manages the state of the reviews.

restaurantReducer

reviewReducer

Now, here's our rootReducer, where we will call our children reducer functions. Notice, we imported combineReducers from redux.

rootReducer

This is equivalent to writing:

function rootReducer(state = {}, action) {
  return {
    restaurants: restaurantReducer(state.restaurants, action),
    reviews: reviewReducer(state.reviews, action),
  };
};

This basically produces the same giant reducer function as manageRestaurants does but in a much more abstract and cleaner way.

Conclusion

If your app is big and has more than one or two resources, you might be better off splitting up the state object into slices and using a separate child reducer to operate on each slice of the state. The slices of state can then be combined using combineReducers, a helper utility lent by Redux, in a parent reducer, conventionally named rootReducer. Keep in mind that using combineReducer might not be helpful if one is intending to learn what is going under the hood as it abstracts the way reducers are being combined and working together. So, try to play around with both scenarios to get a better understanding of how reducers work and when to use combineReducers.