DEV Community: Mihail Gaberov

How to visualize Pancakes Algorithm with React and Popmotion.io

Mihail Gaberov — Tue, 03 Sep 2019 13:03:09 +0000

What you are going to see below was suppose to be part of my solution to an exercise given in a coding challenge. It was several months ago and I had signed in for it. Due to unforeseen factors, I haven't gone to the end. Now, after that time and the challenge finished, I can share it here.

This is not going to be a step-by-step tutorial. Rather a quick review of how can we use frameworks like React and Popmotion.io, and an algorithm. And create a nice visualization of that very same algorithm. Somehow it feels nice! 🤓

The so called Pancakes Sorting Algorithm is famous (or not?) sorting algorithm, that you can read about a lot in internet, if interested. Its nature is out of the scope of this article. Here we only see it in action with nice animations, thanks to Popmotion.io.

Here is the live demo you can play with. There are two text inputs and two buttons. In the first input, you enter the time interval
which will be used for each animation round, i.e. how fast each pancake will be sorted. It's in milliseconds, which means if you enter the value 1000, the animation will execute for roughly 1 second. The second input is used to define how many pancakes you want to see sorting. The value there must be between 2 and 50. The buttons are self-explanatory enough. One is for starting the sorting animation, the other one is for resetting it.

And here is where you can find the source code for the demo app. Feel free to check it out and take a closer look. You might try to amend the animations I did. I would be more than interested to see your versions. :)

That was all. Nice and short, perfect for the summer! ☀️ 🏖

🔥 Thanks for reading! 🔥

How to optimize your JavaScript app by using service workers

Mihail Gaberov — Tue, 03 Sep 2019 08:25:13 +0000

A nice image used for demonstration of SW work.

Every now and then we hear about optimizing something. There are different kinds of optimizations we could do to make our apps faster and more efficient. To save time or memory. This article will cover one of those methods — service workers.

TL;DR

This tutorial explains what a service worker is and how to use it. In JavaScript. There is a code example at the end of it. If you want to skip the reading, here is the Git repo and here you may see a live demo.

The Theory

Let’s see first what a worker is this 👀 and what service can we use it for 🤓.

The service worker is a simple script. JavaScript code, that your browser runs in the background, separate from a web page. It’s very convenient to use service workers for features that don’t need a web page or user interaction. One of the most common usages is intercepting and handling network requests. Which includes managing a cache of responses. The following is a simple example of how to include a service worker in your application run.

Usually, in the entry point of your app, you put this:

if ('serviceWorker' in navigator) {  
  window.addEventListener('load', function() {
    navigator.serviceWorker.register('/service-worker.js');  
  });
}

This way of using service workers is a little bit improved than the basic one. Which would be directly calling the register() method inside the if statement. In this case, we use the window load event to register the service worker after the page has finished loading. After doing this, you need to add your service worker code in service-worker.js file. At this point, you might want to take a look at mine service worker file here.

All major browsers support Service Workers now and you can start using them right away.

The Example

Enough theory, let’s build a real example app, that will leverage the service workers feature.

Let’s imagine we are building an app that needs to load a big chunk of data. It could be, for example, a nice, big full-screen image, we would display on the front page. Or it could be a big video clip we have to wait to load. This is an ideal use case for a service worker to shine. Let’s see how. 👀

In our specific case, we will use the clock time to show the benefit of using service workers. What I mean is, that we will build a simple app, showing the time. It will have a nice, big button for fetching a nice, big image. And it will provide the user with an option to choose to use or not a service worker.

Here is a screenshot of how it looks like.

What this app demonstrates is, that when fetching the image (by clicking the button, wow!) with an active service worker — we don’t get blocked UI (user interface, i.e. fields, buttons, 🐛). If you choose not to use the service worker, you will get a frozen UI for a certain period of time. When the work completes and the main thread frees itself, it will unfreeze the UI.

If you don’t want to clone and run the code yourself, jump straight to the live demo.

Conclusion

This demo of service workers in action shows us the advantage we get from using them. Especially when you are trying to build responsive and robust JavaScript applications. No user wants to end up in a frozen page for an unknown time, as no developer should want that for his application’s users. Keeping in mind the above, service workers are a must now. And we should not neglect them.

🔥 Thanks for reading! 🔥

How to build a chat app with React, TypeScript and Socket.io

Mihail Gaberov — Tue, 30 Apr 2019 15:26:30 +0000

Photo by Hutomo Abrianto on Unsplash

Originally published at mihail-gaberov.eu.

This is going to be a thorough step-by-step guide for building a single page chat application using React, TypeScript and Socket.io.

