The TypeScript team has unveiled the beta version of TypeScript 5.6, and it’s brimming with features designed to make our lives easier.
Catching Logical Errors Early: Disallowed Nullish and Truthy Checks One of the standout features in TypeScript 5.6 is the stricter handling of nullish and truthy checks. Previously, TypeScript would quietly accept certain logical errors, leading to potential bugs that were hard to catch. Now, the compiler flags expressions that always evaluate to a specific boolean value, such as:
Look, we’ve all been there. You’re knee-deep in JavaScript code and suddenly have this brilliant idea: “If I just tweak this bit here, surely it’ll run faster!” Before you know it, you’re down a rabbit hole of micro-optimisations, convinced you’re crafting the most efficient code known to humankind.
The Optimisation Itch
It’s tempting. The thought that with just a few clever tricks, you can make your code zoom along at lightning speed. But here’s the kicker: more often than not, these early optimisation efforts are a bit like rearranging deck chairs on the Titanic. They might make you feel productive, but they’re not addressing the real issues. Because if you haven’t even built your app yet, what are you optimising?
In this blog post, we’ll explore the concept of deep observation in TypeScript and learn how to create a deep observer using proxies. Deep observation allows you to track changes made to an object, including its nested properties, providing a powerful way to monitor and react to modifications in your data structures.
Understanding Deep Observation Deep observation involves monitoring changes made to an object and its nested properties. When a property is modified, whether it’s a top-level property or a deeply nested one, you can capture and respond to those changes. This is particularly useful when working with complex data structures where changes can occur at various levels of nesting.
JavaScript has been around for over 25 years, yet it’s more popular and dominant than ever. Some love to hate it, others grudgingly put up with it, but let’s cut through the bullshit – JavaScript has firmly cemented itself as the one true king of programming languages. And its reign looks set to continue for a long time yet.
First, there’s the ubiquity. JavaScript is fucking EVERYWHERE. It runs in every browser on every device. It’s the default language of the web. And with Node.js, it’s busted out of the browser to conquer the server side, too. You can’t swing a cat without hitting some JavaScript. It’s like the Starbucks of programming – inescapable but also weirdly comforting in its consistency.
In the vast, evolving landscape of JavaScript, there’s a feature that stands out for its versatility and power yet remains underappreciated by many developers: JavaScript proxies. Like the chameleons of the coding world, proxies offer the ability to intercept and customize fundamental operations on objects and arrays. Today, we’re diving deep into how proxies can transform your approach to JavaScript programming, with practical examples that illuminate their potential.
What Are JavaScript Proxies? Introduced in ECMAScript 2015 (ES6), proxies are a metaprogramming feature allowing developers to create a proxy for another object. This proxy can intercept and redefine fundamental operations such as property lookup, assignment, and function invocation. Imagine having a personal assistant who can filter your calls, handle requests on your behalf, and notify you only when necessary; that’s what proxies do for your objects and arrays in JavaScript.
I hate to be “that guy” that publishes a blog post and says, “Stop using X” and “Why you should be using X instead”, but after a recent situation in some code I wrote ages ago and updated, I felt it was worthy writing a blog post about why you should use globalThis instead. That’s not to say if you’re currently using window that you’re wrong (because globalThis aliases window in a browser context). However, by using globalThis, you can save yourself a lot of trouble, especially in unit tests.
Sentiment analysis is usually a task that requires a specialised dataset and machine-learning techniques to implement properly. However, I thought it might be a nice exercise to try and implement sentiment analysis with TypeScript without training models.
// Define a type for the sentiment result type Sentiment = 'positive' | 'neutral' | 'negative'; // Class to perform sentiment analysis on a given text class SentimentAnalysis { // Arrays of positive and negative words to use in the analysis private positiveWords = ["love", "like", "great", "good", "happy", "awesome"]; private negativeWords = ["hate", "dislike", "bad", "angry", "sad", "terrible"]; // Method to perform sentiment analysis on a given text public getSentiment(text: string): { sentiment: Sentiment, positiveWords: number, negativeWords: number, neutralWords: number } { // Convert the text to lowercase to make the analysis case-insensitive const lowerText = text.toLowerCase(); // Sum up the number of times each positive word appears in the text let positiveScore = this.positiveWords.reduce((acc, word) => { // Use a regular expression to match the word in the text return acc + (lowerText.match(new RegExp(word, 'g')) || []).length; }, 0); // Sum up the number of times each negative word appears in the text let negativeScore = this.negativeWords.reduce((acc, word) => { // Use a regular expression to match the word in the text return acc + (lowerText.match(new RegExp(word, 'g')) || []).length; }, 0); // Calculate the number of neutral words by subtracting the positive and negative words from the total number of words let neutralScore = lowerText.split(' ').length - positiveScore - negativeScore; // Compare the number of positive and negative words and return the sentiment result if (positiveScore > negativeScore) { return { sentiment: "positive", positiveWords: positiveScore, negativeWords: negativeScore, neutralWords: neutralScore }; } else if (positiveScore < negativeScore) { return { sentiment: "negative", positiveWords: positiveScore, negativeWords: negativeScore, neutralWords: neutralScore }; } else { return { sentiment: "neutral", positiveWords: positiveScore, negativeWords: negativeScore, neutralWords: neutralScore }; } } } // Create an instance of the SentimentAnalysis class const sentimentAnalysis = new SentimentAnalysis(); // Analyze some sample text const result = sentimentAnalysis.getSentiment("I love this code and think it is great!"); // Log the result console.log(result); This code uses a class called SentimentAnalysis to perform sentiment analysis on a given text. The class has two arrays of positive and negative words and a method called getSentiment that performs the analysis.
The Fetch API is a modern and efficient way to retrieve resources from a server. It is an interface that provides a unified way to fetch resources from different sources. Fetch makes sending HTTP requests, including GET and POST, easy and handles responses asynchronously.
However, handling errors properly is important when working with the Fetch API. Errors can occur for various reasons, such as a network error, a server-side error, or an invalid URL. Failing to handle these errors can result in unexpected behaviour and break your application.
I have never understood why FizzBuzz was deemed a means of screening developers. The idea is for multiples of 3; you print Fizz. For multiples of 5, you print Buzz, and for multiples of 3 and 5 (15), you print FizzBuzz.
While this kind of prescreening question might have worked 15 years ago when information wasn’t as accessible as it is now (smartphones, smartwatches. etc.), it seems strange that some companies still ask developers how to write FizzBuzz.
If you have been a reader of my blog for a while, you would know that I am an avid cryptocurrency enthusiast. I believe in the tech more so than the financial side. I find blockchains fascinating because, despite their perceived complexity, you can implement a blockchain in any programming language; Javascript included.
I thought it would be fun to create a blockchain using TypeScript and then iteratively change the code to offer more flexibility, such as the ability to add metadata into the blocks and query the blocks themselves.