I hereby claim:
- I am juliang on github.
- I am juliang (https://keybase.io/juliang) on keybase.
- I have a public key ASC6w3PW2ig7pBT3EOlvCiqZnC4W60rPOG57MHiE4C807wo
To claim this, I am signing this object:
package | |
{ | |
/** | |
* ObjectPool Class | |
* @author Julian | |
*/ | |
public class ObjectPool | |
{ | |
private var _list:Array; | |
/* | |
tslint:disable no-any | |
tslint:disable no-empty | |
*/ | |
class MutedConsole implements Console { | |
memory: any; | |
Console: NodeJS.ConsoleConstructor; | |
assert(test?: boolean, message?: string, ...optionalParams: any[]): void { } |
I hereby claim:
To claim this, I am signing this object:
Today I learned something at work. I am new to MobX and I had to make changes to a React + Typescript + MobX project. I noticed the props of some React components were marked as optional, and I was told it was because of how the dependency injection worked.
When injecting MobX stores into React components in Typescript, the recommended approach in MobX docs involves declaring optional props (?
). This results in having to perform null checks when accessing an injected store, and MobX recommendeds using the non-null assertion operator (!
).
interface BananaProps {
Following up on the previous gist about avoiding non-null-assertion operator I think it would be good to see some examples of null checking in TypeScript.
Assumming we're using TypeScript with --strictNullChecks
, and that this is what a banana looks like:
type Banana = {
id: number,
open: () => void
};
It happens often at work that my colleagues and I discuss the best way or the proper way to test a specific React component. We don't always agree.
Testing the output of a function is not the same as testing its implementation details.
We recently enabled "noImplicitAny"
in a relatively old TypeScript project. It resulted in 269 new errors. Most of those were missing type annotations but in a few cases, we found problems with the code. These had been around for months and were not caught by our test suite.
We should prefer strict TypeScript configurations to catch issues, not just at compile-time, but (with a good IDE) as we type.
We should try to keep up-to-date with TypeScript versions to benefit from the ever-improving error messages; saving development time.
The following may be a bit obvious for some. But something just clicked in my head and I thought I'd write it down.
Imagine we write a function that returns the "oldest" item in a set/array:
function getOldest(items: Array<{ age: number }>) {