If you want to skip the reading, here 💁 is the GitHub repository with a detailed README 🙌, and here you can check the live demo. 🎀 In order to play with it, you need to open it in two different browsers (or browser tabs) or devices (you may use your computer and your smartphone) and chat with each other.🎀

Research

When you are about to start a new project, it’s a good practice to do initial research about the technical stack you are planning to use.

In other words, you may want or need — especially if you don’t have prior experience with it — to investigate on each technology you will be using. I recommend doing that separately. Take one of the them and create a small app that you can play with.

If you need to check how the integration of two or more technologies is going to work in a real project — then you might want to include them all together in your “research-test-play” app — but preferably do your research one at a time.

Getting to the point

When I started thinking about making this chat application, I did exactly what I described above. I haven’t had recent experience with TypeScript and none with Socket.io, so I had to take a look at those and get myself familiarized with what is their current state. As my plan was to use React as a main UI library, I needed to see how it was going to work with the other guys in the equation. So I did.

I created two small applications (repos here and here) with these technologies, just to be able to play with them and learn how could I use them in my future chat application.

After my initial research was done I was able to start thinking and planning the implementation of my main chat app.

High level planning

Usually what people mean when they say “high level plan” is that they are looking for the big picture. Which means we need to create a rough plan of our execution and define our main pillars, but without going into too much detail. Now when we have clear idea of what to do, let’s start doing it! 👷

Note: From this point forward I will be assuming that you are following my steps as I describe them, hence I will be writing in the second person. 👨

Tech stack

We already mentioned the main technologies we will be using, but let’s define a proper list of all of them here:

React with TypeScript (create-react-app my-app --scripts-version=react-scripts-ts) — a UI library we will use for building our application’s user interfaces.
Redux — a state management library we will use for managing our application’s state.
Express.js — Node.js web application framework we will use for creating an http server that we will need in our application, in order to take advantage of Socket.io engine.
Socket.io — a JavaScript library for real time web applications. It enables real time, bi-directional communication between web clients and servers. We will use it to implement a simple chat behavior in our app.
styled-components — a small library that we will be using for adding styles to our app and make the look and feel beautiful. It utilizes tagged template literals to style your components and removes the mapping between components and styles. This means that when you’re defining your styles, you’re actually creating a normal React component that has your styles attached to it.
Jest/Enzyme — a JavaScript Testing Framework and a JavaScript Testing Utility that we will be using to write unit tests for our application. Both have great integration into the React ecosystem and are heavily used in real projects.

Application Features

In this section we will describe what the features of our application are going to be.

Every time when we plan a new project, we must define certain criteria which will describe some level of completion when met.

In other words, we need to set a limit point which, once reached, will show that our project is completed or at least in its first version. There is a famous saying, that could be matched to the issue with the “never ending” projects:

“A good plan today is better than a perfect plan tomorrow.” — or we may say that a working project today is better than a perfect project tomorrow.

Here is my list with the features I wanted to implement initially:

Header

Chat tab — blinking when new message is received until it is read, or when the user is on Settings page
Settings tab
Unread messages counter
Font Awesome icons

Chat page

Chat area (includes left aligned and right aligned messages)
Message (text, datetime, left or right depending on if it’s received or sent)
Showing the nickname only of the sender
Message sender — input field and button. Input is cleared and focused when button is clicked
Send messages with CTRL+ENTER
Auto scroll to bottom when the chat area is not enough to show all messages

Settings page

UserProfile component — possibility to change user name
Interface color component — change the color theme of the app
ClockDisplay component — change the time mode 12h or 24h, shown with each message
Send messages with Ctrl+Enter — On/Off -LanguageSwitcher — drop down menu allowing changing the language of the app (currently English and Deutsch are supported)
Reset button — resets all settings stored to local storage

Improvements

At the time of writing this, there are still some pending features I would like to implement. Below is the list of all improvements I did or plan to do in future (the ones with the thumb emoji are already implemented):

