DEV Community: UGOJI Duziem

Make your Ionic Apps 100% responsive

UGOJI Duziem — Tue, 05 Jul 2022 15:04:39 +0000

Ionic Framework is used for building cross-platform mobile apps. Cross-platform apps are apps that work on more than one platform (e.g. android, iOS, Desktop), using the same code base.

Ionic comes out of the box with mobile-optimized responsive UI components, which adjust themselves accordingly across different screen sizes (responsiveness). This is what makes Ionic really great to use.

However, without extra effort, you will not get eye-popping responsiveness, and your app will look amateur or average. Thus, 'make your ionic apps 100% responsive' will turn your app from okay-but-not-excellent on some screens towards first-rate perfect beauty on all screens.

100% responsiveness simply means having a layout that is scalable across different screen sizes without losing its proportionality in relation with its elements and to different parts of the screen. This means the way your app appears on an iPhone X should be just as pleasant when it is opened on an iPad (even though an iPad is roughly two times the size of an iPhone X), and should appear just as pleasant on a desktop. This efficiency of design is music to the user. It attests to a precision of purpose. Each user of your app albeit with different devices should feel as though your app was specifically built for their particular device. 100% responsiveness has everything to do with CSS. And the css units for responsiveness are rem, em, %, vw, vh. These units are called relative units.

It is on CSS relative units that all hope of true 100% responsiveness is based. To attain this responsive goal, you will not accept any fixed unit such as px in your application. With that background set, let us develop our responsive app.

This efficiency of design was music to the young mind. It attested to a precision of purpose and the promise of adventure.

Count Alexander Rostov in 'The Gentleman From Moscow'

I assume that you have the ionic cli environment set up on your computer. If you don't, follow the installation guidelines on the ionic website. Essentially, you install the ionic cli by typing the below command in your terminal



npm install -g @ionic/cli

If you have an existing app, great! work with it. Otherwise you can start a new app by typing



ionic start exampleApp

exampleApp is the name of the app.

Having created your new Ionic app, switch into its directory, and run the app in the browser, by typing in the terminal the below command



ionic serve

Towards Responsiveness

Before beginning to develop your app, you should decide on the screen size you want to work with. This will be your base screen size, from which you will work out the relative percentages of the layout for all other screen sizes.
For mobile applications, a very good generic screen width to work with is 360px. Alternatively, you can choose any of the template mobile screen sizes that the Chrome browser offers in its device toolbar.

You can get to Chrome's device toolbar by right-clicking anywhere in the browser, and clicking inspect. This opens Chrome's Developer tools. A shortcut to reach here is to combine CTRL+SHIFT+i.In the Developer's tools, look for the device toolbar icon, it is next to `Elements` button. Click on it to toggle the device toolbar on or off. You will have something like below

From the image above, you can see that we have settled on using the Samsung Galaxy S8+ screen size as our base working screen size. The advantage of working with a mobile screen size when developing with ionic is that the UI components that ionic offers were especially built with mobile screen dimensions in mind, so when you use a mobile screen size, you see how these components were designed to look.

Now that we've settled on the base screen size that we will be working with (360px), let us go to our codebase and implement responsiveness.

In the global.scss file, which can be found in the src folder, append the css media queries typed out below



/* For responsiveness across screens */
html {
  font-size: 100%;
  @media (max-width: 289px) {
      font-size: 45%;
  }
  @media (min-width: 290px) {
      font-size: 50%;
  }
  @media (min-width: 300px) {
      font-size: 52.5%;
  }
  @media (min-width: 320px) {
      font-size: 55.5%;
  }
  @media (min-width: 325px) {
      font-size: 56.5%;
  }
  @media (min-width: 326px) {
      font-size: 57%;
  }
  @media (min-width: 330px) {
      font-size: 59%;
  }
  @media (min-width: 360px) {
      font-size: 62.5%;
  }
  @media (min-width: 411px) {
      font-size: 70%;
  }
  @media (min-width: 500px) {
      font-size: 85%;
  }
  @media (min-width: 720px) {
      font-size: 100%;
  }
  @media (min-width: 1000px) {
      font-size: 110%;
  }
}
html.ios {
  @media (max-width: 359px) and (min-width: 320px) {
      font-size: 59%;
  }
}

Explanation

