rauschma

Cheat sheet for callable entities in ES6

Value:

	FD	FE	AF	C	M
Function-callable	✓	✓	✓	×	✓
Constructor-callable	✓	✓	×	✓	×
Prototype	F.p	F.p	F.p	SC	F.p
Property prototype	✓	✓	×	✓	×

ljharb

Array Iteration

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.

Intro

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

indiesquidge

There are a myriad of benefits of smaller PRs with smaller line change deltas:

• easier for reviewers, not only in sheer amount of code to review, but also in the ability to provide useful feedback or start a discussion around different architecture patterns
• lower chances of bugs creeping in
• simpler to refactor and iterate upon
• encourages the code author to think more iteratively (e.g. what is the API I am trying to add right now? What will it look like when I'm done? Is what I'm doing extensible? Will it be suitable for future extensions, etc.)
• more synonymous with a CI flow; it is better to ship multiple small things that can easily be cherry-picked or reverted than it is to ship big PRs that are harder to debug and roll back

One pitfall to small PRs is people feeling like they can't move ahead or build on top of code that is up for review.

pcattori

import { Base64 } from 'js-base64'
import { Op } from 'sequelize'
import { fromGlobalId } from 'graphql-relay'

// https://github.com/graphql/graphql-relay-js/issues/94#issuecomment-232410564

const effectiveOrder = ({ last }, orderBy) => {
    /* adds `id ASC` to end of `ORDER BY` if `id` is not already in the `ORDER BY` clause
    flips `ASC` to `DESC` (and vice-versa) if pagination arg `last` is defined
    */

sindresorhus

Pure ESM package

The package that linked you here is now pure ESM. It cannot be require()'d from CommonJS.

This means you have the following choices:

1. Use ESM yourself. (preferred)
   Use import foo from 'foo' instead of const foo = require('foo') to import the package. You also need to put "type": "module" in your package.json and more. Follow the below guide.
2. If the package is used in an async context, you could use await import(…) from CommonJS instead of require(…).
3. Stay on the existing version of the package until you can move to ESM.