Crank maintainers wisdom required in Twitter discussion

[brucou]

@brainkim in case you monitor here more often: there is an interesting discussion on twitter addressing crank, and dan has some questions how crank handle concurrency. Would be great if you could chime in:

cf. here and here

[brainkim]

Converting to discussion mostly because I want to use that feature more! Thanks for bringing this to my attention, Bruno.

I've looked at Crank and from a cursory glance I don't understand how it solves the concurrency problem. How does it handle remaining interactive while it's waiting for something async?

https://twitter.com/dan_abramov/status/1301678841023418370

I read the explanation in the docs but I don't understand how it provides consistency guarantees and prevents random things from showing up / disappearing in an uncoordinated way. In React we really care about consistency because without it you can't reason about tree at scale.

https://twitter.com/dan_abramov/status/1301680021246038016

I must admit I didn’t really conceptualize the “concurrency problem” on this level. The way I came to Crank’s async API was to work backwards; if we assume that defining components as async functions is useful, what would be the most useful behavior for the application developer?

For instance, one nice behavior about async function components in Crank is that concurrent renderings of the same component enqueue, such that there is only one pending call of an async component in the tree at a time. This works based on the same diffing algorithm which updates and unmounts components, and is useful insofar as it prevents simple async components from slamming backends with an async request every keystroke or whatever.

The question of “coordinating” async components is one of how asynchrony communicates up the tree to ancestors and with siblings, and if you’re coming from the perspective of React, you might find Crank’s behavior surprising. Crank will only coordinate the first rendering of each element, meaning that if an element has multiple async children, it will render those siblings in unison for the first rendering only.

// Normally the counters would be encapsulated within a generator, but in this example we place them outside to show async function component updates.
let i = 0;
async function Number() {
  await new Promise((resolve) => setTimeout(resolve, 2000));
  return <div>{i++}</div>;
}

const letters = "abcdefghijklmnopqrstuvwxyz";
let j = 0;
async function Letter() {
  await new Promise((resolve) => setTimeout(resolve, 3000));
  return <div>{letters[j++ % letters.length]}</div>;
}

function *App() {
  const handleClick = () => this.refresh();
  while (true) {
    yield (
      <div>
        <button onclick={handleClick}>Refresh</button>
        <div>
          <Number />
          <Letter />
        </div>
      </div>
    );
  }
}

If you run this code, you’ll see that for the first render, nothing appears until both the Number and Letter component fulfill once, after which the number and letter components update independently based on when and how many times you click the button.

Is this a problem? Maybe. What I don’t get with the consistency rhetoric in the referenced tweet is why async components are being held to a higher standard that regular stateful components. Async components are just stateful components which work based on promises, and one possible solution to the “tearing” between the Number and Letter component in the preceding example would be to lift the state to a common ancestor, as advocated in the classic guide Thinking in React. I think as a general rule, you should avoid having too many async components and lift asynchrony as high in the tree as you can.

Maybe this is an unsatisfying answer, and on some level I agree. I spent a lot of time pondering how to reproduce the basic Suspense component, given that the async function components as I have defined both don’t show anything until the promises fulfill and do not respond to updates while the current run is pending. The question is, how do we define components which can concurrently render fallbacks? We can’t use sync function components, because they aren’t stateful, and the most useful behavior is for them to pass updates to their children transparently, regardless of whether or not they’re pending. We also can’t use sync generator components, because sync generator components are resumed with the DOM result of their yields, implying that rendering has completed by the time the generator is resumed. And even if sync generator components did not have this requirement, you can’t await in the body of the generator, so it’s unclear what sort of API we could use to respond to async children.

This left async generator components, so in the spirit of my strategy of “choosing the most useful behavior,” I decided that async generator components are continuously resumed once mounted, and that to suspend async generator components when there aren’t new props updates or refreshes we use a special context async iterator for await ({} of this). This means that async generator components can concurrently render multiple element trees as their children for each update, and I decided that when different element roots are rendered in the same position, the renderings are raced, so that earlier async trees can show while later async trees are pending. This was enough to create Suspense elements in user space, so that was enough for me to ship an initial version of Crank.

async function Fallback({timeout, children}) {
  await new Promise((resolve) => setTimeout(resolve, timeout));
  return children;
}

async function *Suspense({timeout = 1000, fallback, children}) {
  for await ({timeout = 1000, fallback, children} of this) {
    yield <Fallback timeout={timeout}>{fallback}</Fallback>;
    yield <Fragment>{children}</Fragment>;
  }
}

