The popularity of React is undeniable. When bright-eyed developers think about creating a new app, React is usually the first thing that crosses their minds. React has all become the defacto front-end library of choice.
React is comfortable. React is familiar. React is used by almost everyone. React is the library you learn if you want to make yourself an employable front-end developer.
The truth is, front-end developers have painted themselves into a corner with React. To understand why React became so popular, we have to go back to 2013, when React first made its grand debut. AngularJS was the dominant and most popular option for web applications at the time, and boy did AngularJS suck.
Some of you probably already knew this, but I only recently discovered this (accidentally) while building a wrapper around Postgresql queries in Node, and my mind is blown, to be honest.
Calling toString() on an array will automatically return the values within as a comma-separated string. Best of all, there will be no hanging comma and all whitespace is removed. Implementations based on join will have a space between the items, toString() on the array itself will not.
I was recently tasked with implementing pagination for an array of values (in some instances, over 2400 of them) and instead of using an existing library, I opted to write my own pagination logic and put it into an Aurelia value converter.
There are a lot of ways you can achieve this, you can use slice, you can use filter and reduce as well. The solution I ended up coming up with uses slice because it produces the easiest to read and simple code. Performance-wise, I do believe that filter comes out on top, but that isn’t our concern here.
I had a rather interesting use-case recently where I needed to take the contents of an HTML dropdown on a website which had timezones and then convert it into an object. But, I’ve been there before. How many times have you wanted a country dropdown or age dropdown and just wanted to copy one from an existing website?
I just opted for a simple for..loop in this case.
// Query the dom for all option elements inside of the select dropdown called timezone const options = document.querySelectorAll('#timezone option'); const obj = {}; for (const option of options) { obj.label = option.textContent.trim(); obj.value = option.value; } I then use textContent to get the label from the option, and then I call trim to ensure that any whitespace doesn’t get copied over to my object. I call option.value to get the value. But, here is the thing… If you’re taking this data with the intention of iterating over it later on, you probably want it to be an iterable type such as an array or even a map.
Well, here is an announcement that probably won’t surprise anyone who has used Moment in the last few years, especially trying to get the size of it down in your Webpack configuration. The Moment.js team has announced it is now a legacy project in maintenance mode.
It is not dead, but it is indeed done.
The Moment team poetically declares, “We now generally consider Moment to be a legacy project in maintenance mode. It is not dead, but it is indeed done.” Which means, we’ll fix any serious issues (security concerns, etc) but new features or changes are off the table.
For a while now, Microsoft has demoed and spoken about their highly hyped WebAssembly framework that aims to blur the lines between front and back-end programming.
If you are a .NET developer or just like to keep your finger on the pulse when it comes to new frameworks and web tech, you have most likely heard of Blazor. If not, you can keep reading and just smile and nod so people don’t find out you’re behind the times.
I see a lot of questionable blog posts and articles out there about Javascript. And, I should know, I have written some of them myself in the ten years I’ve been blogging on this site.
However, over the last few years since the rise of Medium and Dev.to, I have noticed a few articles (I won’t link or name any) which go along the lines of this:
Stop Using For Loops and Use map, filter and reduce instead
At work recently, I had a use-case where I needed to show a preview of some HTML dynamically sent from the server inside of an iFrame.
It is quite possible before you found this blog post, you found a solution that looked something like this:
iframe.src = 'data:text/html;charset=utf-8,' + encodeURI(html); This will work for simple HTML and instances where the HTML isn’t overly long. But, if your use-case is like mine, the HTML the server is returning is massive. In my case, I had base64 encoded images making the returned HTML huge.
I had to implement some testing logic recently where I wanted to wait for a heavy page to load and for specific elements to become available. I knew I wanted a function that polled the page and returned true if it found the element or rejected if it didn’t.
I actually looked some a pre existing solution and turned up a blank. There are code examples out there, but some developers have created some over engineered solutions using things like proxies, mutation observers and other convoluted ways of waiting for elements.
Some developers are still new to async/await in Javascript. If you’re used to callbacks or using .then to get the value of a promise, async/await can be a bit of a black box, especially when it comes to errors.
The most straightforward and recommended way to handle errors is using try/catch. This will allow you to catch errors if your async function rejects or throws an error.
async function getProducts() { try { const response = await fetch('/products'); const products = await response.json(); } catch(err) { console.error(err); } } If you had a function which handles API requests, you could do something like this: