Skip to content

Instantly share code, notes, and snippets.

Sunil Pai threepointone

Block or report user

Report or block threepointone

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile
@threepointone
threepointone / settled.react.md
Last active Aug 23, 2019
Ember's settled() test helper, for React
View settled.react.md

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
threepointone / count-alts.js
Created May 15, 2019
count the number of images with alts on a twitter.com/USERNAME/media page
View count-alts.js
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'
}
View answers.md

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

View for-snook.md

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.

View hooks-arent-functions.md

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)
View SketchSystems.spec
menus
nothing
prev -> personal-ui
init*
next -> avatar-block
avatar-block
avatar-block-init*
next -> avatar-block-fb-check?
View SketchSystems.spec
# A traffic light
Powered
power failed -> Unpowered
Green*
tick -> Yellow
Yellow
tick -> Red
View reduxfreeze.js
// this component freezes redux state for its children when `cold` is true
// after every render, it saves a snapshot of the last used redux state
// it also replacies the redux store with a 'proxy' store, which, when cold
// - no-ops all action dispatches
// - returns state from the snapshot
class Freeze extends Component<{ cold: boolean, children: Node }> {
context: {
store: Store,
};
static contextTypes = {
View 0 basics.md

A series of posts on css-in-js

0. styles as objects

First, an exercise. Can we represent all of css with plain data? Let's try.

let redText = { color: 'red' };
You can’t perform that action at this time.