| import React, {useEffect, useState, useRef} from 'react' | |
| import documentStore from 'part:@sanity/base/datastore/document' | |
| import {catchError, distinctUntilChanged} from 'rxjs/operators' | |
| import isEqual from 'react-fast-compare' | |
| type Params = Record<string, string | number | boolean | string[]> | |
| interface ListenQueryOptions { | |
| tag?: string | |
| apiVersion?: string |
| // Ported from https://gist.github.com/Grsmto/cc4db257d05898ca60a9572511fa9bcf and adapted to a functional component. | |
| // | |
| // Overrides the array's Add item button based on an integer-based validation rule. | |
| // | |
| // Add the following to sanity.json: | |
| // | |
| // { | |
| // "implements": "part:@sanity/form-builder/input/array/functions", | |
| // "path": "./src/components/customArrayFunctions.js" | |
| // } |
This gist lists challenges you run into when building offline-first applications based on IndexedDB, including open-source libraries like Firebase, pouchdb and AWS amplify (more).
Note that some of the following issues affect only Safari. Out of the major browsers, Chrome's IndexedDB implementation is the best.
When this bug occurs, every time you use the indexeddb, the WAL file grows. Garbage collection doesn't seem to be working, so after a while, you end up with gigabytes of data.
| // Licensed under a CC0 1.0 Universal (CC0 1.0) Public Domain Dedication | |
| // http://creativecommons.org/publicdomain/zero/1.0/ | |
| // HTML files: try the network first, then the cache. | |
| // Other files: try the cache first, then the network. | |
| // Both: cache a fresh version if possible. | |
| // (beware: the cache will grow and grow; there's no cleanup) | |
| const cacheName = 'files'; |
The proposal you’re about to read is not just a proposal. We have a working implementation of almost everything we discussed here. We encourage you to checkout and build our branch: our fork, with the relevant branch selected. Building and using the implementation will give you a better understanding of what using it as a developer is like.
Our implementation ended up differing from the proposal on some minor points. As our last action item before making a PR, we’re writing documentation on what we did. While I loathe pointing to tests in lieu of documentation, they will be helpful until we complete writing docs: the unit tests.
This repo also contains a bundled version of npm that has a new command, asset. You can read the documentation for and goals of that comma
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.
| <!DOCTYPE html> | |
| <html> | |
| <head> | |
| <meta charset="UTF-8"> | |
| <title><%= htmlWebpackPlugin.options.title %></title> | |
| </head> | |
| <body> | |
| <input id="float"/> | |
| </body> | |
| </html> |
| // All the transform types. | |
| const types = [ | |
| "translate", | |
| "translateX", | |
| "translateY", | |
| "scale", | |
| "scaleX", | |
| "scaleY", | |
| "rotate", | |
| "skew", |
| // Straight from documentation. | |
| const reducer = combineReducers({ | |
| a: doSomethingWithA, | |
| b: processB, | |
| c: c | |
| }); | |
| // This is functionally equivalent. | |
| function reducer(state, action) { | |
| return { |
| ssh-keygen -t rsa -b 4096 -m PEM -f jwtRS256.key | |
| # Don't add passphrase | |
| openssl rsa -in jwtRS256.key -pubout -outform PEM -out jwtRS256.key.pub | |
| cat jwtRS256.key | |
| cat jwtRS256.key.pub |
