| const sanityClient = require('@sanity/client'); | |
| const crypto = require('crypto'); | |
| const { | |
| SANITY_API_TOKEN, | |
| SANITY_PROJECT_ID, | |
| SANITY_DATASET, | |
| SHOPIFY_SECRET | |
| } = process.env; |
Hello there.
So, if you are here you probably saw my previous tweet where I asked for tips & tricks on improving the timing on an iOS/React Native app build time.
What will follow was how I mixed those suggestions + some good old GoogleSearch-fu + me deep diving on this for ~2 days.
| // this could be improved... (ex. ignore interfaces/type aliases that describe a parameter type in the same file) | |
| import { Project, TypeGuards, Node } from "ts-morph"; | |
| const project = new Project({ tsConfigFilePath: "tsconfig.json" }); | |
| for (const file of project.getSourceFiles()) { | |
| file.forEachChild(child => { | |
| if (TypeGuards.isVariableStatement(child)) { | |
| if (isExported(child)) | |
| child.getDeclarations().forEach(checkNode); |
React recently introduced an experimental profiler API. This page gives instructions on how to use this API in a production release of your app.
Table of Contents
React DOM automatically supports profiling in development mode for v16.5+, but since profiling adds some small additional overhead it is opt-in for production mode. This gist explains how to opt-in.
React recently introduced an experimental profiler API. After discussing this API with several teams at Facebook, one common piece of feedback was that the performance information would be more useful if it could be associated with the events that caused the application to render (e.g. button click, XHR response). Tracing these events (or "interactions") would enable more powerful tooling to be built around the timing information, capable of answering questions like "What caused this really slow commit?" or "How long does it typically take for this interaction to update the DOM?".
With version 16.4.3, React added experimental support for this tracing by way of a new NPM package, scheduler. However the public API for this package is not yet finalized and will likely change with upcoming minor releases, so it should be used with caution.
| #!/bin/bash | |
| killall Xcode | |
| xcrun -k | |
| xcodebuild -alltargets clean | |
| rm -rf "$(getconf DARWIN_USER_CACHE_DIR)/org.llvm.clang/ModuleCache" | |
| rm -rf "$(getconf DARWIN_USER_CACHE_DIR)/org.llvm.clang.$(whoami)/ModuleCache" | |
| rm -rf ~/Library/Developer/Xcode/DerivedData/* | |
| rm -rf ~/Library/Caches/com.apple.dt.Xcode/* | |
| open /Applications/Xcode.app |
I recently had several days of extremely frustrating experiences with service workers. Here are a few things I've since learned which would have made my life much easier but which isn't particularly obvious from most of the blog posts and videos I've seen.
I'll add to this list over time – suggested additions welcome in the comments or via twitter.com/rich_harris.
Chrome 51 has some pretty wild behaviour related to console.log in service workers. Canary doesn't, and it has a load of really good service worker related stuff in devtools.
| // Promise.all is good for executing many promises at once | |
| Promise.all([ | |
| promise1, | |
| promise2 | |
| ]); | |
| // Promise.resolve is good for wrapping synchronous code | |
| Promise.resolve().then(function () { | |
| if (somethingIsNotRight()) { | |
| throw new Error("I will be rejected asynchronously!"); |
| (function( $ ) { | |
| $.fn.photoswipe = function(options){ | |
| var galleries = [], | |
| _options = options; | |
| var init = function($this){ | |
| galleries = []; | |
| $this.each(function(i, gallery){ | |
| galleries.push({ | |
| id: i, |
