A prompt to boost your lazy "do this" prompts. Install with one of the buttons below.
| // Types for the result object with discriminated union | |
| type Success<T> = { | |
| data: T; | |
| error: null; | |
| }; | |
| type Failure<E> = { | |
| data: null; | |
| error: E; | |
| }; |
| const { withAppBuildGradle } = require("@expo/config-plugins") | |
| /** | |
| * A Config Plugin to disable bundle compression in Android build.gradle. | |
| * @param {import('@expo/config-plugins').ConfigPlugin} config | |
| * @returns {import('@expo/config-plugins').ConfigPlugin} | |
| */ | |
| const withDisableBundleCompression = (config) => { | |
| return withAppBuildGradle(config, (config) => { | |
| let buildGradle = config.modResults.contents |
| import { ServerResponse, type IncomingMessage } from "node:http"; | |
| import { Http2ServerRequest, Http2ServerResponse } from "node:http2"; | |
| import { isArrayBufferView } from "node:util/types"; | |
| const INTERNAL_BODY = Symbol("internal_body"); | |
| const GlobalResponse = Response; | |
| globalThis.Response = class Response extends GlobalResponse { | |
| [INTERNAL_BODY]: BodyInit | null | undefined = null; |
| #!/bin/node | |
| // Script bumps caniuse-lite in common/config/rush/pnpm-lock.yaml | |
| const path = require("path"); | |
| const fs = require("fs"); | |
| const { execSync } = require("child_process"); | |
| async function main() { | |
| const repoRoot = path.join(__dirname, "../"); |
Memoization is a somewhat fraught topic in the React world, meaning that it's easy to go wrong with it, for example, by [making memo() do nothing][memo-pitfall] by passing in children to a component. The general advice is to avoid memoization until the profiler tells you to optimize, but not all use cases are general, and even in the general use case you can find tricky nuances.
Discussing this topic requires some groundwork about the technical terms, and I'm placing these in once place so that it's easy to skim and skip over:
| import React from 'react'; | |
| import { useWindowSize } from 'react-use'; | |
| // 100vh is broken on mobile (Chrome, Safari): | |
| // https://chanind.github.io/javascript/2019/09/28/avoid-100vh-on-mobile-web.html | |
| export default function use100vh() { | |
| const ref = React.useRef(); | |
| const { height } = useWindowSize(); |
| import { Override, motionValue, useAnimation } from 'framer' | |
| const x = motionValue(0) | |
| const y = motionValue(0) | |
| export function Knob(): Override { | |
| const maxRadius = 32 | |
| const overDrag = 0.25 | |
| const animation = useAnimation() |
| (function (context, trackingId, options) { | |
| const history = context.history; | |
| const doc = document; | |
| const nav = navigator || {}; | |
| const storage = localStorage; | |
| const encode = encodeURIComponent; | |
| const pushState = history.pushState; | |
| const typeException = 'exception'; | |
| const generateId = () => Math.random().toString(36); | |
| const getId = () => { |
First, let's note the difference in philosophy: TypeScript aims for fast analysis because you can to compile it down to JS before you can run/test it. flowtype is meant to be an async analysis that can run continuously with changes since the last analysis, or in parallel with your eslint and bundler rules. As such, flowtype's type system and analysis is not quite as concerned with speed or memory usage in service of potentially finding more bugs.
On two occasions I have tried to roll out flow in React Native applications, and on those two occasions we ended up backing out after a few weeks. Some detail: flow doesn't have a public roadmap, and what version you use is dictated by the react/react-native dependency and the annotations in react-native itself. flowtype also has some hard-coded aspects to help the analysis for React, so major updates to React itself sometimes also require updating flowtype to match. React Native upgrades then get gated based on your dependent libraries (or flow-typed) being updated