The k-nearest neighbors (k-NN) algorithm is among the simplest algorithms in the data mining field. Distances / similarities are calculated between each element in the data set using some distance / similarity metric ^[1]^ that the researcher chooses (there are many distance / similarity metrics), where the distance / similarity between any two elements is calculated based on the two elements' attributes. A data element’s k-NN are the k closest data elements according to this distance / similarity.
// something like: | |
<BundleLink to="/profile" onLoadStart={() => { | |
// throw a spinner up on the "old" page while we load | |
this.setState({ navigating: true }) | |
}}>Profile</BundleLink> | |
<BundleLink to="/dash" prefetch={true}>Dashboard</BundleLink> | |
/////////////////////////////////////////////////////// | |
const BUNDLED_ROUTES = { |
version: '3.3' | |
services: | |
db: | |
image: mysql:latest | |
volumes: | |
- dbdata:/var/lib/mysql | |
restart: always | |
ports: | |
- "3306:3306" |
<!DOCTYPE html> | |
<html> | |
<head> | |
<meta charset="UTF-8" /> | |
<title>Add React in One Minute</title> | |
</head> | |
<body> | |
<h2>Add React in One Minute</h2> | |
<p>This page demonstrates using React with no build tooling.</p> |
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.
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.

{ | |
// Commented-out options have their default values. | |
"include": ["src/**/*"], | |
"exclude": ["node_modules/*"], | |
// "files": [], // A list of relative or absolute file paths to include. | |
// "extends": "", // A string containing a path to another configuration file to inherit from. | |
// "references": [], // An array of objects `{"path": "./to/dirOrConfig"}` that specifies projects to reference. | |
// "compileOnSave": false, // Signals to the IDE to generate all files for a given tsconfig.json upon saving. | |
"compilerOptions": { |
# Put this function to your .bashrc file. | |
# Usage: mv oldfilename | |
# If you call mv without the second parameter it will prompt you to edit the filename on command line. | |
# Original mv is called when it's called with more than one argument. | |
# It's useful when you want to change just a few letters in a long name. | |
# | |
# Also see: | |
# - imv from renameutils | |
# - Ctrl-W Ctrl-Y Ctrl-Y (cut last word, paste, paste) |