Select Page

Category: JavaScript

Styling Based on Scroll Position

Rik Schennink documents a system for being able to write CSS selectors that style a page when it has scrolled to a certain point. If you’re like me, you’re already on the lookout for document.addEventListener('scroll' ... and being terrified about performance. Rik gets to that right away by both debouncing the function as well as marking the event as passive. The end result is a data-scroll attribute on the element that can be used in the CSS. Meaning if you’re scrolled to 640px down the page, you have and could write a selector like: html:not([data-scroll='0']) { body { padding-top: 3em; } header { position: fixed; } } See the Pen Writing Dumb JS 🧟‍♂️ and Smart CSS 👩‍🔬 by Rik Schennink (@rikschennink) on CodePen. Unfortunately, we don’t have greater than (>) less than (<) selectors in CSS for things like numbered attributes, so the CSS styling potential is fairly limited here. You might ultimately need to update the JavaScript function such that it applies other classes or data attributes based on your math. But you’ll already be set up for good performance here. “Apply styles when the user has scrolled away from the top” is a legit use case. It makes me think of a once function (like we have in jQuery) where any scroll event would only be triggered once and then not again. They scrolled! So, by...

Read More

A Funny Thing Happened on the Way to the JavaScript

Around this time last year, I wrote an article about the JavaScript learning landscape. Within that article, you’ll find my grand plans to learn JavaScript — complete with a link to a CodePen Collection I started for tracking my progress, and it even got dozens of comments cheering me on. Like most people, I was ambitious. It was a new year and I was excited to tackle a long-standing project. It was my development version of losing 30 pounds (which I also need to do). But, if you follow that link to the CodePen Collection, you’ll see that there’s...

Read More

A Bunch of Options for Looping Over querySelectorAll NodeLists

A common need when writing vanilla JavaScript is to find a selection of elements in the DOM and loop over them. For example, finding instances of a button and attaching a click handler to them. const buttons = document.querySelectorAll(".js-do-thing"); // There could be any number of these! // I need to loop over them and attach a click handler. There are SO MANY ways to go about it. Let’s go through them. forEach forEach is normally for arrays, and interestingly, what comes back from querySelectorAll is not an array but a NodeList. Fortunately, most modern browsers support using forEach on NodeLists anyway. buttons.forEach((button) => { button.addEventListener('click', () => { console.log("forEach worked"); }); }); If you’re worried that forEach might not work on your NodeList, you could spread it into an array first: [...buttons].forEach((button) => { button.addEventListener('click', () => { console.log("spread forEach worked"); }); }); But I’m not actually sure if that helps anything since it seems a bit unlikely there are browsers that support spreads but not forEach on NodeLists. Maybe it gets weird when transpiling gets involved, though I dunno. Either way, spreading is nice in case you want to use anything else array-specific, like .map(), .filter(), or .reduce(). A slightly older method is to jack into the array’s natural forEach with this little hack: [].forEach.call(buttons, (button) => { button.addEventListener('click', () => { console.log("array forEach worked"); }); });...

Read More

Demystifying JavaScript Testing

Many people have messaged me, confused about where to get started with testing. Just like everything else in software, we work hard to build abstractions to make our jobs easier. But that amount of abstraction evolves over time, until the only ones who really understand it are the ones who built the abstraction in the first place. Everyone else is left with taking the terms, APIs, and tools at face value and struggling to make things work. One thing I believe about abstraction in code is that the abstraction is not magic — it’s code. Another I thing I...

Read More

How to stop using console.log() and start using your browser’s debugger

Whenever I see someone really effectively debug JavaScript in the browser, they use the DevTools tooling to do it. Setting breakpoints and hopping over them and such. That, as opposed to sprinkling console.log() (and friends) statements all around your code. Parag Zaveri wrote about the transition and it has clearly resonated with lots of folks! (7.5k claps on Medium as I write). I know I have hangups about it… Part of debugging is not just inspecting code once as-is; it’s inspecting stuff, making changes and then continuing to debug. If I spend a bunch of time setting up breakpoints, will they still be there after I’ve changed my code and refreshed? Answer: DevTools appears to do a pretty good job with that. Looking at the console to see some output is one thing, but mucking about in the Sources panel is another. My code there might be transpiled, combined, and not quite look like my authored code, making things harder to find. Plus it’s a bit cramped in there, visually. But yet! It’s so powerful. Setting a breakpoint (just by clicking a line number) means that I don’t have to litter my own code with extra junk, nor do I have to choose what to log. Every variable in local and global scope is available for me to look at that breakpoint. I learned in Parag’s article that you...

Read More
www.000webhost.com