Add video chat feature.
👍 Added AM/PM time formatting for when 12h mode is selected.
👍 Added possibility to send message via ENTER by default. If the setting to send messages with CTRL+ENTER is ON, then this is going to be the only way (except via mouse/touch of course).
👍 Optimized for iDevices (media queries).
👍 Fix blinking/active class for the Chat tab issue — related to React Router not able to properly re-render connected components https://github.com/ReactTraining/react-router/blob/master/packages/react-router/docs/guides/blocked-updates.md
👍 Clear input field when new message is sent.
👍 Auto scroll to bottom main chat area when new messages exceed available space.
👍 Prevent ‘doubling messages’ (or multiple messages duplicates when more clients are connected).
👍 Add unit tests for the react components. Add unit tests for redux stuff — reducers, store, action creators.
👍 Add media queries for responsiveness — test and adjust on more devices.
👍 Add demo to Heroku.
👍 Add nice how-to in README.
Add animations for the messages.
Add sounds (with options to turn on/off in settings).
Add more color themes.
Add welcome message (broadcasts when a new user is connected).
👍 Add icons (use Font Awesome).
History of all the conversations.
Handle case when socket’s connection state change (visually).
Handle case when there has been a socket error.
Handle case when a very long word (without) spaces is entered and it goes beyond the message background color.
👍 Emoticons support — such as :D, :P, :), ;), 😉, ❤️, etc.
👍 Link Parser — Youtube link (embedded video should appear), link to an image (embedded image should appear), all other links should appear as anchor.

When we know the initial plan and the requirements we need to fulfill, we can do our high level analyses. Our app will have two pages, Chat and Settings, accessible via tab controls.

The Chat page will contain the main chat area with the controls needed to send messages (input field and a button).

The Settings page will contain a few controls for selecting the options described above.

With that in mind we can go to the next section where we will create a more detailed plan before the actual implementation.

More detailed planning

In this section we need to have a deeper look at our application and define what will be the building blocks for it. Since we are going to use React and we know that in the React world the term component is widely used, we may refer to our building blocks as components. We will have components responsible for purely visual stuff, as well as such for managing the local storage, for example.

Let’s try to imagine mentally how our app will look in the end and what components it will need. What we already know is this:

Server part

We will need an HTTP server that will take care of starting the server and handling interactions with Socket.io (sending and receiving messages). Our server logic will be simple enough to live in only one file. You can see the actual implementation here.

Client part

Here we need to have all the visual controls, plus means for managing interactions with local storage, where we will save the user preferences, as well as handling of the translations and color themes.

Now is a good moment to point out that for implementing the translations and theming functionality in the app, I have used React Context API. Also, since I knew I would have to deal with Local Storage, I did another round of the “research-test-play” trip. And the output of it was that I already had a nice service, which provides all the functionalities I needed.

Another thing you will notice when looking at the components folder is that every component has its own directory with a few files in it.

These files serve the following logic:

index.ts → entry point, just expose the component itself. This helps for not having to write repeatedly and long import statements. Here is an example:

// Instead of having to write this:
import ChatArea from '../../ChatArea/ChatArea';
// We can have just this:
import ChatArea from '../../ChatArea';

ComponentName.tsx (ChatArea.tsx) → actual component implementation live here.

ComponentName.test.tsx (ChatArea.test.tsx) → unit tests of the component live here.

StyledComponentName.tsx (StyledChatArea.tsx) → CSS styles of the component live here.

The same pattern is used for most of the components, exception are only the pages, such as the components which play the role of parents for all the inner parts — ChatPage and SettingsPage.

So, with that said, I think we can see what would be our application structure when we try to “componentize” it. Here a list of the components I came up with:

Note: all names are a matter of personal choice, feel free to name yours as you wish.

Let me try to give you a bit more detailed explanation for each of them below:

AppRouter — contains the main app routing logic. For instance, here we define the app routes by giving them the path and component to load when this path is reached. Uses React Router package.
ChatArea — represents the main chat area, where all the messages are being displayed. It’s responsible also for auto scrolling down when the visible area limit is reached.

ClockModeSelector — responsible for displaying controls allowing the user to select the time display mode -12h or 24h. It uses a common component called RadioGroup (will describe it below) and the Local Storage service to write/read from the browser’s local storage.

common/RadioGroup — this is a common component, built with the idea to be re-usable all over the app. We use this component in a few other components, such as ClockModeSelector, ThemeSelector and SendingOptions. It contains logic for displaying two radio buttons with the possibility to pass a callback function which will execute a certain action depending on your needs.
LanguageSelector — responsible for displaying a select input control for choosing the app language. It accepts a function that is coming from the TranslationsProvider utility and does the actual language change.

Message — this component is responsible for displaying each chat message, sent or received. It includes the nickname of the sender and timestamp showing the time when the message was sent/received. It also provides support for emojis (like ❤️) and links parsing — see the screenshot below.

MessageSender — this is the component that provides the necessary user interface controls for sending messages — a text input field and a Send button. It contains logic for defining the different ways of sending — via click or key press (with ENTER or CTRL+ENTER), as well as clearing the input field when a new message is sent.

