karol-majewski

Background: we've had a conversation about using full words vs. single letters in function names. One argument against using full words was that it leads to long, Java-like names like getPropertyFromDictionaryOptionCurried.

The problem

Long names like getPropertyFromDictionaryOptionCurried are bad not because they are made of full words. They are bad because they are saying too much.

If single letters read more naturally than full words, then this would be an improvement:

getPropertyFromDictionaryOptionC

developit

export default (function create(options = {}) {
	const client = {
		headers: options.headers || {},
		create
	};
	const events = {};

	client.emit = (type, e) => {
		events[type] &&
			events[type].slice().map(fn => {

swyxio

Sequence of Gatsby's bootstrap lifecycle with links to source code as of v2.0.0

permalink https://github.com/gatsbyjs/gatsby/blob/ffd8b2d691c995c760fe380769852bcdb26a2278/packages/gatsby/src/bootstrap/index.js

1. open and validate gatsby-config (get-config-file.js) 1.5 load themes (swyx added this note July 2019)
2. load plugins (load-plugins/index.js) from the list given in gatsby-config.js
3. onPreBootstrap: runs onPreBootstrap if it is implemented in any plugins, for example gatsby-plugin-typography. Receives handy [apiCallArgs](https://github.com/gatsbyjs/gatsby/blob/ffd8b2d691c9

threepointone

I made a little styling lib called glam

(some features are in development)

one

let's start off with the simplest use case. we'll make an 'index.html' page, and assume we've setup our js bundler to output bundle.js

Andarist

function createLongLastingContext<T>(factory: () => T) {
  const defaultValue = typeof document !== "undefined" ? factory() : null;
  const ctx = React.createContext<T | null>(defaultValue);
  return {
    useContext: () => {
      const value = React.useContext(ctx);
      if (!value) {
        throw new Error("Context not initialized.");
      }
      return value;

stuartd

Lost from https://blogs.msdn.microsoft.com/ericgu/2004/01/12/minus-100-points/

When I switched over the C# compiler team, I had hoped that I would be able to give some insight into how the design team works, what decisions we make, etc. Language design is a very esoteric field, and there's not a lot written about it (though “Design and evolution of C++“ is a pretty good read). I had hoped that I would be able to do this with concrete examples, as that makes it much easier.

I've been watching for candidate topics to write about, but haven't yet come up with any good ones. One of the problems is that features have a tendency to morph in design (and in whether they'll make it into Whidbey) as time goes by, and it would be bad for me to say, “we're talking about doing“ and then have us decide it wasn't a good idea. Or, for us to decide that doesn't fit into our schedule, or it would break existing code, or any of the other reasons that might cause us to pull a feature. We're generally not comfortable re

devinrhode2

/**
 * Like, basically PERFECT scrollbars
 */

/* 
   It's pure CSS. 
   Since a quick google search will confirm people going crazy about Mac OS Lion scrollbars...
   this has no fade-out effect.
  
   In Mac OS Lion, the lowest common denominator is always showing scrollbars by a setting.

threepointone

On implementing a client for feature flags in your UI codebase

This document isn't an explainer on Feature Flags, you can find that with my amateur writeup, or literally hundreds of better writeups out there.

This document is also agnostic to the choice of service you'd use: LaunchDarkly or split.io or optimizely or whatever; that's orthogonal to this conversation.

Instead, this document is a list of considerations for implementing a client for using Feature Flags for User Interface development. Service providers usually give a simple fetch and use client and that's it; I contend that there's a lot more to care about. Let's dive in.

To encourage usage, we'd like for the developer experience to be as brutally simple as possible. So, this should be valid usage:

sebmarkbage

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

karmacoma-eth

Sending Ether Cheat Sheet

TLDR

🥇 Instead of sending Ether, use the withdrawal pattern

🥈 If you really need to send Ether, use a safe wrapper like OpenZeppelin's Address.sendValue(addr, amount)

🥉 If you really need to send Ether without dependencies, use (bool success, ) = addr.call{value: amount}("")