Skip to content

Instantly share code, notes, and snippets.

🎯
Focusing

swyx sw-yx

🎯
Focusing
Block or report user

Report or block sw-yx

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile
@sw-yx
sw-yx / Netlify9PartDemo Description and Timestamps.md
Last active Oct 2, 2019
Netlify9PartDemo Description and Timestamps.md
View Netlify9PartDemo Description and Timestamps.md
@sw-yx
sw-yx / reactor-needed-details-Oct-Svelte.md
Last active Sep 25, 2019 — forked from bnb/reactor-needed-details.md
reactor-needed-details-Oct-Svelte.md
View reactor-needed-details-Oct-Svelte.md
@sw-yx
sw-yx / cities.js
Last active Sep 16, 2019
threejs boilerplate
View cities.js
let renderer, camera, controls, scene,
width = window.innerWidth,
height = window.innerHeight;
init();
animate();
addShapes();
render();
function addShapes() {
@sw-yx
sw-yx / NETLIFY_ENV_VARS.js
Last active Oct 30, 2019
BIG FAT LIST OF NETLIFY ENV VARS
View NETLIFY_ENV_VARS.js
process.env = {
/**
*
* AUTOMATICALLY SET BY NETLIFY. IMMUTABLE!
* docs: https://www.netlify.com/docs/continuous-deployment/#environment-variables
*
*/
NETLIFY: 'true',
// // URLs
@sw-yx
sw-yx / oclifconf2019.md
Last active May 31, 2019
oclifconf2019 notes
View oclifconf2019.md

some notes

  • decent representaiton here across paypal, twilio, apollo, stripe, intuit, adobe/cordova, and thats just the people ive met so far. and ofcourse salesforce, heroku, and netlify
  • jeff dickey (oclif creator) leaving heroku. not sure what hes doing next
  • salesforce cli has 16k total unique users, ~2k daily active. 90 community plugins
  • twilio is launching a big oclif initiative at Signal Conf in a few weeks
  • paypal working on something big too, a few devs here
  • salesforce/heroku have 10 people fulltime and 70ish domain expert contributors on CLI. a lot more community plugin contributors
@sw-yx
sw-yx / adaptive_intent.md
Created May 3, 2019
an adaptive, intent based CLI "state machine"
View adaptive_intent.md

an adaptive, intent based CLI "state machine"

one realization from working on Netlify's CLI is that the CLI framework we used, oclif, didn't provide a great user experience out of the box.

Emphasis on great: it does a lot of nice things, like offering flag and argument parsing, help documentation, and pluggability. That's good for the CLI developer. But what about the CLI user?

  • Idiomatic oclif code often checks for required preconditions, and if it doesn't exist, it prints a warning and then process.exit(1).
  • Decent code prints a helpful warning telling the user what they got wrong. It is informative.
  • Better code offers a prompt, creates a file, or something similar to solve the precondition before proceeding. (possibly recursively). It is intent-based.
  • Great code remembers past inputs to prompts and uses that to offer useful defaults. It is adaptive.
@sw-yx
sw-yx / createCtx-noNullCheck.tsx
Last active Nov 20, 2019
better createContext APIs with setters, and no default values, in Typescript. this is documented in https://github.com/typescript-cheatsheets/react-typescript-cheatsheet/blob/master/README.md#context
View createCtx-noNullCheck.tsx
// create context with no upfront defaultValue
// without having to do undefined check all the time
function createCtx<A>() {
const ctx = React.createContext<A | undefined>(undefined)
function useCtx() {
const c = React.useContext(ctx)
if (!c) throw new Error("useCtx must be inside a Provider with a value")
return c
}
return [useCtx, ctx.Provider] as const
@sw-yx
sw-yx / final submission.md
Last active Apr 16, 2019
Why React is Not Reactive - React Rally CFP
View final submission.md

This is the CFP for my React Rally talk, which was eventually accepted and given here: https://www.youtube.com/watch?v=nyFHR0dDZo0

Final Submission: Why React is not Reactive

Functional-reactive libraries like RxJS make it easy to understand how data changes, giving us tools to declaratively handle events and manage state. But while our render methods react to state changes, React isn’t reactive. Instead, we write imperative event-handlers, and trip up on gotchas like async setState and race conditions. Why? In this talk we build a Reactive React to show the difference between the "push" and "pull" paradigms of data flow and understand why React chooses to manage Scheduling as a core Design Principle, enabling awesome features like async rendering and Suspense!

Theme: This talk is a deep dive into React's core design principle around scheduling. Instead of abstract discussion, we make it accessible and real by exploring an alternate universe in which React was an FRP library and actually run

You can’t perform that action at this time.