ryanflorence

function useIsPendingPathname(to) {
  let { location } = useTransition();
  let { pathname } = useResolvedPath(to);
  return location?.pathname === pathname;
}

function useIsSlowTransition(ms = 300) {
  let transition = useTransition();
  let [isSlow, setIsSlow] = useState(false);

keleshev

function verboseRegExp(input) {
  if (input.raw.length !== 1) {
    throw Error('verboseRegExp: interpolation is not supported');
  }

  let source = input.raw[0];
  let regexp = /(?<!\\)\s|[/][/].*|[/][*][\s\S]*[*][/]/g;
  let result = source.replace(regexp, '');

bvaughn

function setFocusIfFocusable(node) {
  if (node.nodeType !== Node.ELEMENT_NODE) {
    // Text and comment nodes aren't focusable.
    return false;
  }

  if (node.disabled === true) {
    // Disabled elements can't be focused.
    return false;
  }

brainysmurf

Concurrency in Google AppsScripts (V8)

Steps to reproduce

• Run useForLoop independently, and observe it takes about 7 seconds to complete
• Run entrypoint which calls useForLoop three times, asynchronously
• Observe that the second run takes at least three times as long as the first run to complete
• Repeat the process above but in a browser, and observe the expected behaviour

Conclusion: Even though the documentation indicates that you can define async functions, and that you can make Promises, it ain't actually async.

emmabostian

{
  "React Stateless Functional Component": {
    "prefix": "rfac",
    "body": [
      "import React from 'react'",
      "",
      "const $TM_FILENAME_BASE = () => { ",
      "\treturn (",
      "\t\t<div>",
      "",

kopiro

set myChannels to {"random"} # Populate this field

set theResponse to display dialog "What's your message?" default answer "" with icon note buttons {"Cancel", "Continue"} default button "Continue"
set theMessage to text returned of theResponse

tell application "Slack"
	activate
	tell application "System Events"
		
		repeat with theChannel in myChannels

sebmarkbage

I heard some points of criticism to how React deals with reactivity and it's focus on "purity". It's interesting because there are really two approaches evolving. There's a mutable + change tracking approach and there's an immutability + referential equality testing approach. It's difficult to mix and match them when you build new features on top. So that's why React has been pushing a bit harder on immutability lately to be able to build on top of it. Both have various tradeoffs but others are doing good research in other areas, so we've decided to focus on this direction and see where it leads us.

I did want to address a few points that I didn't see get enough consideration around the tradeoffs. So here's a small brain dump.

"Compiled output results in smaller apps" - E.g. Svelte apps start smaller but the compiler output is 3-4x larger per component than the equivalent VDOM approach. This is mostly due to the code that is usually shared in the VDOM "VM" needs to be inlined into each component. The tr

sophiebits

const {useCallback, useEffect, useReducer, useRef} = require('react');

let effectCapture = null;

exports.useReducerWithEmitEffect = function(reducer, initialArg, init) {
  let updateCounter = useRef(0);
  let wrappedReducer = useCallback(function(oldWrappedState, action) {
    effectCapture = [];
    try {
      let newState = reducer(oldWrappedState.state, action.action);

bvaughn

Chrome's profiler ("Performance tab) is very useful for measuring JavaScript performance, but what if you want to measure the performance of a custom extension?

For example, what if I would like to profile the following interaction:

---

---

quasicomputational

Being able to flush promise resolution (or rejection) in tests is really, really handy, and even essential sometimes. Jest has an open issue for this but I'm impatient.

Setting this up in userland is possible but non-trivial - an adventure, even. I'll lay out what I had to do for any future intrepid types. I'll try to explain the reasoning for all of this and have nothing be magical.

The over-all target is to do task scheduling entirely in userland so that the task queue can be synchronously run to exhaustion. This entails faking timers and swapping out the native promise implementation for one that'll use the faked timers. All of this will be assuming you're using Jest, but the general ideas are test library agnostic.

Runtime performance seems near to native, though there's significantly more transpilation to be done - first runs will be much slower. If you're seeing significant slowdowns, something's probabl