Select Page

Category: Link

Understanding React Render Props and HOC

Here’s a great post by Aditya Agarwal on the difference between render props and higher-order components in React. I particularly like the demo he chose to explain the two. But, to summarize: Higher-order components (HOCs) take a component and return a component. So let’s say you have a component called Username that just returns a string of a user’s name and you want to capitalize that somewhere – this is the perfect opportunity to use a HOC that wraps that Username component and changes each character. Just like the excellent tutorial Kingsley Silas wrote up here on CSS-Tricks. HOCs are particularly useful for when you want to modify a component and then use it in a bunch of places, or to make tiny batches of code to prevent overwhelming a component with too many options and props. A render prop on the other hand is “a function prop that a component uses to know what to render.” At least, that’s what the React docs say, but it took me a while to figure it out. As far as I understand, it lets you provide a way for a React component (typically one that just has a bunch of data you want to reuse) and give it to another (so a component that then renders that data). here’s a great example of this in the React docs: class MouseTracker extends...

Read More

Emphasizing Emphasis

I think Facundo Corradini is right here in calling out our tweet. If you’re italicizing text because it should be styled that way (e.g. using italics to display a person’s internal thought dialog, as illustrated in our example), then that’s an and not an , because is for stress emphasis — as in, a word you would emphasize with your voice, if spoken, to affect meaning. Plus, I’m always down for long-form articles about the nuances of a handful of HTML elements! Direct Link to Article — Permalink The post Emphasizing Emphasis appeared first on CSS-Tricks....

Read More

The Three Types of Performance Testing

We’ve been covering performance quite a bit — not just recently, but throughout the course of the year. Now, Harry Roberts weighs in by identifying three types of ways performance can be tested. Of particular note is the first type of testing: The first kind of testing a team should carry out is Proactive testing: this is very intentional and deliberate, and is an active attempt to identify performance issues. This takes the form of developers assessing the performance impact of every piece of work they do as they’re doing it. The idea here is that we spot the problem before it becomes problematic. Prevention, after all, is cheaper than the cure. Capturing performance issues at this stage is much more preferable to spotting them after they’ve gone live. I think about this type of performance all the time when I’m working on a team, although I’ve never had a name for it. I guess what I’m always thinking about is how can we introduce front-end engineers into the design process as early as possible? I’ve found that the final product is much more performant in when front-end engineers and designers brainstorm solutions together. Perhaps collaborating on a performance checklist is a good place to start? Direct Link to Article — Permalink The post The Three Types of Performance Testing appeared first on CSS-Tricks....

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

Understanding the difference between grid-template and grid-auto

Ire Aderinokun: Within a grid container, there are grid cells. Any cell positioned and sized using the grid-template-* properties forms part of the explicit grid. Any grid cell that is not positioned/sized using this property forms part of the implicit grid instead. Understanding explicit grids and implicit grids is powerful. This is my quicky take: Explicit: you define a grid and place items exactly where you want them to go. Implicit: you define a grid and let items fall into it as they can. Grids can be both! Direct Link to Article — Permalink The post Understanding the difference between grid-template and grid-auto appeared first on CSS-Tricks....

Read More
www.000webhost.com