DEV Community: Mayowa Ojo

Build a custom media query composable for Vue apps

Mayowa Ojo — Sun, 17 Oct 2021 21:51:17 +0000

Introduction

Let's face it, building a fully responsive website can be a daunting task and while the functionality CSS provides are usually enough to make your site adapt to the various screen sizes, there are times when you need a little JavaScript to get it just right and nail that smooth user experience on every device.

Imagine for a second, you're building a dashboard for some e-commerce store to manage all sorts of data and you have a sidebar for navigating the various menus. Naturally the sidebar is the less important component of the page so when you want to adjust for smaller screen sizes, this is the component that gives way. We can hide the sidebar completely on mobile and even show a different variant of the sidebar on tablets.

JavaScript media queries offer the flexibility to conditionally render components which brings performance benefits because you don't have to render elements that are not visible to the user.

The Composable

Composables in Vue 3 are like hooks in react. They provide an intuitive way to extract reactive state and functionality to separate modules or as you will, composables.

Note: The code here leverages features unique to Vue 3 as it makes use of the composition API.

We're going to build a media query composable that accepts a media query string and essentially listens for changes in the window size and returns a variable that tells us if the current window size matches the query string.

// useMedia.js
import { ref, watchEffect } from "vue";

export const useMedia = (query) => {
   const matches = ref(true);

   watchEffect((onInvalidate) => {
      const media = window.matchMedia(query);

      if(media.matches !== matches) {
         matches.value = media.matches;
      }

      const onChange = () => {
         matches.value = media.matches;
      }

      media.addEventListener("change", onChange);

      onInvalidate(() => {
         media.removeEventListener("change", onChange);
      });
   });

   return matches
}

Usage

import { useMedia } from "../../composables/useMedia";
...
const isMobile = useMedia("(max-width: 425px)")
...

In the snippet above we use the watchEffect function to subscribe to changes in the matches variable. In the watchEffect callback, we are listening for a change event on the matchMedia property of the window object. When a change is detected, it calls the onChange function which will update the matches reactive object.

We also have an onInvalidate function being called, which receives a callback function where we remove the event listener. This is essentially a clean-up function like you'd have in a react useEffect hook. This lets us cancel all subscriptions when the component is unmounted.

This is how we can easily build our own custom re-usable function to use JavaScript media queries in our components. If you have any questions or thoughts on this, drop a comment below.

References

JavaScript Media Queries
Composables
Side Effect Invalidation

How to make routable modals in react with react-router

Mayowa Ojo — Thu, 26 Nov 2020 17:17:28 +0000

Introduction

Modals are an integral part of web apps. They come in handy when you want to display content that isn't necessarily large enough to take up its own page or content that depends on the current view but ideally should be standalone to give it more emphasis. Because modals are essentially an overlay on a parent page, it makes them tricky to add to our routing system. In this article your're to learn how to add route navigation to your modals.

Prerequisite

Basic knowledge of react, react hooks, and react-router.
React >=16.8

We're going to start by creating a simple react application which displays a list of contacts. You can set up your application locally with create-react-app or for convenience, use an online playground like codesanbox or stackblitz. I'm using stackblitz and there'll be a link to the playground at the end of the post.

Our react app has 4 components (Home, Contacts, Card and Modal). The Home component just renders a welcome text and a link to the contacts page. The Contacts component renders a list of cards and the Card component in turn contains a link to the modal. I'll be using tailwindcss for styling, again for convenience since the focus of this article is on react-router. Let's create a router component and add the home and contacts page.
App.js

import React from "react";
import {
  Switch,
  Route,
  useLocation
} from "react-router-dom";
import Home from "./Home";
import Contacts from "./Contacts";

export default function App() {
  return (
    <div className="w-full bg-gray-200 px-4 relative">
      <Switch>
        <Route path="/" exact component={Home} />
        <Route path="/contacts" exact component={Contacts} />
      </Switch>
    </div>
  );
}

index.js

import React from "react";
import ReactDOM from "react-dom";
import { BrowserRouter as Router } from "react-router-dom";

import App from "./App";

ReactDOM.render(
  <Router>
    <App />
  </Router>,
  document.getElementById("root")
);

We put our Router in the index.js file instead of App.js because we would later need to access some hooks in App.js which will cause errors if we did otherwise.

Home.js

import React from "react";
import { Link } from "react-router-dom";

const Home = () => {
  return (
    <div className="w-full h-screen flex flex-col justify-center items-center">
      <h1 className="text-center text-3xl text-gray-600 font-medium">Welcome!</h1>
      <Link to="/contacts">
        <button className="rounded-lg bg-indigo-400 px-4 py-2 mt-4 text-white font-bold hover:bg-indigo-500">Contacts</button>
      </Link>
    </div>
  )
}

export default Home;

The Home component is very simple. We use a Link component from react-router to navigate to the contacts page.

Contacts.jsx

import React from "react";
import Card from "./Card";

