James K Nelson

Also, if you pull the second argument of .key()... const [outlet, { load }] = resource.key(url) Then you can avoid Suspense waterfalls by imperatively load stuff into cache (among other things)

If Vue or Angular adds Suspense, it'll work as-is. There's actually nothing React-specific about it. In fact, you can also call outlet.getValue() to get a Promise to the value anyway, which is super handy for SSR

If you want to use it without Suspense, just check hasData before accessing data. You can use that synchronously.

So I guess what I'm saying is error objects are overrated.

Either you have a response, or you don't. And if you don't have a response, you retry, or tell the user that you won't. And the funny thing is that in *none* of these scenarios do you actually need an error object.

Random thought: When *getting* data over the network, there's probably only really 5 reasonable ways to handle the response. 1. Is data! Yay! 2. Data is not here, doh. 3. Data is forbidden, fuck. 4. No (sensible) response. Let's retry. 5. Wtf? Let's crash the app.

Sometimes 350 lines of code take an hour to write. Sometimes they take 3 days. “I have only made this [file] longer because I have not had the time to make it shorter.”

What if you turned Redux inside out?

Reasons to break the rule: - Functions like React.lazy take a module as an argument, and you don't want to customize the function for each module. Use a default export. - You're importing many files at once, e.g. with a Webpack context. Use a default export.

Reasons to avoid default exports: - Now you can always export * from './module' - Add exports to files with less worries about naming - No scratching your head for imports... "was that a default or not?"

Looking at everyone's tweet-length summaries of their accomplishments over the last decade is giving me an acute case of imposter syndrome.