My plan for migrating micro-graphql-react to Svelte was to fork the repo, then use a rusty machete to hack away the complicated bullshit I spent months adding for Suspense support. That'd leave it 98% React agnostic.

Then swap out React, for Svelte.

It appears to work 😏 🥳 🍺 ImageImageImage
The main challenge was ... webpack. If webpack doesn't have .mjs at the front of the extensions array, bad things happen to the writeable store, coming from

var internal = require('../internal');

(webpack hard codes undefined)

/cc @Rich_Harris - maybe add a warning?
And that's it. Now begins the real work, of migrating all the tests from React over to Svelte.

If you're by chance one of the few users of the original react version, don't worry - I'll still be supporting it.
It feels SO good to have the original, non-Suspense version of my GraphQL client back. It's much simpler, and easier to reason about; it's like a breath of fresh air.

And naturally it'll still have preload capability. You don't need Suspense to avoid waterfalls 😉

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Adam Rackis

Adam Rackis Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @AdamRackis

23 Oct
I know I've been heavy on the Svelte hype lately. Some folks have been asking for specifics, which is pretty reasonable. So while my League Client patches, here's a thread of actual Svelte features that make me happy.
1: Uni-directional prop flow as religion is a shitty religion.

A solid component model, with props being passed downward is great. That was the huge value proposition of React. But there are times when this over-complicates matters.
We've all been there. We have some state that a child component needs to control. So what do we do? We define the state in the parent, and pass a setter, or reducer to the child, which the child then calls with the new value. We've all done this a million times.
Read 15 tweets
22 Oct
The nicest surprise with Svelte has been the tooling. I expected it to be raw, but, and I swear on @ken_wheeler's finest bourbon I'm not exaggerating, it's better than React.

Auto complete on Svelte attributes, auto import when you use a component, etc. All *without* TypeScript.
And yeah I know the auto-import thing works with React. Usually. If you're using default exports it's often a crap shoot. It's incredibly reliable with Svelte.

And the attribute completions even include warnings if you reference an action that's not defined, etc. Top notch 🍺
And of course by "tooling" I mean the. VS Code plugin. Install that bitch and you're done.
Read 4 tweets
3 Aug
@acdlite Has this been elaborated anywhere? I'm trying to see what the rules are for mutating refs within a data-fetching hook. CM interrupting renders + data-fetching asynchrony makes this ... hard.

My worry is something like the following:

1/
@acdlite useQuery hook called, "currentQuery" ref is updated

render is interrupted

Can that same render be re-run but...with older state? That's not possible, is it? Except with useTransition, but in that case the new-state renders / old-state renders are in separate trees?

2/
@acdlite Ever be humanly possible for:

useQuery existing w/ data for query "A"

useQuery called with query "B"

currentQuery.current set to "B"—fetch()

useQuery re-renders w/ old query state "A"

ref set to "A"

promise for "B" resolves—wrongly thinks it's outdated bc mismatching ref
Read 6 tweets
17 Nov 19
The React team are some of the best web developers in the world. But sometimes they struggle to explain things to normal people—ie folks who have no fucking clue what "algebraic effects" are (like me!)

So with that, here's my serious attempt at explaining suspense

1/
For simplicity I'll talk in the first person, as though I were one of the devs making Suspense, and announcing it. Again, this is just to keep the messaging simple. I'm not deluded enough to think I could work on that team.
Hey, you know how when you browse to a new section in your web app, the new page's component lazily loads, since you wrapped it in React.lazy()? Well guess what: we have some new primitives that'll make that loading much smoother.
Read 20 tweets
11 Nov 19
Wait hold up React fam ✋

A route only needs to block (Suspend) on the initial data, right?

If our Route were to preload its data, and also send down a read() method that got called on every render, and threw until the FIRST data were ready, wouldn’t that be sufficient?

1/
Subsequent data updates (and, well, the initial data) would be returned from the same GraphQL hooks we’re already using, with the same incremental spinners.

But now a single initial page reveal with all needed data. And render as you fetch.

Is there a downside I’m missing?

2/
So something like

const TodoList = (props) => {
// data already prefetching

props.res.read(); //throws if init data not ready

const { loading, data } = useSameOldGraphQLQuery(...);

// and go ...
Read 10 tweets
30 Oct 19
* puts on a black robe *

* sacrifices a goat *

* lights incense *

"Dan Abramov"

"Dan Abramov"

"Dan Abramov"

Hey Dan 👋 How's London?

Anyway, I was just wondering if you could tell us React devs how preloading is supposed to work in this brave new Suspense world.

Thanks!
"preload high; read low" was the early advice, and that shit made *total* sense.

But now I'm hearing far, far more complex, and at times contradictory advice.
Especially confusing: difference between "fetch then render" & "fetch as you render" is utterly imperceptible 99.99% of the time—basically any time a component can render extremely fast, which is almost always.

Boring.

Let's talk about *real* waterfalls: network waterfalls.
Read 7 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!