const Contacts = () => {
  return (
    <div className="pt-16 w-full">
      <h1 className="text-2xl font-semibold text-gray-600 text-center">Contacts</h1>
      <div className="flex justify-center flex-wrap mt-8">
        {Array(6).fill().map(() => <Card />)}
      </div>
    </div>
  );
};

export default Contacts;

In the contacts page, we render a list of cards. Since we don't have any actual data we just create an arbitrary array of size 6 and fill it with undefined so we can map to Card components.

Card.jsx

import React from "react";
import { Link } from "react-router-dom";

const Card = () => {
  return (
    <div className="w-56 pb-2 mt-8 mx-4 bg-white rounded-md border border-gray-200 overflow-hidden shadow-lg">
      <Link
        to="/contact/andrew-garfield">
        <div className="flex flex-col items-center py-4 px-2 bg-gray-300">
          <span className="w-10 h-10 rounded-full overflow-hidden inline-block">
            <img
              src="https://uifaces.co/our-content/donated/gPZwCbdS.jpg"
              alt=""
            />
          </span>
          <h1 className="text-lg font-medium text-gray-600 mt-2">
            Andrew Garfield
          </h1>
          <p className="text-sm text-gray-600">Project Manager</p>
        </div>
      </Link>
      <div className="px-2 py-2">
        <p className="text-sm text-gray-600 mt-1 flex items-center">
          <svg
            className="w-4 h-4 mr-2"
            fill="currentColor"
            viewBox="0 0 20 20"
            xmlns="http://www.w3.org/2000/svg"
          >
            <path
              fill-rule="evenodd"
              d="M6 6V5a3 3 0 013-3h2a3 3 0 013 3v1h2a2 2 0 012 2v3.57A22.952 22.952 0 0110 13a22.95 22.95 0 01-8-1.43V8a2 2 0 012-2h2zm2-1a1 1 0 011-1h2a1 1 0 011 1v1H8V5zm1 5a1 1 0 011-1h.01a1 1 0 110 2H10a1 1 0 01-1-1z"
              clipRule="evenodd"
            />
            <path d="M2 13.692V16a2 2 0 002 2h12a2 2 0 002-2v-2.308A24.974 24.974 0 0110 15c-2.796 0-5.487-.46-8-1.308z" />
          </svg>
          Voyance
        </p>
        <p className="text-sm text-gray-600 mt-1 flex items-center">
          <svg
            className="w-4 h-4 mr-2"
            fill="currentColor"
            viewBox="0 0 20 20"
            xmlns="http://www.w3.org/2000/svg"
          >
            <path d="M2.003 5.884L10 9.882l7.997-3.998A2 2 0 0016 4H4a2 2 0 00-1.997 1.884z" />
            <path d="M18 8.118l-8 4-8-4V14a2 2 0 002 2h12a2 2 0 002-2V8.118z" />
          </svg>
          andrew@hey.com
        </p>
        <p className="text-sm text-gray-600 mt-1 flex items-center">
          <svg
            className="w-4 h-4 mr-2"
            fill="currentColor"
            viewBox="0 0 20 20"
            xmlns="http://www.w3.org/2000/svg"
          >
            <path
              fill-rule="evenodd"
              d="M7 2a2 2 0 00-2 2v12a2 2 0 002 2h6a2 2 0 002-2V4a2 2 0 00-2-2H7zm3 14a1 1 0 100-2 1 1 0 000 2z"
              clipRule="evenodd"
            />
          </svg>
          +440-344-45-577
        </p>
        <p className="text-sm text-gray-600 mt-1 flex items-center">
          <svg
            className="w-4 h-4 mr-2"
            fill="currentColor"
            viewBox="0 0 20 20"
            xmlns="http://www.w3.org/2000/svg"
          >
            <path d="M2 5a2 2 0 012-2h7a2 2 0 012 2v4a2 2 0 01-2 2H9l-3 3v-3H4a2 2 0 01-2-2V5z" />
            <path d="M15 7v2a4 4 0 01-4 4H9.828l-1.766 1.767c.28.149.599.233.938.233h2l3 3v-3h2a2 2 0 002-2V9a2 2 0 00-2-2h-1z" />
          </svg>
          @andrew_garfield
        </p>
      </div>
    </div>
  );
};

export default Card;

The Card component contains a Link that navigates to the modal which just displays the a single card but the content is not the focus. Let's now create the logic to make a routable modal.

For our modal to be routable we need to render it in a route component but also make sure that we don't leave the current page when navigating to the modal. We want it to behave like a sub-route. Let's update our App.js
App.js

import React from "react";
import {
  BrowserRouter as Router,
  Switch,
  Route,
  useLocation
} from "react-router-dom";
import Home from "./Home";
import Contacts from "./Contacts";
import Modal from "./Modal";
import "./style.css";

export default function App() {
  const location = useLocation();
  const background = location.state && location.state.background;

  return (
    <div className="w-full bg-gray-200 px-4 relative">
      <Switch location={background || location}>
        <Route path="/" exact component={Home} />
        <Route path="/contacts" exact component={Contacts} />
      </Switch>

      {background && <Route path="/contact/:name" children={<Modal />} />}
    </div>
  );
}

