Goals: Add links that are reasonable and good explanations of how stuff works. No hype and no vendor content if possible. Practical first-hand accounts of models in prod eagerly sought.
import * as React from "react"; | |
import { useMousePosition } from "~/hooks/useMousePosition"; | |
/** Component to cover the area between the mouse cursor and the sub-menu, to allow moving cursor to lower parts of sub-menu without the sub-menu disappearing. */ | |
export function MouseSafeArea(props: { parentRef: React.RefObject<HTMLDivElement> }) { | |
const { x = 0, y = 0, height: h = 0, width: w = 0 } = props.parentRef.current?.getBoundingClientRect() || {}; | |
const [mouseX, mouseY] = useMousePosition(); | |
const positions = { x, y, h, w, mouseX, mouseY }; | |
return ( | |
<div |
/* | |
Copy this into the console of any web page that is interactive and doesn't | |
do hard reloads. You will hear your DOM changes as different pitches of | |
audio. | |
I have found this interesting for debugging, but also fun to hear web pages | |
render like UIs do in movies. | |
*/ | |
const audioCtx = new (window.AudioContext || window.webkitAudioContext)() |
This week NN Group released a video by Jakob Nielsen in which he attempts to help designers deal with the problem of customers being resistant to their new site/product redesign. The argument goes thusly:
- Humans naturally resist change
- Your change is for the better
- Customers should just get used to it and stop complaining
There's slightly more to it than that, he caveats his argument with requiring you to have of course followed their best practices on product design, and allows for a period of customers being able to elect to continue to use the old site, although he says this is obviously only a temporary solution as you don't want to support both.
function gmailAutoarchive() { | |
var threads = GmailApp.search("in:inbox label:auto-archive older_than:2d"); | |
Logger.log("found " + threads.length + " threads:"); | |
for(var i = 0; i < threads.length; i++) { | |
var thread = threads[i]; | |
Logger.log((i+1) + ". " + thread.getFirstMessageSubject()); | |
} | |
var batch_size = 100; |
// 🔥 Node 7.6 has async/await! Here is a quick run down on how async/await works | |
const axios = require('axios'); // promised based requests - like fetch() | |
function getCoffee() { | |
return new Promise(resolve => { | |
setTimeout(() => resolve('☕'), 2000); // it takes 2 seconds to make coffee | |
}); | |
} |
https://gist.github.com/ljharb/58faf1cfcb4e6808f74aae4ef7944cff
While attempting to explain JavaScript's reduce
method on arrays, conceptually, I came up with the following - hopefully it's helpful; happy to tweak it if anyone has suggestions.
JavaScript Arrays have lots of built in methods on their prototype. Some of them mutate - ie, they change the underlying array in-place. Luckily, most of them do not - they instead return an entirely distinct array. Since arrays are conceptually a contiguous list of items, it helps code clarity and maintainability a lot to be able to operate on them in a "functional" way. (I'll also insist on referring to an array as a "list" - although in some languages, List
is a native data type, in JS and this post, I'm referring to the concept. Everywhere I use the word "list" you can assume I'm talking about a JS Array) This means, to perform a single operation on the list as a whole ("atomically"), and to return a new list - thus making it mu
Recently CSS has got a lot of negativity. But I would like to defend it and show, that with good naming convention CSS works pretty well.
My 3 developers team has just developed React.js application with 7668
lines of CSS (and just 2 !important
).
During one year of development we had 0 issues with CSS. No refactoring typos, no style leaks, no performance problems, possibly, it is the most stable part of our application.
Here are main principles we use to write CSS for modern (IE11+) browsers:
- SUIT CSS naming conventions + SUIT CSS design principles;
- PostCSS + CSSNext. Future CSS syntax like variables, nesting, and autoprefixer are good enough;
- Flexbox is awesome. No need for grid framework;
- Normalize.css, base styles and variables are solid foundation for all components;
#!/bin/sh | |
command="${*}" | |
printf "Initialized REPL for `%s`\n" "$command" | |
printf "%s> " "$command" | |
read -r input | |
while [ "$input" != "" ]; | |
do | |
eval "$command $input" | |
printf "%s> " "$command" |
import React from 'react'; | |
import PropTypes from 'prop-types'; | |
import classNames from 'classnames'; | |
const ANIMATION_DURATION = 1000; | |
class BatchDropZone extends React.Component { | |
static propTypes = { |