Navigation — here lives the implementation of the app navigation. It consists of two tabs — Chat and Settings and contains logic for connecting to sockets, by sending a Redux action when the component is mounted. It manages an UnreadMessagesCounter component by passing it the count of the currently unread messages (this happens when the user receives a message while being on the Settings page). It also has a logic responsible for making the tab blink when a new message arrives.

Nickname — this is simple component for rendering the nickname of a chat user.

ResetButton — this will be a simple component, used in the Settings page for rendering a Reset button. The function is going to be exactly that — resetting the settings selections that are already saved into the local storage, if any.

SendingOptions — responsible for displaying options for choosing if a message can be sent via CTRL+ENTER. It works same way as ClockModeSelector component — uses RadioGroup component and accepts a callback function.

ThemeSelector — same as the component above. The only difference is that here the user is allowed to select a color theme. In our case the options are only two — light theme or dark theme.

ThemeSelector component
Timestamp — simple component used for rendering the time of the messages.

UnreadMessagesCounter — this is the component I mentioned a little bit earlier. It shows a counter indicating the number of the received, but not yet read, messages. It’s positioned in the navigation area.

UserProfile — this the component responsible for rendering an input field the user can use for changing its user name. It’s saving the new user name into the local storage, using a debounce function. This means that the actual triggering of the function is happening some defined time after the user stops typing. It also triggers another Redux action, so we can use the new username in our Redux state.
pages/ChatPage— parent component that encloses everything shown on the Chat page.
pages/SettingsPage — parent component that encloses everything shown on the Settings page.
Everything described above was related to our React components. All of them are responsible for getting some data and displaying it in a proper way. In order to be able to handle this data in a convenient for us way, we use a few more things. Let’s have a look at these things in the sections below.

Redux State Management

Here we will talk about how our app state is being managed by using Redux and socket middleware.

Store

Our store is going to be relatively simple. We will have only two reducers defining a piece of the state reserved for the socket state and for the messages state. This is also where we apply our middleware. If you are familiar with Redux Saga package, you have probably seen this pattern of applying custom middleware when using Redux.

Something like this:

import { createStore, applyMiddleware } from 'redux'
import createSagaMiddleware from 'redux-saga'
import reducer from './reducers'
import mySaga from './sagas'
// create the saga middleware
const sagaMiddleware = createSagaMiddleware()
// mount it on the Store
const store = createStore(
  reducer,
  applyMiddleware(sagaMiddleware)
)

But in our case it would be like this:

import { createStore, combineReducers, applyMiddleware, compose } from 'redux';
import socketReducer from './socket/reducer';
import messageReducer from './message/reducer';
import socketMiddleware from './socket/middleware';
const rootReducer = combineReducers({
  socketState: socketReducer,
  messageState: messageReducer
});
// @ts-ignore
const composeEnhancers = window.__REDUX_DEVTOOLS_EXTENSION_COMPOSE__ || compose;
const index = {
  ...createStore(rootReducer, composeEnhancers(applyMiddleware(socketMiddleware)))
};
export default index;

Message

After defining our store, it’s time to see how are we going to handle the messaging in Redux. We have defined our actions here and our messageReducer here.

Actions — here we define the main actions needed for sending and receiving messages, as well as changing the user name.
Reducer — here is where our messageReducer function lives and where we define what happens when one of the actions above is dispatched.

Socket

We follow the same logic as above here. We have our socket actions, the middleware I mentioned above, and the socketReducer.

Actions — contains actions for connecting the socket (the one dispatched from the Navigation component in the beginning when the application is started) and one for when the connection status is changed, i.e. showing if we are connected or not.
Middleware — contains implementation of a simple socket middleware, which provides us with the minimum functionality we need in our chat app.
Reducer — here is where our socketReducer function lives and where we define what happens when one of the actions above is dispatched.

Theming

In order to implement the possibility for setting different color themes in our application and considering the fact we are using styled-components, I used a ThemeProvider — component provided by them. Here is the implementation that includes defining objects with custom colors used in the themes.

The logic behind applying the selected color theme resides here. Ideally the containing component should be named something different than TranslationsProvider, as it doesn’t handle only the translations, as we see. We could add this to the list of future improvements/refactoring.

Here is how the existing color themes look:

Utilities

In almost every software project, at certain point, the need of common reusable functions emerges. This is the moment when developers usually create a common shared file or files, containing such helpers functions. In our case this would be /utilities folder that currently contains four files. I will go through each of them below and explain the logic behind my decision to create it and put it there:

