threepointone

import "isomorphic-fetch";
import https from 'https'
import fs from 'fs'

async function get(url) {
  return await (
    await fetch("https://patchstorage.com/api/alpha/" + url)
  ).json();
}

threepointone

const bypass = [
  // function names to avoid logging
];
const collapsed = [
  // function names to groupCollapsed
];

module.exports = function(babel) {
  const { types: t } = babel;
  const wrapFunctionBody = babel.template(`{

threepointone

settled

Stealing an idea from ember's settled test helper.

Assuming these conditions are true in your unit tests -

• you're using Jest
• and Jest's fake timers
• and all your data requests are happening via fetch

threepointone

function count(){
  const images = [...$('.stream-item img')].filter(x => {
    let classList = [...x.classList]
    return !(classList.includes('avatar') || classList.includes('avatar--circular') || classList.includes('Emoji'))
  })

  const alts = images.map(x => x.alt).filter(x => !!x)
  return Math.ceil(alts.length/images.length*100) + '% coverage'
}

threepointone

good doc! some quick answers -

It seems like act() is being recommended for wrapping all state updates in React tests, but is it necessary to use it everywhere if you can use waitForElement to turn the whole test async?

This is a very good question, and something I grappled with earlier. A couple of things that stood out for me -

• waiting for an element is indeed pretty close to what a user's experience is like; ie - a user 'waits' for the form to show itself, after which they fill it in and click a button, then 'wait' for the success screen etc. Ultimately, act() makes this test stronger - it'll ensure that effects, and queued promises, have been flushed before you interact with the element. wrapping waitForElement with act() (the async version, ie), will make this invisible to the user, but with the guarantee that their UI is 'stable'.

• I couldn't assume that all tests would use waitForElement. For example, using timers is common for testing transitions and such. In these scenarios too, ac

threepointone

https://twitter.com/snookca/status/1073299331262889984?s=21

‪“‬In what way is JS any more maintainable than CSS? How does writing CSS in JS make it any more maintainable?”

‪Happy to chat about this. There’s an obvious disclaimer that there’s a cost to css-in-js solutions, but that cost is paid specifically for the benefits it brings; as such it’s useful for some usecases, and not meant as a replacement for all workflows. ‬

‪(These conversations always get heated on twitter, so please believe that I’m here to converse, not to convince. In return, I promise to listen to you too and change my opinions; I’ve had mad respect for you for years and would consider your feedback a gift. Also, some of the stuff I’m writing might seem obvious to you; I’m not trying to tell you if all people of some of the details, but it might be useful to someone else who bumps into this who doesn’t have context)‬

So the big deal about css-in-js (cij) is selectors.

threepointone

the "why do hooks need components to test?" confusion

Hooks look and behave like regular functions. which make expectations around them... weird.

Consider useState. Suppose I tell you, this is its usage -

const [state, setState] = useState(initial)

threepointone

A
  X
    next -> B
B

threepointone

menus 
  nothing
    prev -> personal-ui

  init*
    next -> avatar-block
  
  avatar-block
    avatar-block-init*
      next -> avatar-block-fb-check?

threepointone

# A traffic light
Powered
  power failed -> Unpowered

  Green*
    tick -> Yellow

  Yellow
    tick -> Red