npx create-react-app@next --scripts-version=@next --template=cra-template@next my-js-app
npx create-react-app@next --scripts-version=@next --template=typescript@next my-ts-app
I heard some points of criticism to how React deals with reactivity and it's focus on "purity". It's interesting because there are really two approaches evolving. There's a mutable + change tracking approach and there's an immutability + referential equality testing approach. It's difficult to mix and match them when you build new features on top. So that's why React has been pushing a bit harder on immutability lately to be able to build on top of it. Both have various tradeoffs but others are doing good research in other areas, so we've decided to focus on this direction and see where it leads us.
I did want to address a few points that I didn't see get enough consideration around the tradeoffs. So here's a small brain dump.
"Compiled output results in smaller apps" - E.g. Svelte apps start smaller but the compiler output is 3-4x larger per component than the equivalent VDOM approach. This is mostly due to the code that is usually shared in the VDOM "VM" needs to be inlined into each component. The tr
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.
import fetch from 'isomorphic-fetch'; | |
import stripeInit from 'stripe'; | |
import {stripeKey, graphCoolEndpoint} from './constants'; | |
const stripe = stripeInit(stripeKey); | |
const updateGraphCoolCustomer = async (id, stripeId) => { | |
const updateCustomer = JSON.stringify({ | |
query: ` | |
mutation { |
import * as admin from 'firebase-admin'; | |
import Graphcool, { fromEvent } from 'graphcool-lib'; | |
import { Request, Response } from 'express'; | |
const TAG = 'LoginHandler'; | |
const serviceAccount = require('./path/to/firebaseKey.json'); | |
const pat = '__PAT__' |
Some quick thoughts on https://twitter.com/dan_abramov/status/884892244817346560. It's not ignorant at all to ask how browser vendors approach performance. On the V8 side we've discussed bytecode precompilation challenges a few times this year. Here's my recollection of where we stand on the idea:
JavaScript engines like V8 have to work on multiple architectures. Every version of V8 is different. The architectures we target are different. A precompiled bytecode solution would require a system (e.g the server or a CDN) to generate bytecode builds for every target architecture, every version of V8 supported and every version of the JavaScript libraries or bundles bytecode is being generated for. This is because we would need to make sure every user accessing a page using that bytecode can still get the final JS successfully executed.
Consider that if a cross-browser solution to this problem was desired, the above would need to be applied to JavaScriptCore, SpiderMonkey and Chakra as well. It would need to ca
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.
In React's terminology, there are five core types that are important to distinguish:
React Elements
{{{ Zkratky | |
C control | |
M meta (Alt, option) | |
E Escape (meta) | |
E / = M-/ (escape a meta jsou zamenitelne - rozdil je v tom ze meta se musi drzet | |
}}} | |
{{{ Troubleshooting | |
Kdyz vam neco nebude fungovat muze to byt starsi verzi interpretu nebo readline | |
System wide konfigurace od package maintaineru |
#!/usr/bin/env bash | |
# MIT © Sindre Sorhus - sindresorhus.com | |
# git hook to run a command after `git pull` if a specified file was changed | |
# Run `chmod +x post-merge` to make it executable then put it into `.git/hooks/`. | |
changed_files="$(git diff-tree -r --name-only --no-commit-id ORIG_HEAD HEAD)" | |
check_run() { | |
echo "$changed_files" | grep --quiet "$1" && eval "$2" |