common.ts — here is the place where I decide to put such common helper functions, which are supposed to be easily used where needed in the whole application. In this specific case you will find four functions used for time formatting, and a helper for defining the active page and for scrolling an element to bottom.
localStorageService.ts — I have already mention this service in the first part of this tutorial. Here is where all methods for manipulating the local storage live.
TranslationsProvider.tsx — this component was also mentioned multiple times, but for the sake of clarity I will mention it again here. It contains the logic for providing translations and color theme in the app.
withTranslations.tsx — this is a higher-order component (HOC) which is responsible for attaching the application context (containing the translations and themes themselves) to any component being wrapped by it.
Here is an example of how is it used:

export default withTranslations(SettingsPage as React.FunctionComponent);

We have walked a long way to here and we still haven’t started with the actual implementation.

That is a vivid pointer for us to show how important and extensive the planning phase of a project could be.

Let’s jump now to the implementation phase in the next section.

Implementation

If you reached this point of the tutorial, you should have a very clear idea of what are we going to build. Here, we are about to find out how are we going to do it.

Starting small

As with any other project we should strive to start with small, incremental chunks and build on them. In our case I have decided to start first with building the header navigation. The reason for that was that I wanted to have the router and the navigation controls in place, so I could easily navigate through the tabs while developing and testing.

Settings page

After I had finished with the header and navigation parts, I decided to jump to the settings page first. Again, my reasoning was very simple — I wanted to build first what I was going to use in the Chat page. In other words I wanted to be able to customize my chat area, messages, ways of sending and so on, before implementing them.

So I started building component by component as I described them in the previous section. Once I had the full Settings page finished, I was able to go and start implementing the Chat page components. But before that, I had to take care of the supporting stuff — integrating with local storage and adding translations mechanism.

Chat page

After I have done all from above, the implementation of the Chat page and its components was fairly easy. I had to take care of the visual part manly and make the integration with the Redux store. As you already saw, I had to implement only two components which are shown and used on the Chat page — ChatArea and MessageSender.

Adding improvements

I want to say a few words here regarding the app improvements we did or will do in the future. Usually when we have a new requirement (let’s call it “requirement”, that makes is sound closer to what would be in a real project), it is again a very good idea to do some initial research, instead of jumping directly into implementation. You will be surprised how many solutions are already out there, waiting for us to use them.

In other words, we don’t have to invent the wheel again.

This is what I did when I started thinking about adding support for emoticons or link parsing. It turned out that there are already solutions I could use with a little tweaking from my side, just to make them fit well in my project.

Here are the links to the packages I used:

https://www.npmjs.com/package/linkifyjs
https://docs.microlink.io/sdk/getting-started/react/
https://www.npmjs.com/package/react-emojione
https://www.npmjs.com/package/get-urls

And here you can see how I used them in our chat app.

Deploying to Heroku

I have written another article in the past. It was about totally different subject, but there is a part exactly related to how to deploy an app to Heroku. You might find it useful to check it out.

For deploying our chat application to Heroku, I will assume you have already an account and can easily follow the steps below:

npm build to build the project to build folder.
Add build folder to Git to make sure it will be committed.
Make sure that express server loads static resources from it.
Commit all: git commit -m 'Deploy to Heroky'.
Run git push heroku master.
Open the app from the given URL (in my case: mihails-chat.herokuapp.com).

Future (possible) plans

At the time of writing this I was thinking it might be very interesting to try building the same application with the other super famous UI library on the market — Angular. I still think it will be worth it, but I am not sure whether I will have the time and the power to do it 😐.

In any case, what I am thinking about it as a pure, technical comparison of two major UI libraries from the developer’s point of view.

Another possible extension would be to add video chat functionality using WebRCT or similar technology.

If I do it, I will make sure you know it!

🔥 Thanks for reading! 🔥

What should we test (ReactJS Components)

Mihail Gaberov — Thu, 25 Apr 2019 12:06:32 +0000

Photo by Artem Sapegin on Unsplash

There are a lot of discussions in the web when we talk about testing. And even more about unit testing. In React.

TL;DR

This is going to be a brief summary of what and how should we think about when we test a ReactJS application. More specific, what should we write tests for, when creating React components for our app. If you want to skip the reading, here you can find shorter version in a few slides.

All of the points below are recommended by people smarter than me. I just collected them as a summary of best practices, trying to help my team to decide on the matter. And start using them in our day-to-day work.

Do we need unit tests?

This is a long time discussion, that has only one right answer. Yes! Tests provide developers with confidence. This confidence allows us to produce software with better quality. To do proper refactoring. And to reason better about what we do.

In short term it might look it’s not worth it. That it takes too much time. Time we might spend for implementing features instead. But very soon after the start of every project, the payoff of having a nice test suit is huge. The punishment of not having such, especially when a release date is approaching — disaster!

