| 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; |
🥇 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}("")
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:
| export default (function create(options = {}) { | |
| const client = { | |
| headers: options.headers || {}, | |
| create | |
| }; | |
| const events = {}; | |
| client.emit = (type, e) => { | |
| events[type] && | |
| events[type].slice().map(fn => { |
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. See also my blog at www.janvsmachine.net.
Keep it simple, stupid. You ain't gonna need it.
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:
See the Tailwind Plugins for more info on plugins.
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
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.
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
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