You can even reproduce React’s nested suspense behavior, which, as it turns out, preact compat has trouble with (preactjs/preact#2747).

function fetchUser() {
  await new Promise((resolve) => setTimeout(resolve, 1000));
  return {
    name: "Ringo Starr"
  };
}

async function fetchPosts() {
  await new Promise((resolve) => setTimeout(resolve, 2000));
  return [ 
    {
      id: 0,
      text: "I get by with a little help from my friends"
    },
    {
      id: 1,
      text: "I'd like to be under the sea in an octupus's garden"
    },
    {
      id: 2,
      text: "You got that sand all over your feet"
    }
  ];
}

async function ProfileDetails() {
  // Try to read user info, although it might not have loaded yet
  const user = await fetchUser();
  return <h1>{user.name}</h1>;
}

async function ProfileTimeline() {
  // Try to read posts, although they might not have loaded yet
  const posts = await fetchPosts();
  return (
    <ul>
      {posts.map((post) => (
        <li crank-key={post.id}>{post.text}</li>
      ))}
    </ul>
  );
}

function ProfilePage() {
  return (
    <Suspense fallback={<h1>Loading profile...</h1>}>
      <ProfileDetails />
      <Suspense fallback={<h1>Loading posts...</h1>}>
        <ProfileTimeline />
      </Suspense>
    </Suspense>
  );
}

To synthesize this info, one way you can synchronize the Number and Letter components in the initial example is with an async generator component which somehow unmounts the async components, so that the concurrent renderings can again be synchronized.

let i = 0;
async function Number() {
  await new Promise((resolve) => setTimeout(resolve, 2000));
  return <div>{i++}</div>;
}

const letters = "abcdefghijklmnopqrstuvwxyz";
let j = 0;
async function Letter() {
  await new Promise((resolve) => setTimeout(resolve, 3000));
  return <div>{letters[j++ % letters.length]}</div>;
}

async function *Together({children}) {
  for await ({children} of this) {
    yield null;
    yield children;
  }
}

function *App() {
  const handleClick = () => this.refresh();
  while (true) {
    yield (
      <div>
        <button onclick={handleClick}>Refresh</button>
        <Together>
          <Number />
          <Letter />
        </Together>
      </div>
    );
  }
}

The async generator component makes sure all its children render at the same time by unmounting and remounting its children so no enqueuing behavior occurs. However, this has the unfortunate side effect that the component is cleared of all DOM nodes whenever it updates. You can use special Raw element tag to circumvent this problem, but it’s still somewhat awkward.

async function *Together({children}) {
  let node;
  for await ({children} of this) {
    if (node) {
      yield <Raw value={node} />;
    }

    node = await (yield children);
  }
}

The truth is, there currently is no way with Crank to both render the previous value and break diffing so the components unmount and remount to prevent async siblings from tearing. The use of the Raw tag is somewhat icky, insofar as the components would be unmounted and any event handlers or timers would be erased, which might be what you want, though not necessarily.

Ultimately, to implement something like React’s SuspenseList and siblings which coordinate with each other, Crank probably needs one more API change which allows async children to render but also defer the commit of that rendering until something else happens. I’ve recently thought about this.schedule callbacks returning a potential promise, much like I plan on allowing this.cleanup callbacks to return a promise as a way to do async unmounting, but I’m not sure of anything yet. I’ve been avoiding working on this stuff because any time I do promise stuff I want to rip my hair out.

In any case, I think I’m on the right track, and I can’t stress how much easier it is to just be able to await promises in components, without a caching requirement. I think the coordination stuff is a nice-to-have which can be added later, and in the meantime you get async SSR today. Like literally today, without compromise, and I didn’t have to do anything special on the renderer side of things.

Ultimately, I think React’s approach of providing framework provided components like Suspense and SuspenseList is brittle. What if you only want loading states to appear for the first rendering? What if you want a second fallback to appear after 10 seconds to indicate the servers are not responding? You could add these as options to the props, but I think these “what ifs” indicate that there needs to a lower-level API, even if Suspense solves the 90% use-case. My argument is that allowing functions to be async functions or generators with the behavior I described is the primitive operation we need. I was very happy that Crank more or less allowed you to define the Suspense component in user-space, and I promise you all of SuspenseList will be implementable with some slight API tweaks soon.

It's great others are pursuing incremental progress. I used to get distracted by what "pundits" say and feel it's important to participate in the conversation. But if Jordan was busy convincing the influencers in 2012 instead of working on his vision, we'd still be doing MVC.

https://twitter.com/dan_abramov/status/1301289346541260805

Amen.

[brucou]

@brainkim @ryansolid I somehow was not notified of this answer so only discovering it now... Thanks for a detailed answer Brian. Looking forward to SuspenseList with Crank. I was however intrigued by the async SSR comment though. I still have to read ryan's article on isomorphic rendering: https://indepth.dev/the-journey-to-isomorphic-rendering-performance. Will then compare the approaches.

[ryansolid]

Yeah I didn't see this either and only saw the notification when you responded. To be fair in the article I only touch on using the placeholders as a mechanism to distribute loading responsibility during streaming and to break apart hydration. You can achieve this without concurrent models. The article actually if anything highlights how much harder Solid's granularity makes things in this particular scenario as while it has incredible performance capabilities it can introduce too much overhead in an environment that doesn't have something expensive to deal with like the DOM. I had to dig deep to try to reconcile this in a way that I could keep the same client code yet gut all the dynamicism in the server yet maintain predictability.

The one thing I suppose Crank and Solid have in common here is the use of primitives (mind you Solid's are man-made) don't require special consideration around caching. In the granular reactive approach caching is built in by virtue of these reactive nodes (they are always caching) so modeling the problem is matter of connecting the dots. You don't need to cache in generators either because JavaScript runtime holds on to the context.

After reading the recent article about how @brainkim created Crank I see a lot of parallels. When you can build your whole renderer, whole everything off primitives it is a very different almost freeing approach to designing a framework. Everything becomes a question of how to model the problem. You rarely need to make new concepts. In theory anyone with these primitives could do the same thing. And any time you see a new problem you are just like "Oh, I just need to configure them this way". That runs super deep in Solid as there isn't even a VDOM, like literally everything is just a reactive computation. You could start with about an 80 line reactive implementation and just start building it out from there like I detail in (https://indepth.dev/solidjs-reactivity-to-rendering/)

.Actual concurrency was the one place I had to make an exception it turns out, but I was floating a few models of Suspense around for a year that behaved close enough to CM without having it (much closer than React without CM). I made the change really for that last 10%. I'm not sure it's necessary. I also work at MarkoJS now and we are debating over the same thing. It's really hard to pull the trigger on the complexity of bringing this in.

[brainkim]

Must have been something to do with convert to discussion that stopped notifications. My bad!

This is the article that Ryan is referring to (https://crank.js.org/blog/writing-crank-from-scratch). I detail the async component algorithms in the later sections, which might indirectly answer the original question.