The default font-size of most web browsers is 16px. So the above code gives us a percentage of that 16px, for different ranges of screen size. Keep in mind that we selected 360px as our working screen size. 62.5% of 16px gives us 10px. This translates to 1rem equal to 10px. This makes conversion easier especially when we are getting the measurement from a UI design that is very likely to be in px.
The above CSS code says I want the font-size of my app to be 100% of whatever value I give it, except when the device screen falls within any of the limits captured by the different media queries. In that case, let the font-size of the app be the percentage value found within that limit.
The html.ios css selector targets iOS devices.

With the font-size of the html set globally, we can go into the different css files of our codebase, and confidently write responsive css using rem, em, %, vh, and vw units. Remember we don't use absolute units (px) for responsive design.

Some CSS tidbits

A rem value changes in proportion to the root computed font-size i.e the global html font-size. rem is the unit we will use in most cases. It's great for aligning block elements relative to the screen size.
An em value changes in proportion to the font-size of the parent element. em units are better for sizing inline elements. SVG icons are perfect candidates for em-based sizing.
A vh value is the % value of the current viewport height
A vw value is the % value of the current viewport width.

The above tidbits set you good to go on and build responsively. But with ionic, that will only get you to like 80% of your desired goal.
As long as you use ionic built-in UI components, your UI may look decent, but it will still lack that proportionality that makes an app feel great on all screens. This is because ionic UI components are built using px units. px units are absolute. They don't scale.

Ionic built-in UI components

Take the ion-item for example, this component has custom css properties such as --padding-end, --padding-start, --padding-top, --border-radius. In essence, all properties of an ionic built-in component, that have to deal with length, were designed with px unit. Therefore you have to update them in your css file with their rem equivalent. That is to say, if the default --padding-start of ion-item is 10px, in your css file, you update it



ion-item {
  --padding-start: 1rem // or whatever value that fits your purpose
}

By updating the default custom css properties of ionic UI components, you get a component that truly scales magnificently across all screens.

Ionic CSS utilities

Eschew completely the use of ion-padding and ion-margin css utilities in your templates. These particular utilities are in px units. They do not scale. Instead create the padding or margin, as required, inside your css file.

Other CSS utilities that ionic provides are actually great for responsive design. Ionic grid system is amazing for great responsiveness.

And yes, with these extra efforts, your app transforms from one that looks good on some screens, and average on others, to one that effuses joy in the hands of any user on any screen. I hope this post is helpful to you. Thank you for reading.

The thing with JavaScript Template literals

UGOJI Duziem — Sun, 27 Feb 2022 12:55:14 +0000

Template literals in JavaScript are depicted by back ticks ``.
They are useful because they help us to include variables and functions within a sentence without the need for truncating and joining. What do I mean?

Example 1a:

Without Template Literals``

var belligerent1 = 'NATO'
var belligerent2 = 'Russia'

var sentence = 'Upheaval in Europe as ' + belligerent1 + ' and ' + belligerent2 + ' attempt a showdown'

As you can see from the above example, our sentence needed the values of the variables belligerent1 and belligerent2 for its message to be complete.
Without template strings, we truncate the strings at the point where we need to insert the variable, use the + operator to join the variables to our strings, so that in the end we have a complete sentence.

With Template literals, you can rewrite the sentence without the need to truncate and join.

Example 1b:

With Template Literals

var beliigerent1 = 'NATO'
var belligerent2 = 'Russia'

var sentence = `Upheaval in Europe as ${belligerent1} and ${belligerent2} attempt a showdown`

The rewritten version above, shows a string with variables included that is not using the + operator and yet is full and complete. Thanks to template literals.
By enclosing your string with back ticks ``, JavaScript uses ${ } to embed variables and functions into the string. And so with back ticks, you can write full sentences having variables, and functions, without the need to truncate and join.

Example 1c

With Template Literals``

var belligerent1 = 'NATO'
var belligerent2 = 'Russia'
function takeAction(value) {
 if (value == 'pressure') return 'charge'
 if (value == 'reflect') return 'retrace steps'

 return 'deliberate some more'
}

var sentence = `Upheaval in Europe as ${belligerent1} and ${belligerent2} attempt a showdown. Certainly, one of them, soon or late, will ${takeAction('reflect')}`

A third example with function included just for the good of it.

So what is it with Template Literals??

