Skip to content

Instantly share code, notes, and snippets.

View danielkcz's full-sized avatar
🏗️
Building own experimental dating app

Daniel K. danielkcz

🏗️
Building own experimental dating app
View GitHub Profile
@iansu
iansu / README.md
Last active March 1, 2021 08:40
Create React App 4.0 Alpha Testing

Create New App

JavaScript Template

npx create-react-app@next --scripts-version=@next --template=cra-template@next my-js-app

TypeScript Template

npx create-react-app@next --scripts-version=@next --template=typescript@next my-ts-app

@sebmarkbage
sebmarkbage / WhyReact.md
Created September 4, 2019 20:33
Why is React doing this?

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

@bvaughn
bvaughn / index.md
Last active November 14, 2024 19:13
How to use profiling in production mode for react-dom

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

Profiling in production

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 {
@jhalborg
jhalborg / graphcool-firebase-auth.js
Created July 21, 2017 11:43
GraphCool + Firebase Auth function for generating a custom Firebase token with embedded Graphcool token
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__'
@addyosmani
addyosmani / bytecode.md
Last active May 28, 2022 22:40
Thoughts on precompiling JS bytecode for delivery through a server/CDN

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

@Rich-Harris
Rich-Harris / service-workers.md
Last active December 18, 2024 21:13
Stuff I wish I'd known sooner about service workers

Stuff I wish I'd known sooner about service workers

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.

Use Canary for development instead of Chrome stable

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.

@sebmarkbage
sebmarkbage / react-terminology.md
Last active January 9, 2023 22:47
React (Virtual) DOM Terminology
{{{ 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
@sindresorhus
sindresorhus / post-merge
Last active July 25, 2024 06:53
git hook to run a command after `git pull` if a specified file was changed.In this example it's used to run `npm install` if package.json changed and `bower install` if `bower.json` changed.Run `chmod +x post-merge` to make it executable then put it into `.git/hooks/`.
#!/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"