Test render logic

When we write tests for our components, we write them in such way that they test only the render logic and don’t care about any internal implementation. What does this mean? It means that, your test should be testing the things that the user will be seeing and interacting with. Let’s say you are testing a component that displays a button on the screen.

When the user clicks the button, your component renders a message in a div element. Your test should check practically for the same — check if the button is clickable and if this div exists after the clicking.

No lifecycle methods

Tests should not test lifecycle methods, they are supposed to be covered by React itself. If we have some logic that needs to be tested in these methods, we should try to extract it in another testable place and only use it in there. Ideally, in our componentDidMount method for example, we should have only functionality for fetching data (calling an API for example). All the rest that you might be tempted to leave there, should be extracted in other methods, that could be tested, if needed.

No outsiders

(Unit) Tests should not test interaction with outside world!

The name “unit” implies independence and autonomy. A unit test should be an encapsulated piece of code, that has inside everything it needs to perform its job. When we need to write tests which need data, we use mocks. That said, every interaction with APIs, DBs, etc., is not a matter of unit tests and should not be tested in such.

Small, smaller, easier

Tests should be small and easy to read — if we need to test a big component with a lot of dependencies, we need to consider splitting it to smaller testable pieces.

Dīvide et imperā.

As the famous quote above implies, it’s a lot more easier to deal with small, well modularized components, than the opposite. Also, if we need to use big mocks, we need to extract them out of the test and only use them by importing, in order to avoid polluting the test file.

Example

Given a simple component containing a button and a text field
We should test what the user sees — rendering, and what the user can do — user interaction
If there is visual change after clicking — test for it
If there is a value returned after clicking — test for it

But we don’t care about the internal implementation of the click handler!

I have prepared a small example, trying to demonstrate the above. You can find it here. In order to run it locally on your machines, just clone it and install the dependencies. Then do ‘npm run test’. 🚀 📜

References

There are many resources on that subject online, but I am going to list here the ones I have found very useful and learned from them.

👏 A nice article on the subject

👏 Another good one for testing with Jest, Enzyme and Sinon

👏 Jest Cheat sheet

👏 Presentation slides online

👏 Github repo with working examples

Conclusion

The important lesson we must keep from all this testing stuff is, that no matter how exactly we write our tests (well it matters…a bit 💬), as long as we write tests at all. This way of thinking and working should become our second nature when we are striving to produce errorproof software. With time and practice the things become better and easier. The most important thing for us is to never stop improving.

Keep going!

🔥 Thanks for reading! 🔥

How to solve the Sherlock and Anagrams coding challenge in JavaScript

Mihail Gaberov — Wed, 24 Apr 2019 07:39:47 +0000

Originally published at mihail-gaberov.eu.

Photo by Javier Quesada on Unsplash

This post is going to get you through my solution of a coding challenge called "Sherlock and Anagrams". You may take a look at it in HackerRank. I spent a lot of time trying to solve it, with JavaScript. When I tried to google it, I could not find a decent JS solution. I found just one and it was not working correctly. Also any explanations were completely out of the question. That's why I decided to write an article about it and try to put some nice and easy to digest explanations along the way. Keep reading now!

⚠ CAUTION: I will roll out my solution below with short explanations about each of the steps. If you want to give a try yourself, please stop here and go to HackerRank site.

Problem

Two strings are anagrams of each other if the letters of one string can be rearranged to form the other string. Given a string, find the number of pairs of substrings of the string that are anagrams of each other.

For example s = mom, the list of all anagrammatic pairs is [m, m], [mo, om] at positions [[0], [2]], [[0, 1], [1, 2]] respectively.

Constraints

Length of the input string: 2 ≤ |s| ≤ 100

String s contains only lowercase letters from the range ascii[a-z].

Analysis

First thing first - we need to get a better understanding of the whole problem. What is an anagram? What is an anagrammatic pair? Can I see one? Also, what exactly does it mean substrings?

In other words, we need to have a clear picture of what are we trying to solve, before solving it.

From the description of the problem we can deduct all we need. Keep walking! 🚶

I think here is a good moment to mention that the challenge in question is under "Dictionaries and Hashmaps" section in HackerRank website, so it's very likely for one to think, that probably he has to use this kind of data structures when solving it. 😇

Anagrams

Since we are going to look for anagrams, let's start with them. As it is described above, an anagram of one word is another word, that has the same length and is created with the same characters from the former one.

So we will have to look for words and compare them with other words, in order to see if they are anagrammatic pairs. Once found, we will just count them.