It is in when you're trying to make a perfect replica of a string, maybe for example, in a software testing scenario.
Generally, strings are tricky to reproduce. Some may have spaces or next lines (\n), or the lack of them, which your eye did not quite catch, and so you code your string, but the test script does not agree with your submission. And thus, these features, such as spaces, next lines, if present or absent, can be the make or break between the app accepting your submission, as the string it wants.

Obviously, the longer the string, or where there are paragraphs in a string, the higher the chances of a miss in reproducing it perfectly.
Template literals, in addition to being employed for conveniently including variables and functions in strings, they are also employed, quite often too, when strings are long and have paragraphs.
Normal string quotes '' or "" cannot make paragraphs within the string with the ENTER key on the keyboard. One has to encode the paragraph with \n, and generally continue typing on the same line. See the tip below.

Tip:

whether you're using template strings or normal quotes, you can wrap your string onto the next line with the escape character \. The escape character is really a handy tool in strings and regex.

The template string differs again from normal quoted string in that it recognizes the ENTER key of your keyboard and allows you to make paragraphs without the need to use \n. Here in this its strength also lies its slippery slope.

When you code in a string of multiple lines enclosed in template literals, you may miss some spaces and paragraphs that are contained therein. Especially if this string is to be the exact replica of another written string. Also

Your code editor may format your code and introduce unwanted spaces in your string
Every ENTER key press you make in your template string, is a \n introduced
When you print your string, you may not observe some of the extra spaces you have introduced by yourself, yet if the string is to match another, then it's very important to be aware of why the match might be bringing up a fail even when the two strings look very much the same.

Some steps to take to protect yourself from this GOTCHA

These steps are only necessary really, if the output pattern of your string is crucial to what you're doing or testing.
Here are some steps...

If you simply mean to wrap your code to the next line, while in a template string, use the escape character \

Example:

const foodStatus: `There's still rice. There's beans, but there's \
no more meat, no plantain, and no egg.`

Observe that I did not put the beginning of the sentence in a new line, away from its opening quote. That would have literally created a \n at the top of the string, and that is not my intention.

Where there are no variables of functions to be included, you could opt for normal quoted strings entirely. Example:

const foodStatus: "There's still rice. There's beans, but there's no more meat, no plantain, and no egg."

Combine template literals with normal quoted strings. You use the template literals where you need to get in the variables and functions, and normal quotes where only strings are involved. Yes, you will use the + operator to join them. But at least you can be super certain of every space and \n that exists in the string, as you will ensure no string wraps into the next line. More so, you will preserve your code formatting style this way. Example:

function takeAction(value) {
 return (
`There are ${(2 > 1) ? 2 : 'no'} yam${true ? '' : 's'}` +
' in the farm barn, ' +
`but there are ${(5 % 2 == 0 ) ? 5 : 30} egg${false ? '' : 's'} of beer.\n` +
' enough to go round.'
)
}

This way, the ENTER key pressed outside any of the quotes don't add any \n. And you're confident of where all spaces and \n are.

Thank you for reading.

Optimising JavaScript code

UGOJI Duziem — Fri, 14 May 2021 12:09:06 +0000

An optimized piece of code is any code that works optimally, i.e. code that is efficient. We say code is efficient, when it wastes neither time nor effort nor expense (expense includes computer memory). The reward for an optimised JavaScript code is generally a less buggy, smaller-sized, smoother and faster application.

In this article, I reproduce a program, which I wrote for a front-end web application to check if a number given by the user is a narcissistic number.

The flesh of the app is codified by the HTML and CSS given below.

<body>
  <div class="container">
    <h3>Narcissistic Number</h3>
    <p>Type in a number to check if it's narcissistic</p>
    <input type="number" id="inputField" onfocus="this.value=''" autofocus />
    <button id="btn">evaluate</button>
    <p id="displayResult"></p>
  </div>
</body>

The CSS

.container {
  margin: 0 auto;
  width: 280px;
  background-color: #fafafa;
}

p[data-status="true"] {
  color: green;
}

p[data-status="false"] {
  color: red;
}

The above HTML & CSS produce a beautiful application that looks like this

Now for the functioning of the app, (for the body cannot live without the mind - Morpheous), our JavaScript code that makes the app tick, is coded thus...

let displayResultEl = document.getElementById("displayResult");
let inputField = document.getElementById("inputField");

