The front-end space over the last six years or so has really heated up, you could say superheated. As browsers become more powerful, devices continually improved and innovation a constant thing, no language is more popular and widely used than Javascript. And yet, as learning resources have become more easily accessible and coding boot camps have become a thing, newcomers are being taught to lean on frameworks and libraries straight out of the gate.
Staunch functional proponents will fire up at the mere mention of classes or any form of object-oriented programming. These arguments go way back to before Javascript was even a thing or as popular as it is now. Let’s clear the air and point out that classes in Javascript are not real classes. They’re often compared to the likes of Java and other languages that promote OOP-style programming, but classes in JS are unlike those implementations. Javascript has prototypes and prototypes are not classes.
If you are writing tests using Jest and you use TypeScript, there is a good chance you have encountered an error along the lines of TypeError: defaultsDeep_1.default is not a function or TypeError: myClass.default is not a constructor when trying to test a file that is using a default import from a module. You most likely have read countless StackOverflow questions, but none of the solutions will solve the issue. You’ve read the Jest documentation (which is quite extensive), but still no mention of mocking default module imports with TypeScript.
As ubiquitous as state management has become in front-end development, it is still a confusing magical black box to most developers. Data goes in, data goes out, and nobody thinks about what happens in-between. Some developers believe the answer to the question in my title is: always. While some don’t believe in using state management at all and if you’re like me, the answer is: it depends. When state management gets added to an application that meets the criteria for using it, a weight gets lifted off your shoulders, and things make sense. Prematurely introduce state management or use it in places where you shouldn’t, and your life becomes a tangled mess.
Hello humans. In JavaScript, the worlds most loved and internets favourite client-side language, thanks to modern ECMAScript standards, we have default and named exports. It’s simple, and you have a file that exports something to be imported somewhere else. A named export is explicit and is only importable by its defined name. A default export is implicit, and you can import it and call it whatever you like. Now, default exports came about in the CommonJS world of Node.js where you would import a module using const MyModule = require('my-module') to account for uses where exports are default module.exports = MyClass – although, it is worth pointing out that CommonJS does support named exports.
Recently, I published a blog title which I titled, The State of JS Survey Is A Farce in which I expressed criticism that the State of JS survey is highly inaccurate, biased and dangerous. I didn’t get a roaring response until a developer who is one of three running the survey Sasha Greif out of nowhere expressed feelings that I was unkind in my blog post in a Tweet that tagged me. @AbolitionOf calling the State of JS a “farce” was pretty unkind. I hope you get better treatment if you ever launch your own projects
The State of JS is a survey that has been running for a few years now, which surveys front-end developers and aims to find out what they’re using, what they love, what they’re interested in learning and what they’re not interested in knowing. The survey sounds good in theory, it gives you insight into the state of front-end development and the various tools, libraries and frameworks people are using. In practice, the survey is a farce. The 2018 version of the survey saw over 20,000 respondents complete the survey. While 20,000 respondents seem quite low given the number of developers out there who identify as front-end or Javascript developers, the actual issue here is the data, in this case, is biased. When you use biased data, you get a biased result.
For years, I wanted the ability to use variables as object keys in Javascript. Thanks to ES2015, we got the ability to have computed object keys from within the object definition itself. This isn’t a new or cutting-edge addition, we’ve had it in Javascript for a while now and it is well-supported. The reason for talking about them is a lot of developers do not know about these features or simply forget about them.
Recently, whilst working on a project I needed to take HTML FormData and then convert it to JSON to be sent off to an API. By default the FormData object does not work in the way you would want it to for JSON. Using the for..of syntax introduced in ECMAScript 2015, we can access the form data entries and iterate over them to get key and value pairs. This will be the verbose solution, scroll to the bottom to get the cleaner solution using .reduce below.
Most of the time when you’re looping over an array of elements, you’ll do it sequentially. However, I recently needed to iterate through an array of objects in reverse just using a plain old for loop. This will not be a highly informative or groundbreaking post but, I thought I’d share this in case someone wants to solve the same problem and might be confused with the many different ways you can loop over an array in reverse.