Forem: Umer K

This JavaScript feature FAILED miserably, and no one knows about it

Umer K — Tue, 08 Oct 2019 14:14:19 +0000

Any person who is even mildly experienced with JavaScript has used Object literals. Object literals are a great way to encapsulate information. This is how they work

let person = {
    name: 'Umer',
    interests: ['javascript', 'webdev']
}

This is a very neat and useful fundamental feature of JavaScript (and other languages) but it can get messy. You may have chains of object literals, and having to refer to them in code can be a pain.
This is an example from a project that simulates light behaviours

    updateLines(obj) {
        for(let i = 0; i < obj.vertices.length; i++) {
            let dx = obj.vertices[(i + 1)%obj.vertices.length][0] - obj.vertices[i][0];
            let dy = obj.vertices[(i + 1)%obj.vertices.length][1] - obj.vertices[i][1];
            obj.segments[i].pos.set(obj.vertices[i][0], obj.vertices[i][1]);
            obj.segments[i].displacement.set(dx, dy);
            obj.segments[i].dir = obj.segments[i].displacement.copy().normalize();
        }
    }

Note how many times I have had to reference the obj object. This agony makes way for the JavaScript feature that has very well failed (although this has been replaced with a cleaner concept).

with (expression) statement

According to the MDN docs, the with statement extends the scope chain for a statement. This means that if we used with (obj) in our previous example, it would have been possible for us to remove the reference to obj in our statements. This clearly makes our code cleaner and easier to manage.

updateLines(obj) {
    with(obj) {
        for(let i = 0; i < vertices.length; i++) {
            let dx = vertices[(i + 1)%vertices.length][0] - vertices[i][0];
            let dy = vertices[(i + 1)%vertices.length][1] - vertices[i][1];
            segments[i].pos.set(vertices[i][0], vertices[i][1]);
            segments[i].displacement.set(dx, dy);
            segments[i].dir = segments[i].displacement.copy().normalize();
        }
    }
}

The example I have shown is not very extreme, but you can imagine if the obj was part of an object chain, there would be a much more visible improvement in code coherence.

Do NOT use this feature

We looked at how useful this feature is, but it can cause all sorts of problems. For example it produces uncertainty when we might have a local variable by the name of, say, 'length'. If we used the with statement with an object that owns a property by the same name (length), we have a problem. You can read in more detail about the problems this feature can cause here

It is due to these reasons that this feature is now deprecated and is not recommended for use in any code.

ES6 to the rescue

ES6 introduces a very much cleaner way to achieve similar functionality but without the same troubles. This feature is known as object destructuring, and we use this in modern JavaScript to fetch properties from inside of objects into local or global scopes. This feature has many more use cases, and is much more complex (read here), but we will discuss a simpler example here.
This code snippet is from my Live Interactive Drawing Board application

    const { name, email, password } = req.body;
    if (!name || !password || !email) {
        return res.status(400).json({ msg: "Kindly fill all the required fields" });
    }

This is some very basic server side code, in nodejs. We pull out three properties from the req.body object by using curly braces in our declaration, and equating this to our object. The code then checks to see if all the items have been provided, and if not, this sends a Bad Request Response to the client.

Now you know about the JavaScript feature that failed, even after it had become a part of the specification. If you found this article useful, dropping a love react would make me happy. If you found some flaw in this article, please let me know in the comments below.
For articles and rants relating to JavaScript and Web Development, you may want to consider following me.

Here are Top 5 Best Practices for JavaScript you MUST ALWAYS FOLLOW

Umer K — Wed, 25 Sep 2019 13:56:27 +0000

JavaScript is one of the most flexible and lenient programming languages out there, compared to the likes of Java or C++ which have much stricter rules. This means that often we encounter unexpected behaviour, even when we are writing the same code that we have written and tested before. As programmers, we do not like anything unexpected (except for of course, Math.random(). We all love Math.random()!) and so we strive to minimise these 'wrong' ways of writing code, that may or may not work at any point in time.

This article is intended for audiences with limited experience of JavaScript, and limited understanding of the language. I will be regularly posting articles both for relatively new JavaScript programmers and more advanced articles for experienced programmers. If you code in JavaScript, you might want to follow me.

1) Avoid Global Scope wherever possible

It is from personal experience that I am telling you this - global scopes are ALWAYS a pain to work with. Generally, you bundle JavaScript files by putting them in an html file using the <script> tag. This means that it is as if all these files were written together inside one single file, unless you use modules or some next generation tool like Babel.
There are many examples, many of which are complex to understand the importance of, but I'll try my best for this simple scenario.
Imagine you wanted to store some data for a canvas sketch, and you do it like this:

let canvasWidth = 5;
let canvasHeight = 67;
let canvasMousePos = { x: 9, y: 6 };

This could be fine, but then when you want to add more properties for your canvas, you will pollute the global namespace even more. We use Object literals for this purpose. It is generally bad practice to store ANY similar data in separate global namespaces, which is also very good for when you need to expand. The following code shows a better way, and shows also for when you might want to include two canvases with different properties in the future.

let mycanvas = { width: 5, height: 67, mouse: { pos: { x: 9, y: 6 } } };
let myothercanvas = { author: 'John', width: 50, height: 107, mouse: { pos: { x: 9, y: 6, z: 89 } } };

If you were paying attention, you might suggest using an Array to store these two canvases to further remove pollution of the global scope, which is exactly what you should do. At a certain point, you might want to start solving these problems with Object Oriented Programming.