function isInteger(x) {
  return x % 1 === 0;
}

let narcissistic = function() {
  let strValue = inputField.value; //this is a string
  if(isInteger(strValue)) { 
    let power = strValue.length;
    let allDigits = [];

    for(let i = 0; i < power; i++) {
      allDigits.push(parseInt(strValue[i], 10));
    }

    let raisedToPowers = allDigits.map(digit => 
             Math.pow(digit,power));
    let total = raisedToPowers.reduce(
               (sum, raisedToPower) => {
                 return sum + raisedToPower;
                }, 0);
     if(total == strValue) {
       displayResultEl.dataset.status = "true";
       return `TRUE! ${strValue} is a narcissitic number`;
     } else {
       displayResultEl.dataset.status = "false";
       return `False! ${strValue} is not a narcissistic 
              number`;
     }
   } else {
       displayResultEl.dataset.status = "false";
       return "Use positive integers only";
   }
}

let btnEl = document.getElementById("btn");
btnEl.onclick = function() {
  displayResultEl.innerHTML = narcissistic();
}

const enterKey = 13;
inputField.addEventListener("keyup", function(event) {
  event.preventDefault();
  if(event.keyCode === enterKey) {
     btnEl.click();
  }
});

Summarily, what the above JavaScript code accomplishes is,

It takes the input typed in by the user, and checks to see if it is a narcissistic number or not. It displays the result of that check.

Hurray! The app works🙈😀. By the way, a narcissistic number is a number that is the sum of its own digits each raised to the power of the number of digits. Narcissistic numbers include, in addition to all single digit numbers, 153, 370, 371, 407, 1634 etc.

Back to our app, the check is started either when the user hits the button on the app, or after the user has pressed the enter key on their keyboard. A magnificent triumph!
However, when you have gotten your app to do what it is intended to do, you then want to optimise for performance and maintainability. As it is, the JavaScript solution above, as most first time code solutions, is clunky and not optimised. Bugs delight in such code.

The Refactor

So what's with the above JavaScript code, and where can we optimise?
When we observe the code, we notice a couple of things

There are variables in the global space.
Global variables make codes harder to maintain, as they could be used anywhere.
There is a callback function using a variable (btnEl) outside its scope.
This is a major gotcha for developers. Because of the concept of closure, reference to a variable declared outside its scope remains. This is a cause of Memory leak, which can lead to all types of nightmares as the application gets bigger.
Objects declared and initialized in one outer scope are being brought into the inner local scope wholly, when perhaps the inner scope only needs one property or two. An object being used in this manner only adds up more memory usage. A destructured object allows for inner local scopes to use just those properties they need without having to bring in all kb of that object. For instance, in our code, the narcissistic function has inputField.value inside its scope. In reality, that function holds all the properties in inputField, not just value. This is unnecessary memory consumption.
There may be redundant lines of code, which only increases the time for the algorithm to run
The narcissistic function does more than one thing. It checks for the narcissistic status of the input, which is what it is set up to do. But then goes on as well to update DOM elements (a second thing). These concerns can be separated.
There is no clear pattern or definite architecture to our code. It seems anything can be anywhere.

The first step towards refactoring, and therefore optimisation of code, is observation, which is what we have done. Let us see if we can apply some improvement.

The Improvement

Picking it from (6), every code needs a discernible structure. You may call it pattern or architecture. Any name is fine by me as long as it brings in a bit of order. Let me also say, there is no one structure to rule them all. For the code above, I will like to use a module pattern, which I grasped while taking a Jonas Schmedtmann course on JavaScript.
In essence, every front-end application has its UI part (UI module), its computational part (Data Module), and its controller part (App Controller Module).

Anything directly affecting the UI, stays inside the UI module.
The calculations, permutations, brain work, stays inside the Data Module.
Finally the App Controller module takes care of all event handlers, as well as acts as the intermediary between the UI and the Data modules.

This separation of concerns is captured thus...

//UI Controller
let UIController = (function() {

  return {
    ...
  }
})();


//Data Controller
let dataController = (function(){

  return {
    ...
  }
})();


// App controller
let controller = (function(dataCtrl, UICtrl) {
  return {
    init: function() {
      console.log('Application has started');
      setupEventListeners();
    }
  }
})(dataController, UIController);

