There's the pervarsive notion that all JS is created equal and that there's only minor and easily detectable differences between the various file formats used to author JavaScript. This is correct, from a certain point of view.
For many people writing JavaScript that gets passed into build tools,
| interface A { type: 'A', a: 10 }; | |
| interface B { type: 'B', b: [11] }; | |
| type AB = A | B; | |
| type TypeOf<T extends { type: any }> = T extends { type: infer Type } ? Type : never; | |
| type Cases<T extends { type: any }, R> = { | |
| [P in TypeOf<T>]: (val: Extract<T, { type: P }>) => R | |
| } |
This post has been written in collaboration with @klervicn
Virtually all web apps and websites need to pull data from a server, usually through a JSON-returning API. When it comes to integrating data fetching in React component, the "impedence mismatch" between the React components, which are declarative and synchronous, and the HTTP requests, which are imperative and asynchronous, is often problematic.
Many apps use third-party libraries such as Redux or Apollo Client to abstract it away. This requires extra dependencies, and couple your app with a specific library to perform data fetching. In most cases, what we want is a direct way to integrate plain HTTP requests (e.g. using native fetch) for usage in React components.
Here we will discuss how we can use React Hooks to do this in an elegant, scalable manner.
TLDR: type + predicate = refinement type
We have a type called T and a predicate on T ( (x: T) => boolean ) called P.
We can say that P refines T into a type PT, where PT is a subtype of T containing all values x of type T for which P(x) === true.
| Dev UX: auto imports | Dev UX: contextual naming | Perf: tree shaking | Dev UX: namespace/type merging | |
|---|---|---|---|---|
| namespace import | not yet | yes | maybe | no |
| TS namespace | yes | yes | no | yes |
| types: namespace import / values: named import | not yet / yes | yes / no | yes | no |
| types: TS namespace / values: named import | yes | yes / no | yes | yes |
This week NN Group released a video by Jakob Nielsen in which he attempts to help designers deal with the problem of customers being resistant to their new site/product redesign. The argument goes thusly:
There's slightly more to it than that, he caveats his argument with requiring you to have of course followed their best practices on product design, and allows for a period of customers being able to elect to continue to use the old site, although he says this is obviously only a temporary solution as you don't want to support both.
| import { Observable } from 'rxjs'; | |
| import fetch, { RequestInit, Request, Response } from 'node-fetch'; | |
| import AbortController from 'abort-controller'; | |
| export type RequestInit = RequestInit; | |
| export function fromFetch(input: string | Request, init?: RequestInit): Observable<Response> { | |
| return new Observable<Response>(subscriber => { | |
| const controller = new AbortController(); | |
| const signal = controller.signal; |
| Filter | Description | Example |
|---|---|---|
| allintext | Searches for occurrences of all the keywords given. | allintext:"keyword" |
| intext | Searches for the occurrences of keywords all at once or one at a time. | intext:"keyword" |
| inurl | Searches for a URL matching one of the keywords. | inurl:"keyword" |
| allinurl | Searches for a URL matching all the keywords in the query. | allinurl:"keyword" |
| intitle | Searches for occurrences of keywords in title all or one. | intitle:"keyword" |
| const allowsTracking = () => { | |
| const dnt = | |
| window.doNotTrack || | |
| navigator.doNotTrack || | |
| navigator.msDoNotTrack | |
| if (dnt === 1 || dnt === '1' || dnt === 'yes') { | |
| return false | |
| } | |
| if ('msTrackingProtectionEnabled' in window.external) { | |
| return !window.external.msTrackingProtectionEnabled() |