2) Do not omit Semi Colons

A feature that many new and amateur developers love about JavaScript is the fact that in most cases, semicolons ( ; ) are optional and the code runs without them. This feature is known as Automatic Semicolon Insertion. However, using this feature is not recommended and you should include any due semicolons as this can result in unexpected behaviour. Semi colons are also crucial for better readability.

3) JavaScript Array Methods

We store lists in arrays and generally this is so that at some point in our code we will iterate over them, or do some sequential manipulation of this data. Array methods are really useful here.
Imagine I have an array of users each of whom has a name and some other properties associated with it. If I wanted only the names of these users I could make a new array, loop over the original array and push items into this new array like the first snippet, or we could just use the map method on our array.

    const users = [{ name: 'John', age: 87, post: 'high' }, { name: 'Doe', age: 43, post: 'low' }];
    const names = [];
    for(let i = 0; i < users.length; i++) {
        names.push(users[i].name);
    }
    // alternatively, in one line
    const names = users.map(user => user.name); //["John", "Doe"]

For a list of all array methods and their use cases, click here

4) Reusing any piece of code? Make it a function

How often does it happen that you write some functionality but have to use it again at some other place? I guess very often is the answer for everyone. Whenever you see yourself reusing a piece of code, even if it is just two times, make it into a function. This will mean that if you want to change how that code works in the future (and trust me this will always happen), you will only need to change this in one place instead of 23 places inside 5 JavaScript files.

5) Make your code concise wherever possible

JavaScript code allows flexibility in syntax. So much so that it is possible to make code blocks very concise by omitting redundant parts of the syntax, without breaking recommended patterns. For example the following omits curly braces where they are redundant.

if (this.isHungry()) this.stroll()
else if (inPerception.length <= 2) this.stroll(() => this.inPerception > 2);
else {
    this.cohesion(inPerception, cohesionPriority / 100);
    const colliding = peerTree.retrieveFromRadius(pos.x, pos.y, r, this.isOfTypeSelf);
    this.seperate(colliding, seperationPriority / 100);
}

*This code is from a project that Simulates Evolution in Intelligent Autonomous Agents
This feature must be used with extreme caution and only where statements succeeding expressions are singular. Generally only include curly braces where you have to encapsulate more than one statement, otherwise, omit them for better readability and less redundancy.

Conclusion

You might have noticed that I have given particular importance to the fact that code should be easy to expand upon in the future, and it should be neat to look at and comprehend for anyone (not just you). This is one of the key concepts programmers follow. If you have more tips for new programmers, leave them in the comments below.
If you have read this far, you should be tempted to leave a love react and see how happy that makes both of us ;)

Want to write future safe code for the future web? Let me help you with Web Components

Umer K — Mon, 23 Sep 2019 15:04:34 +0000

Whether you smell this or not, things are changing for good.
Web Components is a suite of different technologies allowing you to create reusable custom elements — with their functionality encapsulated away from the rest of your code — and utilise them in your web apps
These are a specification of the W3 Consortium, and are a standard across all browsers (or are at least promised as such). This technology means that there might soon no longer be any need to rely on third party frameworks (you only need to rely on relevant tools for now), install bloat, or learn for months on end, to make a seemingly basic modern web application. If you want to write code for the future web right now, i.e where the buzz-following herd of web developers will be in, say, 2 or 3 years, this is the right technology for you. This article will help you get started.

You may ask why you should ditch the cool React, and the swag-ful Angular, and Vue 😎 and the rest of this post aims to explains this.

The stepping stones into developing applications for the web, or even static sites to some extent, have for very long been frameworks. You maybe spend two days trying to learn HTML when you get thrown at yourself words like "React", "Angular" or "Vue." This means that learning HTML(&CSS) and JavaScript is not enough to effectively write even beginner level applications.

You need to install some package manager like npm, go through some command line hell, (and assuming you are learning react, lets say) install create-react-app, run create-react-app, which will take a half hour or more even if your machine is above average (hard disks, ugh).
This is the easiest path and right now, you have not done anything. This here is just scaffolding for your code. Now you need more boilerplate react code, and alas, you need also Redux, and also 20 react libraries for that one animation (which is taken for granted in modern day web), and more... You need to make the choice between hooks and class based React (which does not mean anything to you, who just learnt about setTimeout last weak). Well it does not stop here, the hell that is, but you get the idea.

This is not the way writing code should work. If all frameworks out there ultimately aim to achieve the same fundamental functionality, and your client is using pretty much the same browser and the very same Internet, why is there not a standard way, which is common, and which we teach developers to build their applications, unless their project demands an exclusive, high level, opinionated framework, suited for their specific needs. If JavaScript Web frameworks right now pretty much do the same thing for me and you: normal, sane developers, looking to build web applications of the same sort of which millions already exist, why not? Why not future safe, non-isolated, plug and play?

(Please do not write bullets about how these buzz frameworks are different, they are not for me. They are not for my friend who wants to get into webdev, they are not for that comp sci graduate, they are different for you, a 25 year old JS developer, because Angular uses a two-directional data flow process where it updates the Real DOM directly while React updates only the Virtual DOM and abracadabra alakazam hocus pocus)

My point is that if you are a developer of the web, who is adequately skilled with JavaScript and some of the tools, you should switch your energy to the new standard: Web Components. Maybe not at this low level directly, but maybe try lit-html and Lit Element which are both very elegant solutions to reach framework-like functionality with minimal desire to bump your head on a wall. The article I linked above should be adequate.