Anagrammatic pairs

After we saw what an anagram is, it should be relatively easy to conclude, that anagrammatic pair is just two strings that are anagrams. Such as "mo" and "om", or "listen" and "silent". We will have to count how many pairs like this could be found in a given string. In order to do that, we need to split this original string to substrings.

Substrings

Substrings, as the name infer, are parts of a string. These parts could be just a letter or a pair of letters, such as what have we seen in the example above - "m" or "mo". In our solution we will split the original string to such substrings and then we will go over them and do the comparison, which will tell us whether we have anagrammatic pairs among them.

Solution

Now, when we did our analysis, it's showtime! 🎆

Let's summarize:

We need to find all substrings of the given string - create a method for that.
We need to be able to check if two strings are anagrams - create a method for that.
We need to count all anagrammatic pairs in the given string - create a method for that.
Combine everything from above and spit the result - create a method for that.

Get all substrings

This would be our helper method for finding all substring of a given string:

function getAllSubstrings(str) {
  let i, j, result = [];

  for (i = 0; i < str.length; i++) {
    for (j = i + 1; j < str.length + 1; j++) {
      result.push(str.slice(i, j))
    }
  }
  return result
}

As you can see, it has O(n²⁾ time complexity, but for our case it does the job, because we have limited length of the input string (up to 100 characters).

Check for anagrams

This would be our helper method for checking if two strings are anagrammatic pair:

function isAnagram(str1, str2) {
  const hist = {}

  for (let i = 0; i < str1.length; i++) {
    const char = str1[i]
    if (hist[char]) {
      hist[char]++
    } else {
      hist[char] = 1
    }
  }

  for (let j = 0; j < str2.length; j++) {
    const char = str2[j]
    if (hist[char]) {
      hist[char]--
    } else {
      return false
    }
  }

  return true
}

❕ You remember, judging by the section where this challenge belongs, we assumed that most probably we will have to use data structures such as hashmaps or dictionaries. Here is the moment to notice that. We use a simple JavaScript object to play the role of a hashmap. We do two iterations - one per string. When we iterate over the first one, we add its characters as keys to the hashmap and count their appearances, which are going to be stored as their values. Then we do another iteration over the second string. Check if its characters are stored in our hashmap. If yes - decrement their value. If there are missing characters, which means the two strings are not anagrammatic pair, we simply return false. If both loops complete, we return true, signifying that the strings being analysed are anagrammatic pair.

Do the counting

This is the method, where we will use the helper for checking if a pair is anagrammatic and count it. We do that with the help of JavaScript arrays and the methods they provide. We iterate over an array containing all the substrings of the original string. Then we get the currect element and remove it from the array. And then we do another loop through that array and return 1 if we find that there is an anagram of the current element. If nothing is found, we return 0.

function countAnagrams(currentIndex, arr) {
  const currentElement = arr[currentIndex]
  const arrRest = arr.slice(currentIndex + 1)
  let counter = 0

  for (let i = 0; i < arrRest.length; i++) {
    if (currentElement.length === arrRest[i].length && isAnagram(currentElement, arrRest[i])) {
      counter++
    }
  }

 return counter
}

And in the end

The only thing left to be done now is to combine all of the above and spit the desired result. Here is how the final method looks like:

function sherlockAndAnagrams(s) {
  const duplicatesCount = s.split('').filter((v, i) => s.indexOf(v) !== i).length

  if (!duplicatesCount) return 0
  let anagramsCount = 0

  const arr = getAllSubstrings(s)

  for (let i = 0; i < arr.length; i++) {
    anagramsCount += countAnagrams(i, arr)
  }

  return anagramsCount
}

Maybe you have noticed, here I am checking first for duplicates, in order to know if I should continue further. As if there are no duplicated letters, then it's not possible to have an anagram.

And finally, we get all substrings into an array, iterate over it, count the anagrammatic pairs that are found and return this number.
You can find the full code here.

Conclusion

This kind of exercises are very good for making you think algorithmically, but also they change your way of working in your day to day job. My recommendation would be to do the same I am trying to do - train your brain now and then with one of those. And if you can - share. I know sometimes you don't have time for such challenges, but when you do - go for it.

My personal feeling after finishing this was a total satisfaction, which is completely understandable, considering the the time it took me to do it. But at the end, dear reader, I am even happier I can share this experience with you 😌!

🔥 Thanks for reading! 🔥

How to optimize your JavaScript apps using Loops

Mihail Gaberov — Tue, 23 Apr 2019 05:22:01 +0000

Originally published at mihail-gaberov.eu.

One of the easiest and most ignored thing to do, in order to boost up the performance of our JavaScript applications, is to learn how to write properly high performant loop statements. The idea behind this article is to help with that.

We will see the main types of loop used in JavaScript and how can we write them in a performant way.

Let's begin!

LOOP PERFORMANCE

When it comes to loop performance, the debate is always about which loop to use. Which is the fastest and most performant? The truth is, that, of the four loop types provided by JavaScript, only one of them is significantly slower than the others - for-in loop. The choice of loop type should be based on your requirements rather than performance concerns.

There are two main factors that contribute to loop performance - work done per iteration and number of iterations.
In the sections below we will see how by decreasing them, we can have a positive overall impact to the loop performance.

For Loop

ECMA-262, 3rd Edition, the specification that defines JavaScript's basic syntax and behavior, defines four types of loops. The first is the standard for loop, which shares its syntax with other C-like languages:

for (var i = 0; i < 10; i++){
    //loop body
}

This is probably the most commonly used JavaScript looping construct. In order to understand how can we optimize its work, we need to dissect it a little bit.

Dissection

The for loop consists of four parts: initialization, pretest condition, loop body, post-execute. The way it works is the following - first the initialization code is executed (var i = 0;), then the pretest condition (i < 10;). If the pretest condition evaluates to true, then the body of the loop is executed and after that the post-execute code (i++) is run.

Optimizations

The first step in optimizing the amount of work in a loop is to minimize the number of object member and array item lookups.

You can also increase the performance of loops by reversing their order. In JavaScript, reversing a loop does result in a small performance improvement for loops, provided that you eliminate extra operations as a result.

Both of the statements above are valid for the other two faster loops as well (while and do-while).

// original loop
for (var i = 0; i < items.length; i++){
    process(items[i]);
}

// minimizing property lookups
for (var i = 0, len = items.length; i < len; i++){
    process(items[i]);
}

// minimizing property lookups and reversing
for (var i = items.length; i--; ){
    process(items[i]);
}

While Loop

The second type of loop is the while loop. This is simple pretest loop, consisted of pretest condition and a loop body.

var i = 0;
while(i < 10){
    //loop body
    i++;
}

Dissection

If the pretest condition evaluates to true, the loop body is executed. If not - it's skipped. Every while loop can be replaced with for and vice versa.

Optimizations

// original loop
var j = 0;
while (j < items.length){
    process(items[j++]);
}

// minimizing property lookups
var j = 0,
    count = items.length;
while (j < count){
    process(items[j++]);
}

// minimizing property lookups and reversing
var j = items.length;
while (j--){
    process(items[j]);
}

Do-While Loop

do-while is the third type of loop and it's the only post-test loop in JavaScript. It is comprised of body loop and post-test condition:

var i = 0;
do {
    //loop body
} while (i++ < 10);

Dissection

In this type of loop, the loop body is executed always at least once, then the post-test condition is being evaluated, and if it's true, another loop cycle is executed.

Optimizations

// original loop
var k = 0;
do {
    process(items[k++]);
} while (k < items.length);

// minimizing property lookups
var k = 0,
    num = items.length;
do {
    process(items[k++]);
} while (k < num);

// minimizing property lookups and reversing
var k = items.length - 1;
do {
    process(items[k]);
} while (k--);

For-In Loop

The fourth and the last type of loop is called for-in loop. It has very special purpose - enumerates the named properties of any JavaScript object. Here it is how it looks like:

for (var prop in object){
    //loop body
}

Dissection

It's similar to the regular for loop only by its name. The way it works is totally different. And this difference makes it much slower than the other three loops, which have equivalent performance characteristics such that it's not useful to try to determine which is fastest. Each time the loop is executed, the variable prop has the name of another property, which is a string, on the object. It will execute until all properties have been returned. These would be the properties of the object itself, as well as the ones inherited through its prototype chain.

Notes

You should never use "for-in" to iterate over members of an array.

Each iteration through this loop causes a property lookup either on the instance or on the prototype, which makes the for-in loop much slower than the other loops. For the same number of iterations, it could be seven times slower than the rest.

Conclusion

👍 The for, while and do-while loops all have similar performance characteristics, and so no one loop type is significantly faster or slower than the others.

👍 Avoid the for-in loop unless you need to iterate over a number of unknown object properties.

👍 The best ways to improve loop performance are to decrease the amount of work done per iteration and decrease the number of loop iterations.

I hope this was useful for you, as it was for me!

🔥 Thanks for reading! 🔥

Resources

"High Performance JavaScript" - Nicholas C. Zakas