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;

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}("")

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:

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 => {

stettix

Things I believe

This is a collection of the things I believe about software development. I have worked for years building backend and data processing systems, so read the below within that context.

Agree? Disagree? Feel free to let me know at @JanStette.

Fundamentals

Keep it simple, stupid. You ain't gonna need it.

Merott

This is a simple Tailwind plugin to expose all of Tailwind's colors, including any custom ones, as custom css properties on the :root element.

There are a couple of main reasons this is helpful:

• You can reference all of Tailwind's colors—including any custom ones you define—from handwritten CSS code.
• You can define all of your colors within the Tailwind configuration, and access the final values programmatically, which isn't possible if you did it the other way around: referencing custom CSS variables (defined in CSS code) from your Tailwind config.

See the Tailwind Plugins for more info on plugins.

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

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

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

fnky

ANSI Escape Sequences

Standard escape codes are prefixed with Escape:

• Ctrl-Key: ^[
• Octal: \033
• Unicode: \u001b
• Hexadecimal: \x1B
• Decimal: 27