controller.init();

You can see now, with a structure, we have solved many things at once. We will not have variables lying about in the global space anymore, they will have to fit in, in one of the module's local scopes. This clarity gives every developer confidence that they are not altering what they needn't alter.
After this improvement, you want to improve the code itself, its algorithm, remove redundant lines and also ensure that functions do only one thing.
Let us look at how our improved code looks in the UI module...

let UIController = (function() {
  let DOMstrings = {
    displayResult: "displayResult",
    inputField: "inputField",
    btn: "btn"
  }

  let outputStatement = function({ isNarcissistic, strValue, exponent, sum }) {
    let sentence = `${strValue} is ${isNarcissistic ? '' : 'not'} a narcissistic value.\n 
      The sum of its own digits, each raised to the total digits count ${exponent}, is ${sum}`;

    switch(isNarcissistic) {
      case false:      
        return `No, ${sentence(false)}`;
      case true:
        return `Yes, ${sentence(true)}`;
      default:
        return "Please type in an integer"
    }
  }

  return {
    getDOMstrings: function() {
      return DOMstrings;
    },
    getOutputStatement: function(value) {
      return outputStatement(value);
    }
  }
})();

In the UI module,

we hold all the DOM strings in an object, so we only need to change them in one place if the need arises.
we have an outputStatement function that uses destructuring to pick only those properties it needs from the object passed into the function. This keeps the app light weight, as only what is needed is used
The outputStatement function does only one thing. It outputs a statement on the screen
The UIController is a global variable that gives other modules access to only the object it returns. Thereby effectively compartmentalizing our code, exposing only what needs to be exposed.

Let us see what out data module looks like

//Data Controller
let dataController = (function(){
  let validateInput = function(strValue) {
    if (isNaN(strValue)) return false;
    return (strValue == parseInt(strValue, 10) && strValue % 1 === 0);
  }

  let narcissistic = function(strValue) {
    let base;
    let exponent;
    let start;
    let length = strValue.length;
    let sum = 0;
    if (strValue < 0) {
      base = -1;
      exponent = length - 1;
      start = 1; 
    } else {
      base = 1;
      exponent = length;
      start = 0; 
    }

    for (let i = start; i < length; i++) {
      sum += Math.pow(strValue[i], exponent)
    }

    let signedInteger = base * sum;
    return {
      isNarcissistic: (signedInteger == strValue),
      sum: signedInteger,
      exponent,
      strValue
    };
  }

  return {
    checkValidInput: function(input) {
      return validateInput(input);
    },

    checkNarcissistic: function(strValue) {
      return narcissistic(strValue);
    }
  }
})();

The data module follows the principles we applied in the UI module

Each function doing one thing only
Data controller as an IIFE exposing only what needs to be exposed

Finally, let us look at our app module...

// App controller
let controller = (function(dataCtrl, UICtrl) { 
  let { inputField, btn, displayResult } = UICtrl.getDOMstrings();
  let { getOutputStatement } = UICtrl;
  let { checkValidInput, checkNarcissistic } = dataCtrl;
  let inputFieldEl = document.getElementById(inputField);

  let setupEventListeners = function() {
    let btnEl = document.getElementById(btn);

    inputFieldEl.addEventListener("keyup", keyAction);
    btnEl.addEventListener("click", executeInput);
  }

  let keyAction = function(event) {
      event.preventDefault();
      const enterKey = 13;    
      if (event.keyCode === enterKey || event.which === enterKey) executeInput(); 
  }

  let executeInput = function() {
    let strValue = inputFieldEl.value;
    let isValidInput = checkValidInput(strValue);
    let displayResultEl = document.getElementById(displayResult);
    if (isValidInput) {
      let result = checkNarcissistic(strValue);
      displayResultEl.dataset.status = result.isNarcissistic ? "true" : "false";
      displayResultEl.innerHTML = getOutputStatement(result);
    } else {
      displayResultEl.dataset.status = "false";
      displayResultEl.innerHTML = getOutputStatement('NaN');
    }
  }

  return {
    init: function() {
      console.log('Application has started');
      setupEventListeners();
    }
  }
})(dataController, UIController);

controller.init();

The app controller is what brings it all together.

Observe that the DOM elements are assigned as narrow as possible to the scope that actually needs them. This way, when you make changes to a DOM element, you're not worried it is being used somewhere else.

