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
{{{ 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 |
users = require './../data/users' | |
data = users: [] | |
data.users.anon = authenticated: false | |
data.users.admin = users[0] | |
data.users.jk = users[1] | |
data.users.artle = users[5] | |
data.users.beountain = users[4] | |
setSession = (userKey) -> |
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__' |
module.exports = [ | |
{ "name": "Brunch.io", "shortName": "brunch", "soId": "brunch", "_id": "514825fa2a26ea020000000b", "__v": 0 }, | |
{ "name": "C#", "shortName": "c#", "soId": "c#", "_id": "514825fa2a26ea020000000e", "__v": 0 } ] |
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
In React's terminology, there are five core types that are important to distinguish:
React Elements
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
/** | |
* Outputs a new function with interpolated object property values. | |
* Use like so: | |
* var fn = makeInterpolator('some/url/{param1}/{param2}'); | |
* fn({ param1: 123, param2: 456 }); // => 'some/url/123/456' | |
*/ | |
var makeInterpolator = (function() { | |
var rc = { | |
'\n': '\\n', '\"': '\\\"', | |
'\u2028': '\\u2028', '\u2029': '\\u2029' |