We've introduced two new things; location and background. location is an object that contains url information which we get from the useLocation hook. It updates to the new url whenever we navigate to a new page. background however represents the location state that we were right before we navigate to the modal. Remember we don't actually want to leave the current page, that's why we don't render the Route component for the modal in the Switch component, rather we put it outside and conditionally render depending on the value of background.

What this means is that if there's a background state (it suggests that we are routing to a modal and we don't want to leave the current page), then use the background state as the location for the Switch so that we can still show the current page behind the modal. You should notice that we're passing a location prop to the Switch component whose value is either the background (if it exists) or the new location set by useLocation.

You might be wondering where exactly this background state comes from. Well, we set it in the Link component that navigates to the modal. Since we navigate to our modal from the Card component, let's update it to reflect that.
Card.jsx

import React from "react";
import { Link, useLocation } from "react-router-dom";

const Card = () => {
  const location = useLocation();
  return (
    <div className="w-56 pb-2 mt-8 mx-4 bg-white rounded-md border border-gray-200 overflow-hidden shadow-lg">
      <Link
        to={{
          pathname: "/contact/andrew-garfield",
          state: { background: location }
        }}
      >
        <div className="flex flex-col items-center py-4 px-2 bg-gray-300">
          <span className="w-10 h-10 rounded-full overflow-hidden inline-block">
            <img
              src="https://uifaces.co/our-content/donated/gPZwCbdS.jpg"
              alt=""
            />
          </span>
          <h1 className="text-lg font-medium text-gray-600 mt-2">
            Andrew Garfield
          </h1>
          <p className="text-sm text-gray-600">Project Manager</p>
        </div>
      </Link>
...

I'm showing only the part of the Card component that changed. We now pass an object to the Link component which contains two fields; pathname and state. pathname is the page we're navigating to and state is an object we can pass user defined variables to. So we set the background here which is just the current location we get from useLocation. This is how we tell react-router to use the current location instead of updating to a new location object.

I believe you get the concept now, whenever we want to navigate to a modal, we set the background state to tell react-router that we do not want to leave the current page but just display the modal as an overlay. This gives us the ability to treat the modal as a normal page and use features like history.goBack. I left the Modal component for last so you can see this in action.
Modal.jsx

import React from "react";
import { useHistory } from "react-router-dom";
import Card from "./Card";

const Modal = () => {
  const history = useHistory();

  const closeModal = e => {
    e.stopPropagation();
    history.goBack();
  };

  React.useEffect(() => {
    document.body.classList.add("overflow-hidden");

    return () => {
      document.body.classList.remove("overflow-hidden");
    };
  }, []);

  return (
    <div className="absolute inset-0 bg-black bg-opacity-75 w-full h-screen z-10 flex items-center justify-center">
      <span
        className="inline-block absolute top-0 right-0 mr-4 mt-4 cursor-pointer"
        onClick={closeModal}
      >
        <svg
          class="w-6 h-6 text-white"
          fill="currentColor"
          viewBox="0 0 20 20"
          xmlns="http://www.w3.org/2000/svg"
        >
          <path
            fill-rule="evenodd"
            d="M4.293 4.293a1 1 0 011.414 0L10 8.586l4.293-4.293a1 1 0 111.414 1.414L11.414 10l4.293 4.293a1 1 0 01-1.414 1.414L10 11.414l-4.293 4.293a1 1 0 01-1.414-1.414L8.586 10 4.293 5.707a1 1 0 010-1.414z"
            clip-rule="evenodd"
          />
        </svg>
      </span>
      <Card />
    </div>
  );
};

export default Modal;

Here, we get the history object from the useHistory hook. We can then call history.goBack() when we want to close the modal to navigate to the previous page, only that the previous page is in-fact the current page.

pageCeption

Haha, I'm sorry.

Alright, that is the end of this post. Hopefully, it's not too long and you've learned something new. Here's a link to the demo and a github repo

Cloning Quora's Editor in VueJS

Mayowa Ojo — Tue, 08 Sep 2020 17:01:44 +0000

I recently started building a full-stack clone of the Quora web app as part of my portfolio projects. I'm using Golang and VueJS for this and one of the more challenging parts of the front-end was the custom WYSIWYG editor, so I decided to share my thoughts on how I was able to scale this huddle.

Content

Comparison
A suitable editor
Features
Challenges
Implementation

Comparison with the Original

It's not uncommon for companies in the tech space to develop their own in-house tools. After doing some research, I discovered the rich text editor you see in quora was developed in-house and it's not open-source. Of course, this makes it a tad bit difficult to replicate. I was left with the option of using picking from the plethora of open-source editors (boy are there so much...) and customizing it to look and behave like quora's. Challenge Accepted

After two days of slapping my keyboard and constant headache, I finally pulled it off, and dare I say it makes the original look like the clone (a very bold claim I know).

The original vs the clone:

Picking a Suitable Editor

If you're familiar with WYSIWYG editors, you'll know that they're notoriously known to be difficult to customize to your needs. Now, you can write your own editor from scratch but that is a long dark road that's mostly not worth the torment especially for a one-off portfolio project.

After considering a handful of the more popular editors out there (ckeditor, tinymce, froala, quilljs, editorjs), I figured quilljs was the best fit for a couple of reasons:

It has a nice, clean API
It's well documented
It's reasonably customizable
Extensible through custom modules

Features of Quora's Editor

The editor in itself is not entirely complex, only a couple of things make it unique. It has most of the common formatting options like bold text, italic, ordered and unordered lists, blockquotes, code-blocks, embedded media, HTML links, and edit history. What is less common tho is a mention feature where you can type the @ symbol to select from a list of users, spaces, or topics. Also, the toolbar has 3 layers that slide up and down to ensure only 1 is visible at a time. Not too complex huh.

Challenges

Some of the challenges I faced include:

Implementing the sliding toolbar
Overriding Quill's default image handler
Implementing the mention feature
Handling multiple editors

Implementation

I started by drawing out the UI in Figma with a little improvement of my own in the colors and icons.

Since I'm building the front-end with Vue, I figured using a component library will make my life easier. I found two popular ones (vue-quill-editor and vue2-editor). Both are very good but I went with vue-quill-editor because it provided better customization for the toolbar. However, that came at the cost of implementing my own image handler to override the default behavior of quilljs converting images to blobs. More on that later.

Setting up the editor is easy:

// register globally
// [main.js]
import VueQuill from "vue-quill-editor";
import 'quill/dist/quill.core.css' // import styles
import 'quill/dist/quill.snow.css' // for snow theme

//---
Vue.use(VueQuill);
//---


// [Editor.vue]
<template>
   <quill-editor 
      class="editor" 
      v-model="content" 
      :options="editorConfig['options']" 
      @ready="onEditorReady($event)" 
      ref="editor"
   >
      <div :id="'toolbar'+toolbarId" slot="toolbar">
      // toolbar markup
         <button class="ql-bold" type="button"><button/>
      </div>
   </quill-editor/>
</template>
<script>
export default {
   //---
   name: "Editor",
   data: () => ({
      content: ""
   }),
   computed: {
      editorConfig: function() {
         return {
            options: {
               placeholder: "Write your answer...",
               modules: {
                  toolbar: "#toolbar"
               } 
            }
         }
      } 
   }
}
</script>

That's a basic setup for the editor. Quill lets us customize the look of the editor by overriding some css styles. As shown above, the <quill-editor> component takes a named slot toolbar. This is where we can write our own toolbar markup, while also letting quill handle the logic.

For example, quill looks for any button element with specific class names (e.g ql-bold) that define the functionality of that toolbar element. However, you see even though we can define our own toolbar markup and style it conveniently, quill injects some default styles at runtime to the document <head>. This makes it difficult to style other parts of the editor where we don't control the markup because the injected styles will take precedence.

So how do we tackle this? we programmatically inject our own styles too!. By injecting our own css styles to the document head using the same selectors, we can override whatever styles quill injects. So technically we override their own overrides. * evil grin *

There're a couple of ways to inject styles with javascript. A very simple one is to create a style element with document.createElement() and set the innerHTML to your styles like so:

const injectStyles = () => {
   const style = document.createElement("style");
   style.innerHTML = `
   selector {
      property: value
   }
   `
}

// call injectStyles in the `mounted` lifecycle hook

We can then take advantage of Vue's lifecycle hooks to call this method every time the editor component is mounted. I found this to be very powerful as I could bend the editor to my will just by opening my inspector tab and finding the selectors quill uses for each element I want to override. Let's say we want to change the background color of the editor container, we can simply target the element with its class .ql-container.ql-snow.

I won't be able to write all the code for the editor in this post but here's a link to the GitHub repo for your perusal.

Back to the toolbar. Looking at quora's editor you'll see that the toolbar has 3 layers. A very simple way to implement this is to give the toolbar a specified height (say 44px), have a container inside the toolbar that wraps three other containers each having the same height as the toolbar and serving as a layer. The idea is to make the elements above and below the toolbar sit in front using z-index so that they cover the overflow from the toolbar. We can programmatically pull the toolbar up and down (using top or transform: translate-y) by values equal to the height of the toolbar while adding a nice transition effect. This way, only one layer is visible at a time.

We could have given the toolbar a negative z-index but that will hinder pointer events so we give the elements above and below a higher z-index instead.

I think you get the gist by now. You can just place each button however you want in the toolbar and style them accordingly.

Handling Images

The next feature of the editor is handling images. By default, when you upload an image, quill converts it to a blob. But that's not what we want. We want to get fancy and save the image to a platform like Cloudinary or amazon s3, return a URL and embed that URL in the editor. We can do this by defining our own image handler like so:

// quill - quill instance, can be gotten from the editor ref
const quill = this.$refs['editor']

const handleImageUpload = () => {
   const fileInput = document.createElement("input");
   fileInput.setAttribute("type", "file");
   fileInput.click();

   fileInput.onchange = () => { // Listen for image upload
      const file = fileInput.files[0];
      const formData = new FormData();
      formData.append('image', file);

      if (/^image\//.test(file.type)) {
         // handle server request and return url
         const url = await serverRequest(formData);
         // embed url in editor
         const range = quill.getSelection();
         quill.insertEmbed(range.index, "image", url);
      } else {
         console.warn("[WARNING]: You can only upload images")
      }

   }
}

The function above creates an input of type="file", listens for an upload event (i.e when you select a file from your local system), sends the image to your server, and returns a URL which is embedded in the editor. You can then register this function as a quill module like so:

// ---
onEditorReady: function(quill) {
   quill.getModule("toolbar").addHandler("image", () => {
      this.handleImageUpload();
   });
}
//---

onEditorReady is a function that is called when the ready event is emitted from the quill-editor component.

Mentions feature

The mentions feature was another tricky part. Basically, when you type @ or click the @ button, it shows a list of users, spaces, and topics with a search bar. I found a 3rd party module that implements this and I just had to customize the appearance.

<script>
import "quill-mention";
import { suggestions } from "../constants/suggestions";

//---
handleEditorMention: function(searchTerm, renderList, mentionChar) {
   let values;

   if (mentionChar === "@") {
      values = suggestions;
   }

   if (searchTerm.length === 0) {
      renderList(values, searchTerm);
   } else {
      const matches = [];
      for (let i = 0; i < values.length; i++)
         if (
         ~values[i].value.toLowerCase().indexOf(searchTerm.toLowerCase())
         )
         matches.push(values[i]);
      renderList(matches, searchTerm);
   }
},
//---
</script>

This module registers itself once you import it. Basically, you have a list of suggestions (ideally, you want to make a
request to the server and fetch this list) this module checks for a match as you type @.... Again, it's easy to write your styles for the dropdown list in your injectedStyles function.

Multiple Editors

This was another stumbling block I came across. I discovered having two or more editor instances on the same page causes chaos with the toolbar as they're being referenced by the same toolbar id. One way to fix this is to use different toolbar ids for each editor. But my editor component was rendered in a parent component which in turn was rendered in a loop, so how do we ensure the ids will always be unique?

Generate unique ids with a library like shortid and pass it as props to the editor component after which we can merge with the toolbar id. This ensures we always have unique ids.

<template>
   <quill-editor 
      class="editor" 
      v-model="content" 
      :options="editorConfig['options']" 
      @ready="onEditorReady($event)" 
      ref="editor"
   >
      // id is merged with the generated shortid
      <div :id="'toolbar'+toolbarId" slot="toolbar">
      // toolbar markup
         <button class="ql-bold" type="button"><button/>
      </div>
   </quill-editor/>
</template>

That's a quick overview of how you can build your own custom editor like quora. Hopefully, you found this helpful. Once again, the code is available in this repository. You can check it out if you're interested. It was a good challenge and I'll keep working on the full project. Please share your thoughts below or ask questions, I'm open to discussions.

Build A Simple CLI Tool With Deno

Mayowa Ojo — Mon, 20 Apr 2020 17:20:58 +0000

What is Deno?

Deno is a secure runtime for JavaScript and TypeScript created by Ryan Dahl who also happens to be the creator of Nodejs. If you've never heard of deno, I suggest you watch these talks by Ryan: He talks about his mistakes with Nodejs here and a more in-depth look into deno here
Deno is basically what Nodejs would have been if it was written today. Now, deno is still a relatively new project and it's not reached v1.0 yet and although it's not intended to replace Nodejs, it certainly has prospects to be the future of server-side JavaScript. Some of the core values that makes it different from Nodejs include:

security out of the box - explicit access is required for file, network and environment access.
a different module management system - deno does not use npm and there's no node_modules. Rather, it has a module management system similar to Go where modules are imported via URL.
in-built support for typescript - you can run typescript files directly without compiling to javascript.
it is built with Rust!

I'm personally very excited about this project especially because of its support for typescript. However, it's nowhere near reaching Nodejs in terms of popularity and adoption.

Let's build something!

In this article, we're going to build a simple cli tool to demonstrate some of the features of deno. Our cli will be interacting with a cryptocurrency API to fetch live data.

Requirement: make sure you have deno installed. If you don't, refer to this link. It's pretty straightforward.

Deno projects typically have an entry file called mod.ts so we're going to start here. If you're coding along, create your project folder alongside your entry file. Here's what the project directory looks like:

Overview:

mod.ts is our entry file.
Makefile contains useful commands that would typically be in package.json for a Node.js project.
deps.ts contains all our dependencies.
types.d.ts contains our type definitions.
import_map.json contains our import maps. We use this to enable clarity and readability.

Our cli is basically going to provide two commands. One to fetch and list all coin prices within a limit and one to fetch a particular coin using an id. First off, we need to parse the flags provided with each command and deno provides us just what we need from the std library. So we're going to import the parse method from the flags module. This is how we import modules in deno:

In deno, modules are imported using a URL and they're cached the first time you run your app so even if you don't have an internet connection at subsequent times, your app will still run. The @v0.38.0 in our import means I'm importing from the release version I currently have installed. You can omit that and just import from the latest version if you just installed deno. In the code above, we're destructuring the args variable from the Deno namespace which simply returns the arguments passed to a script then we pass it to the parse method which returns an object containing all arguments passed in key-value pairs. For example, if we run our program as $ crypto-cli --coins --limit 10, the object returned will be: {_: [], coins: true, limit: 10}. The first property in the object is always an array containing all arguments that did not have an option associated with them(i.e it doesn't match -f or --flag). If you do not pass a corresponding value to a flag, it defaults to true.

Let's write out the function for our first command:

Here, we have an async function that returns the data from our API call. We're making a fetch request (yes, deno has browser functionality in-built) to the API endpoint to get all coins within the limit provided. The if statement checks if a limit was not provided and defaults to 10.

The function for the second command looks very similar, only that an id is provided this time.

The response data from the API contains a bunch of information so we're going to filter what we need out and format the data we want to display.

In the code above, the formatData function accepts the raw data object and returns a string of the coin name and current price in USD.

Now let's define the main function which executes our program commands.

The function above is an IIFE which runs immediately the file is executed. We have a switch statement to check the first flag that was passed and calls the appropriate function. The default case simply displays the welcome message. We also have if conditions to check for optional flags like the limit.

To test our program, we're going to run $ deno run --allow-net mod.ts --coins --limit 10. We should get the following result:

You must have noticed the --allow-net flag passed to the command. This is an example of deno being security first. Deno can't access your network, files, or environment without giving it explicit access. So for example, if your code needs to access the file system you'd need to run it with the --allow-read flag.

That's all there is for our cli tool. If you'd like to see the full code, the repository is linked here. In conclusion, Deno is a very exciting project especially because you get all the benefits of typescript out of the box without the need to compile your files to js. You can build a lot with it, ranging from cli Programs to HTTP servers. Do have a look at the collection of 3rd party libraries and see what people are building.

How Pointers Work In Go

Mayowa Ojo — Wed, 15 Apr 2020 10:23:00 +0000

This is my second article since I started learning the go programming language. If you're also getting your feet wet with a statically typed and compiled language like Go for the first time, this article will help you understand the what and why of pointers.

What are pointers?

Pointers, in computer programming, are simply objects that store memory addresses. A memory address is a reference to a specific location in memory. Think of it as physical addresses, you can easily access a particular location on a map if you had the address right? The map here is the computer memory layout where you store variables of different types each referenced by a unique address.

Why pointers?

By now you must be wondering what is the significance of pointers. Pointers are particularly useful in repetitive operations like working with iterables or working with multiple copies of the same underlying data. It is much faster and less expensive to copy over a pointer to a variable and also to deference it rather than copying the whole data structure itself.

Let's say you have an array of 10,000 items and you want to make a duplicate, copying over an array of such size is not only less efficient but will also be significantly slower than copying a memory address. Imagine you had to make up to 3, 4, or even 10 copies, it's starting to look silly.

NB: Dereferencing means fetching the value stored at a memory location by a pointer.

While pointers are not explicitly available in every programming language, a similar concept like the reference data type is used rather than pointers in languages like JavaScript, Java, Python. The benefit of pointers is that it removes the layer of abstraction that comes with references and allows the developer explicit access to memory addresses.

Pointers in Go

Go, like C and C++ gives us pointers to work with. The syntax is similar to C but with a little difference. This is how you define a pointer in Go:

In the snippet above, we define a variable called name (very thoughtful) and set the value "John Travolta". We also define another variable pointerToName which is literally a pointer to the variable name. The "&" symbol preceding name essentially says: "give me the memory address of this variable". If we print both variables, we see that name outputs the value of the variable while pointerToName outputs the memory address of the variable name.

So how do you dereference (i.e fetch the underlying value of a memory address) a pointer in go? Before we look at the syntax, it's worth noting that go is a pass-by-value language. This means that when we pass variables around (e.g to a function or assigning an existing variable to another variable declaration), the value is copied to a different memory location and is no longer tied to the original copy. If we mutate the duplicate data, the original copy maintains its state.

This is what is known as passing by value. Of course, the opposite happens when you pass by reference.
Although, not all data types are passed by value. Slices, maps, channels, functions and of course pointers are reference types while ints, floats, strings, bools, and structs are value types. It is worth noting especially when working with structs to build more complex data structures.

Consider the following snippet:

What's happening here? We're simply defining a struct that describes a user with 4 fields. We declare a variable user1 of type User and set the field values. We declare a new variable user2 by copying user1 then we update the age field. From the output of the two variables, we see that the age field remains unchanged for user1 while user2 is updated. Moving on, we declare a third variable, wait for it, user3 and set it to be a pointer to user1. Now, we do the same thing by updating the age and isAdmin fields and from the output, we see that these files were updated for both user1 and user3.

The "*" symbol preceding user3 in the fmt.Printf() function is how we dereference pointers. We're essentially saying: "give me the value stored at this memory address". This is the reverse use case of the "&" symbol.

In conclusion, we can observe that our data structure wasn't mutable by default and we had to explicitly mutate it through pointers which is a good safety measure. This is an introduction to pointers, however, there's more to it like its usage in receiver functions and double pointers. You can read more about pointers in Go here and here.

A Barebones Introduction To Go Modules

Mayowa Ojo — Sun, 22 Mar 2020 08:24:50 +0000

I recently started learning golang and as with any language you're picking up for the first time, I had difficulty understanding some concepts. Coming from the world of JavaScript, installing packages, module management, and general code organization was fairly easy to grasp, however, I wasn't ready for what go had in stock. After doing some research, I found out about go modules, GOPATH, GOROOT, and some other crap I didn't understand.

Basically, local and 3rd party packages in go weren't very easy to work with as your code has to be in some specific location to be able to install dependencies, but if you're learning go in 2020 you're in luck because since go v1.11, you can use go modules, which is the new dependency management for go.

A module is a collection of go packages that reside within a directory that has the file go.mod at its root. In essence, a project directory is a module if it has go.mod at the top level just like you have a package.json in a JavaScript project. A package, on the other hand, is a collection of go source files that exist in the same directory. Functions, types, variables, and constants are visible to all files within a package, provided they're capitalized.

You can organize your reusable code into its own package and then import anywhere you want to use it. To setup go modules in your project directory, simply run go mod init <repository url>. This would create a go.mod and a go.sum file where you can manage your dependencies. Visit the official docs to dive deeper. You now can now easily import your local and 3rd party packages without worrying about $GOPATH and whatnot.

NOTE: To use go modules, your project directory must be outside the GOPATH. Go automatically disables go modules when inside GOPATH.

Let's look at a simple example for you to picture this concept clearly. Say you have a project folder named awesome-cli with the following structure.

awesome-cli ---
              |
             cli ---
                   |
                   cli.go
             config ---
                      |
                      database_config.go
             utils ---
                     |
                     parser.go
                     database.go
             go.mod
             go.sum
             main.go
            .gitignore
             README.md
             Makefile

To initialize go modules in the project folder, you'd run go mod innit github.com/<username>/awesome-cli. Now if you want to import a Parser function from utils/parser.go into your cli.go file, it would look like:

cli.go

package main

import (
    "fmt"
    "github.com/<username>/awesome-go/utils"
)

func main() {
   // use parser function
   parsedArgument, err := utils.Parser(arg)
}

parser.go

package utils

func Parser(arg string) (parsedArgument, error) {
   // do something
}

Notice that the Parser function is capitalized, this is because named exports are capitalized in go. Also, anyone can import this module using the url provided and you can import packages from other repositories with go get.

This is a very low-level dive into go modules for a beginner. You can look into the go docs for more advanced concepts.

Avoid deeply nested imports with path mapping in typescript

Mayowa Ojo — Sun, 15 Mar 2020 06:06:50 +0000

Photo by Lukas Beran on Unsplash

Importing modules with relative paths can be such a pain as your codebase grows and you start splitting large files into smaller reusable modules. Files get nested very deep so much you stare at your folder structure perplexed. Consider the following folder structure:

root/
   tsconfig.json
   types.d.ts
   .env
   src/
      server.ts
      database/
      models/
      routes/
         posts/
         comments/
      controllers/
         posts/
         comments/
         media/
      utils/
         database/
            seed.ts
         workers/
            publisher.ts

Say you want to import a function from a module in src/utils/workers into the post controller, it's already looking like a mess: import { function } from "../../utils/workers/publisher.ts". This can get even messier when file locations change and you need to update everywhere you imported that file.

One way to tackle this is to use typescript path mapping. You define a namespace in your tsconfig mapping it to a specified path by declaring a paths field in your tsconfig.json under compilerOptions like so:

{
   "compilerOptions": {
      "baseUrl": ".",
      "paths": {
         "@workers/*": ["src/utils/workers/*"],
         "@mediaControllers/*": ["src/controllers/media/*"]
      }
   }
}

Here, we set the baseUrl to the root directory, which is necessary for creating path maps. We create a namespace "@workers" which maps to the path "src/utils/workers/". The '@' symbol is not necessary, it's just there to easily standout and make it recognizable as a namespace.

Now if we want to import a module from workers, we simply use the namespace. i.e import { function } from "@workers/publisher.ts". We don't have to worry about relative paths anymore, and when we move files from their original location, we just simply update the path map. So problem solved! 😁️.

Note that typescript resolves paths relative to baseUrl so keep that in mind when creating path maps.

Utilizing symbolic links in your Node.js projects

Mayowa Ojo — Tue, 10 Mar 2020 02:06:47 +0000

Photo by Paul Esch-Laurent on Unsplash

A symbolic link(or symlink) is used to describe any file that contains a reference to some other file or directory which can be in the form of a relative or absolute path. In a way, you can say a symlink is a shortcut file. If you haven't heard of symlinks before, this can significantly speed up your development process and aid productivity so keep reading to learn how. 😁

N.B: Creating symlinks is not a concept specific to Node.js or npm, in fact, it's existed since the 1970s in computer science.

One good use case of symbolic links is during your development process. You normally extract repeated functions and methods or blocks of code into its own module to enable reusability, but you remember you've used the same functionality in a different project and you don't want to copy/paste code. What are your options?

import the file from your other project. This could work but you'd have to always use the relative/absolute path and your code can break if there are any changes made in your filesystem.
publish your reusable code to npm and install it in your new project. I think you'd agree that this is unnecessary overhead.

This is where symlinks can be useful. Creating a symlink will make your module available globally and you can access it from anywhere in your filesystem. What's even more awesome is you can make your file an executable and have it mapped to a command you can run from your terminal to execute this file.

So how do you create symlinks? npm makes this seamless. It's as easy as typing npm link from the root directory where your module is located(i.e where your package.json is). This will create a symlink between the global directory where your node_modules is located and the local directory where you ran this command.

Now, in your package.json, add the following:




"bin": {
  "<package name>": "<relative path to your file/module"
}

<package name> is whatever you chose to name your file/module. Note that this is what npm will use to locate it. This is also what you'll use to execute the file from the terminal. If for example, you're trying to expose a file named cli.js in a folder called utils, which is in the src folder your path would be ./src/utils/cli.js.

The next step is to use this in your other project. Simply go to that directory and run npm link <package name>. Npm will essentially install that package in your new project and you can import it just like any other npm package without bothering about resolving the path.

Lastly, if you want to run this file as an executable, add the following to the top of the file:



#!/bin/env node

We're essentially telling the system that the JavaScript file interpreter should be usr/bin/env node. This is the path to your node executable and can vary in your system so take note. You can now execute this file from the terminal using just the package name.

P.S: If you run into errors executing your file, check the file permissions in case it's not executable by default. To make it executable, run chmod +x <filename>

Prevent Your App From Idling on Heroku

Mayowa Ojo — Tue, 03 Mar 2020 23:29:33 +0000

This is a short article on how to stop your app from entering an idle/sleeping state when deployed to Heroku. If you have personal projects you hosted on Heroku servers which don't generate much traffic because they're just well, personal projects, you might have noticed it takes a considerable amount of time to serve up the page when you randomly go to the URL. This is because the free dynos provided by Heroku go to a sleeping mode when it doesn't receive any request for about 30 mins. However, if your app has more than one web dyno, it will never go into an idle state.

The dyno manager will reboot when a request is made but this takes roughly 10 seconds and that's why your site will seem slow. Read more about apps sleeping on Heroku in this post.

If for example, your app is a service that runs some scheduled background processes and doesn't necessarily make Http requests, then you don't want it going into sleep mode because your scheduled task won't run.

I'm going to cover two ways you can prevent idling in this post. Both methods are based on constantly making Http requests to your server in order to simulate the effect of traffic and keep the dyno busy.

- Using Timers

The first method is to use timers, notably the native setInterval function in NodeJS. Basically, the setInterval will call a function that makes a request continuously at a specified timer interval. Ideally, we'd like to keep that interval under 30 mins. Here's a code sample:

// keepAlive.js
const fetch = require('node-fetch');

// globals
const interval = 25*60*1000; // interval in milliseconds - {25mins x 60s x 1000}ms
const url = <some route exposed by your api>

(function wake() {

  try {

    const handler = setInterval(() => {

      fetch(url)
        .then(res => console.log(`response-ok: ${res.ok}, status: ${res.status}`)
        .catch(err => console.error(`Error occured: ${err}`));

    }, interval);

  } catch(err) {
      console.error('Error occured: retrying...);
      clearInterval(handler);
      return setTimeout(() => wake(), 10000);
  };

})();

We use an IIFE(immediately invoked function expression) since we want the timer to start once the server is up. Just import/require this file in your server/index.js file. We're also recursively calling the function should the request fail in order to try again after 10s.

- Using Cron Jobs

The second method, which is my preferred one uses a cron job. This is easier to work with and much cleaner in my opinion. A cron is simply a time-based job scheduler. Essentially, it will run a task given to it at a scheduled time continuously until it's stopped. There's a number of libraries to handle cron jobs and node-cron is one of them. Here's a code sample.

// keepAlive.js

const cron = require('cron');
const fetch = require('node-fetch');

// globals
const url = <some route exposed by your api>

(() => {


  const cronJob = cron.CronJob('0 */25 * * * *', () => {

    fetch(url)
      .then(res => console.log(`response-ok: ${res.ok}, status: ${res.status})
      .catch(err => );

  });

  cronJob.start();
})();

Here, we use an IIFE again to invoke the function. We create an instance of the CronJob class which takes the cron time as its first parameter and a callback. The cron time format means it will run every 25 minutes. A helpful tool to generate cron schedule expressions can be found here.

Now, since we don't need any particular response from the fetch method, we simply log the response status to the console and if you run $ heroku logs --tail in your terminal, you'd see these messages from the requests being made. You can use this to confirm that the requests are running constantly at the specified time interval.

Please share your thoughts below.