- https://github.com/ehmicky/cross-platform-node-guide, https://shapeshed.com/writing-cross-platform-node/
- Computing average in a constant time (average streaming)
- connect.js explained
Understanding Babel internals
- Step-by-step guide for writing a custom babel transformation
- Understanding ASTs by Building Your Own Babel Plugin
All tested with
node --use_strict (to prevent silent errors).
Note: Flow tracks these flags on objects:
Optional chaining gotchas
Optional chaining != error suppression operator.
Node.js LTS or not?
Node LTS is primarily aimed at enterprise use where there may be more resistance to frequent updates, extensive procurement procedures and lengthy test and quality requirements.
Generally if you are able to keep up with the latest stable and future Node releases you should do so. These are stable and production ready releases with excellent community support. Unstable and experimental functionality is kept behind build and runtime flags and should not affect your day to day operations.
Does it mutate 😱
Jest: test.concurrent( ... )
V8 Built-in functions
Yarn comments in
https://github.com/yarnpkg/yarn/pull/3829/files (also great example of
test.concurrent usage ^^)
Clearing/resetting/restoring Jest mocks
I am never gonna remember this correctly I guess.
jest.clearAllMocks()only clears the internal state of the mock
jest.resetAllMocks()does the same + it removes any mocked implementations or return values
jest.restoreAllMocks()does everything above but it restores the original non-mocked implementation (and works only with
Is this thing a number?
TL;DR - do not use only
isNaN for this and write a lot of tests.
StackOverflow implementation (so far ✅):
Facebook implementation (❌ fails for many values like
null, booleans, Date object, empty strings, ...):
@cookielab implementation (❌ fails for values like
7.2acdgs and it's not multiplatform):
Please note that
Number.isNaN differs significantly (
isNaN performs a type conversion). The same for
In comparison to the global
isFinite()function, this method doesn't forcibly convert the parameter to a number. This means only values of the type number, that are also finite, return
Polyfill (to understand the difference better):
Unfortunatelly, Flow cannot uncover this version (which can also explode):
Placement of catch BEFORE and AFTER then
There are differences either when p resolves or rejects, but whether those differences matter or not depends upon what the code inside the
.catch() handlers does.
What happens when p resolves
In the first scheme, when p resolves, the .then() handler is called. If that .then() handler either returns a value or another promise that eventually resolves, then the .catch() handler is skipped. But, if the .then() handler either throws or returns a promise that eventually rejects, then the .catch() handler will execute for both a reject in the original promise p, but also an error that occurs in the .then() handler.
In the second scheme, when p resolves, the .then() handler is called. If that .then() handler either throws or returns a promise that eventually rejects, then the .catch() handler cannot catch that because it is before it in the chain.
So, that's difference #1. If the .catch() handler is AFTER, then it can also catch errors inside the .then() handler.
What happens when p rejects
Now, in the first scheme, if the promise p rejects, then the .then() handler is skipped and the .catch() handler will be called as you would expect. What you do in the .catch() handler determines what is returned as the final result. If you just return a value from the .catch() handler or return a promise that eventually resolves, then the promise chain switches to the resolved state because you "handled" the error and returned normally. If you throw or return a rejected promise in the .catch() handler, then the returned promise stays rejected.
In the second scheme, if the promise p rejects, then the .catch() handler is called. If you return a normal value or a promise that eventually resolves from the .catch() handler (thus "handling" the error), then the promise chain switches to the resolved state and the .then() handler after the .catch() will be called.
So that's difference #2. If the .catch() handler is BEFORE, then it can handle the error and allow the .then() handler to still get called.
Responsive component with hooks