Phew! And so, our final code all together looks like...

//UI Controller
let UIController = (function() {
  let DOMstrings = {
    displayResult: "displayResult",
    inputField: "inputField",
    btn: "btn"
  }

  let outputStatement = function({ isNarcissistic, strValue, exponent, sum }) {
    let sentence = `${strValue} is ${isNarcissistic ? '' : 'not'} a narcissistic value.\n 
      The sum of its own digits, each raised to the total digits count ${exponent}, is ${sum}`;

    switch(isNarcissistic) {
      case false:
        return `No, ${sentence(false)}`;
      case true:
        return `Yes, ${sentence(true)}`;
      default:
        return "Please type in an integer"
    }
  }

  return {
    getDOMstrings: function() {
      return DOMstrings;
    },
    getOutputStatement: function(value) {
      return outputStatement(value);
    }
  }
})();



//Data Controller
let dataController = (function(){
  let validateInput = function(strValue) {
    if (isNaN(strValue)) return false;
    return (strValue == parseInt(strValue, 10) && strValue % 1 === 0);
  }

  let narcissistic = function(strValue) {
    let base;
    let exponent;
    let start;
    let length = strValue.length;
    let sum = 0;
    if (strValue < 0) {
      base = -1;
      exponent = length - 1;
      start = 1; 
    } else {
      base = 1;
      exponent = length;
      start = 0; 
    }

    for (let i = start; i < length; i++) {
      sum += Math.pow(strValue[i], exponent)
    }

    let signedInteger = base * sum;
    return {
      isNarcissistic: (signedInteger == strValue),
      sum: signedInteger,
      exponent,
      strValue
    };
  }

  return {
    checkValidInput: function(input) {
      return validateInput(input);
    },

    checkNarcissistic: function(strValue) {
      return narcissistic(strValue);
    }
  }
})();



// App controller
let controller = (function(dataCtrl, UICtrl) {
  let { inputField, btn, displayResult } = UICtrl.getDOMstrings();
  let { getOutputStatement } = UICtrl;
  let { checkValidInput, checkNarcissistic } = dataCtrl;
  let inputFieldEl = document.getElementById(inputField);

  let setupEventListeners = function() {
    let btnEl = document.getElementById(btn);

    inputFieldEl.addEventListener("keyup", keyAction);
    btnEl.addEventListener("click", executeInput);
  }

  let keyAction = function(event) {
      event.preventDefault();
      const enterKey = 13;
      if (event.keyCode === enterKey || event.which === enterKey) executeInput();
  }

  let executeInput = function() {
    let strValue = inputFieldEl.value;
    let isValidInput = checkValidInput(strValue);
    let displayResultEl = document.getElementById(displayResult);
    if (isValidInput) {
      let result = checkNarcissistic(strValue);
      displayResultEl.dataset.status = result.isNarcissistic ? "true" : "false";
      displayResultEl.innerHTML = getOutputStatement(result);
    } else {
      displayResultEl.dataset.status = "false";
      displayResultEl.innerHTML = getOutputStatement('NaN');
    }
  }

  return {
    init: function() {
      console.log('Application has started');
      setupEventListeners();
    }
  }
})(dataController, UIController);

controller.init();

Observe our refactored code above...

It consumes less memory, as objects are now destructured, and functions use the property they want without having to carry the whole weight of that object. Peek at the outputStatement function definition (line 9).
It runs faster than our old code and even takes care of more edge cases, as refactoring exposed some bugs not previously seen.
There is no fear of a DOM leak (which severely hampers apps). Our rewritten callbacks do not refer to any variable outside its scope. Therefore when the callback function is done, JavaScript cleans up the memory without any reference left behind(closure).
Each function in the code does only one thing, and concerns are properly separated. Unlike the old code, now the narcissistic function only checks if it's narcissistic, and another function has the responsibility of updating the DOM. Everything is well spelt out.
Lastly, it's beautiful to read.

I do think it's beautiful to read. Thank you dear reader for coming with me through this journey. Together we have seen a code transform from Gandalf the Grey to Gandalf the White🧙. Your thoughts are very much welcome. And remember, if you have ever whispered under your breath, "For Frodo", think of me as family.🤗

You can see the full working application here
https://codepen.io/Duz/pen/oaGdmG