SuspenseList RFC

[brucou]

Alright, this is a work in progress and the idea is to log my mental peregrinations here. When it is done, I'll update the status.

Problem description

We want to address the case where some elements are related logically, and that relation impact the order in which they should be displayed to an user. For instance, we have a list of items that are fetched remotely, and we want the items on that list to appear in some consistent order as they appear in the document source:

Source:

<Item1/>
<Item2/>
<Item3/>

Possible display sequence:
t0:

<Item1/>

t1:

<Item1/>
<Item2/>
<Item3/>

The following display is not desired at any point of time (item2 cannot be displayed before item1 is):
tX:

<Item2/>
<Item3/>

This has obvious inspiration in terms of specifications from React's SuspenseList. The React version have more options (like displaying in reverse order) but for now we won't include that in our specifications.

The rationale here is that ordering the display of logically related items improves user experience. For the nitty-gritty details, there.

Modelization

Our problem is one of scheduling or orchestration. On the one hand we have components that can produce content (e.g., HTML) at arbitrary times for a finite number of times. On the other hand, we need to orchestrate the display of content produced by the components, so that an ordering relation is satisfied.

The content produced by a list of n components can be described with HTML(i,j) where i <= n refers to the ith component in the list, and j refers to jth production of a component. We need a function that, given what has already been produced, when something new is produced, then it produces ordered content (i.e. satisfies an ordering relation).

What has already been produced can be described by an array of (i,j) (let's call it PAST). What is produced is another array of (k,l) (let's call that PRESENT). The following property exists always: for each (k,l) in PRESENT, and j in PAST with (k,j) in PRESENT (k,l) > (k,j) when applicable --- in other words, the lth production of component k comes after the jth, or, the present comes after the past. Then a function order must produce from PAST and PRESENT another content list to display. Let's call that list ORDERED. We have order(PAST, PRESENT) = ORDERED.

A very common case is a list of components which only ever produce content twice (initial fallback content, and final content computed from some remotely fetched resource) or once: static content. A common ordering function allows to display static content always and immediately, while displaying non-static component in increasing order. The ordering function can in general be anything, and should be provided by the user of the API. However common ordering functions should also be provided for the API user to reuse.

Proposal

With those semantics defined, we are left with the problem of actually implementing a mechanism to index the components of the list, index the production of a given component, and then display the ordered content that is computed.

To index component of the list, we propose to use a component SuspenseList that wraps around all the components to display in an orderly fashion. The index used for a component will be that of that component in the array of children components of the SuspenseList wrapper:

<SuspenseList>
    static content
    static content
  <RemoteFetch1 />
    static content
  <RemoteFetch2 />
  ...
</SuspenseList>

Here RemoteFetch1 appearing first, has index 1.

For the communication of the production of a component, we propose either:

• use events that will be captured by the SuspenseList
  • this involves determining propagation rules (for instance in case of nested SuspenseList, event should be received only by the closest SuspenseList?)
• injecting a yieldP property into every participating children. The children can then yield their content directly to SuspenseList.
• bake in the SuspenseList in Crank so that API users can use standard JS yield and Crank takes care of propagating anything yielded to the closest SuspenseList, if any.

Using event

TODO: analysis of the three possibilities? any other?

• need to discriminate the components that are not static from those that are

  • use a Suspense component

• need to emit an event that carries the index of the emitting component with it?

• need to decide the name of the event?

• inject a property emit, or resolve or whatever that will directly send to the SuspenseList parent.

• the event is sent on reception of the remote resource (synchronously or not? to think about when the this.refresh should happen). The component with the remote resource yields as usual. The yielded stuff will be picked by this.refresh()

Crank does not allow components that emit multiple times. This would require a push-based iterator, i.e. a stream! So instead of async generator creating iterators that return promises when called, we need observables generators, that create hot streams that emits on their own and trigger refresh on their own. Well I think anyways. Not sure.

I'll use the example here from React:

...
const resource = fetchProfileData();
...
ProfilePage = 
    <Suspense fallback={<h1>Loading profile...</h1>}>
      <ProfileDetails />// The code is that accesses resource that is in closure...
      <Suspense fallback={<h1>Loading posts...</h1>}>
        <ProfileTimeline />
      </Suspense>
    </Suspense>

We recommend to use also a <Suspense/> component but no fallbacks. The Suspense component will handle the state of some asynchronous processes (for instance, started, pending, timeout, error, success...), pass that state as a props of its children and refresh every time that state changes. So we would have:

updateProcessStateFactory = (component, processState) => value => { processState.state = value; component.refresh() }

ProfilePage = 
    <Suspense processStreamFactory=... >
      <ProfileFallback processState>
        <h1>Loading profile...</h1>
      </Fallback>
      <ProfileDetails processState/>
      <TimelineFallback processState>
        <h1>Loading posts...</h1>
      </TimelineFallback>
      <ProfileTimeline processState />
    </Suspense>

Observe as there is no need to nest Suspense components. Suspense is managing a stream, and coordinating with children via props. We need a suspense component PER STREAM (i.e. per resource in the React example).

The Suspense component works that way:

• when run the first time, it creates a stream from the stream factory and subscribes to that. Every time a value is received, that value is emitted through the event emitter. Note that there may be complications if the stream emits synchronously -- should probably defer to the next tick. TO THINK ABOUT. It yields its children (all the time)
• when run other times, it yields its children.
• when the Suspense component is destroyed, the stream is unsubscribed to.

Its parameters:

• processStreamFactory = (...) => {
  return a stream that starts some async. process and emits both control state of the process in flight and data. For standard fetches, this is a simple state machine with a few states. cf. Svelte Suspense
  }

TODO:

• check that it wouljd work in principle
  • the Suspense component has no way to pass processState to its children...
    • Use a provision??
    • use a parent component on top of Suspense and add updateState parameter to Suspense to trigger this.refresh of the parent component? Then I also need a processState parameter for the Suspense component to trigger the refresh of that component
• move on to SuspenseList... The Suspense needs to be autonomous without SuspenseList, and if a SuspenseList it needs to communicate with it... So instead of updateProcessState send an event that bubbles to the closest SuspenseList, and if no such thing, it works too? TO THINK ABOUT

NOTE:
Therefore, the children prop should be treated as a black box, only to be rendered somewhere within a component’s returned or yielded children. Attempting to iterate over or manipulate the passed in children of a component is an anti-pattern, and you should use event dispatch or provisions to coordinate ancestor and descendant components.

[brainkim]

@brucou Thanks Bruno for opening this discussion. Here’s a braindump of what I think we need for SuspenseList parity.

What we have so far

Currently, we have async components (via async functions and generators) and the ability to implement the Suspense component in user-space. If you’re not familiar with how this works, check out the guide on async components and the blog post on writing Crank from Scratch, in particular, the sections on implementing async function and generator components. To recap, we use async generator functions as split points for racing concurrent renderings of element trees, and we use the async strategies of enqueuing and chasing to ensure that components are kept up-to-date with their latest props. Therefore, React’s Suspense component can be implemented with an async generator in user space.

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

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

This implementation notably differs from React in that props aren’t cached in any way. If this Suspense component is rerendered, the loop will resume, meaning that the children of the Suspense component will be unmounted and remounted, so, unlike React, you can’t just blindly rerender a Suspense component and expect it to preserve child state intelligently.

This also hints at the sole mechanism for “async coordination” in Crank as of today, which is that each element will wait for all descendant async components to fulfill at least once before rendering to the DOM. Once this has happened however, all bets are off, and async components rerender independently of siblings according to the enqueuing mechanism. If you want async child components to rerender together, you must unmount all of them, so that the same async coordination process can begin again.

Implementing SuspenseList

I don’t want to implement Suspense or SuspenseList as special elements defined by the framework, because I’m not sure their APIs are in any ways the most ideal. Moreover, they feel “composite” as opposed to “atomic” – props like fallback from Suspense, and revealOrder and tail from SuspenseList seem to indicate the composition of multiple rendering primitives. By contrast, the special element tags which Crank does define feel necessary; subjectively speaking, I think fragment, portal, copy and raw elements all seem to require special renderer handling and feel “primitive,” though I don’t really know if I can formalize this intuition. In any case, I would like to make an effort to implement APIs which allow SuspenseList to be implemented in user-space rather than implementing it at the framework level, if only because it would allow for potential competing APIs to SuspenseList which might be more ergonomic, or make more sense to developers.

I initially assumed that we would be able to implement SuspenseList in user-space just with Crank’s async abilities in conjunction with provisions, but we’re a missing piece. Here’s a mockup of what I initially thought would work.

const SuspenseControllerKey = Symbol.for("SuspenseControllerKey");
export function *SuspenseList({revealOrder, tail, children}) {
  const controller = new SuspenseController(revealOrder, tail);
  this.provide(SuspenseControllerKey, controller);
  for ({revealOrder, tail, children} of this) {
    controller.prepare(revealOrder, tail);
    yield children;
  }
}

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

export async function *Suspense({timeout, fallback, children}) {
  const controller = this.consume(SuspenseControllerKey);
  this.provide(SuspenseControllerKey, undefined); // hide the controller from children
  for await ({timeout, fallback, children} of this) {
    // technically we need to handle Suspense components rendered outside SuspenseList but for now we’re not gonna worry.
    const i = controller.getIndex();
    await controller.fallbackReady(i);
    controller.sendFallback(i, yield <Fallback timeout={timeout}>{fallback}</Fallback>);
    await controller.childrenReady(i);
    controller.sendChildren(i, yield children);
  }
}

This pseudo-code describes a SuspenseController which is given a revealOrder and a tail, and assigns a unique index (probably just an integer) to every direct Suspense descendant. We wait for the SuspenseController to tell us that we can render the fallback/children for each Suspense component, and we then do the normal yielding of elements, except we pass the result of the yield operation from the Suspense component into the controller along with the index. We’re taking advantage of a poorly documented feature of Crank, which is that when yielded children in an async generator component are themselves asynchronous, the value which is passed back in is a promise which fulfills when the children fulfill.

The problem with this implementation is that it has limited concurrency. Each Suspense component cannot yield its fallback or children until the SuspenseController is ready, meaning each Suspense component must wait for its antecedent sibling before it even begins the process of rendering its children. This is non-ideal, but I could not for the life of me figure out how to both defer the rendering of the Suspense component’s children and have that rendering process kick off concurrently. Furthermore, if you were to attempt to implement revealOrder="together", this implementation would almost certainly cause a deadlock, where no Suspense component could render its children before another.

The missing piece I alluded to earlier is a solution to this problem. Ideally we would have some kind of way to have the Suspense component render, but avoid inserting the newly created DOM nodes into the live DOM until some other moment. My idea after a lot of rumination is to allow the callback passed to the schedule() method return a potential promise, which, until settling would hide a component’s DOM nodes from its ancestors. This API might also be valuable for other use-cases, and it would rhyme with the planned implementation of async unmounting, where a callback to cleanup() can return a potential promise to defer the removal of DOM nodes from the tree. The Suspense component could then be potentially refactored to the following.

export async function *Suspense({timeout, fallback, children}) {
  const controller = this.consume(SuspenseControllerKey);
  this.provide(SuspenseControllerKey, undefined); // hide the controller from children
  for await ({timeout, fallback, children} of this) {
    const i = controller && controller.getIndex();
    controller && this.schedule(() => controller.fallbackReady(i));
    yield <Fallback timeout={timeout}>{fallback}</Fallback>;
    controller && this.schedule(() => controller.childrenReady(i));
    yield children;
  }
}

Now, each Suspense component sibling can execute in parallel, and defer the mounting of its children until its antecedent sibling has fulfilled. Note that we also don’t need to implement sendFallback() or sendChildren() methods, because calling fallbackReady() or childrenReady() is now enough to notify the controller that the specific Suspense component’s children has fulfilled, because the schedule() callback is only called after the component’s children have finished rendering. This feels like an elegant solution to me.

Implementation

Async schedule() and cleanup() callbacks will be implemented soonish, because I think it’ll be useful for other reasons besides SuspenseList and potentially make Crank’s API more powerful than any other framework’s with regard to promises and asynchrony. Unfortunately, I’ve been busy working on other things and haven’t set some time aside to implement it, and working with promises is incredibly difficult, especially given the high degree of asynchrony which Crank already has. It honestly might take a month to work out all the kinks which appear in the form of race conditions.

I also am not 100% certain that the controller.getIndex() stuff would work as expected. We need to consider, for instance, Suspense components which appear as the children of async components. If the getIndex() call is deferred because of some promise, the call would provide an index out of tree order, which is not what we want. We might need to cut off any getIndex() calls which happen after a zero-length setTimeout() call, to make sure that only Suspense component registrations which occur in the same microtask loop are used.

Even if we do that, I’m not sure that the above code will call getIndex() in tree-order in complex cases anyways. I need to confirm that rendering happens in tree-order even when performing complex nested async component calls. An alternative approach might be to do what React is doing, and only coordinate Suspense components which are direct children of the SuspenseList component. This might involve some kind of prop-injection mechanic. I’m not a fan of this approach because I typically don’t like components or JSX patterns which limit the ways in which you can compose element trees. To me, the limitations described by React warnings for SuspenseList (facebook/react#16094) seem damning.

Allowing schedule() callbacks to be async also has ramifications for the framework as a whole. So far, I’ve prided myself on the fact that Crank preserves synchronicity for sync components. However, if there is a mechanism for anyone with access to a component context to make that component defer insertion of its DOM nodes into the parent, we have to deal with the ramifications. At the very least, we have to consider this as a breaking change for the framework.

Ultimately, I think it’s fine for components to only be able to guarantee that their own child DOM nodes are created when schedule() callbacks are called, and not guarantee that these DOM nodes are in the live DOM, but there are also important situations where you need to fire callbacks when a component is inserted into the live document element, like when you need to use getComputedStyle() for instance. We might need another callback for that use-case, if we go with the async scheduling route. It would also mean that we get to batch arrange() calls on component host elements, which would solve an important performance footgun, where multiple children immediately refresh after mounting (#155). Need to do more thinking about this but I think I’m close to feeling confident that this is the right way forward.

[brucou]

I'll anwer to that more in details. But:

This also hints at the sole mechanism for “async coordination” in Crank as of today, which is that each element will wait for all descendant async components to fulfill at least once before rendering to the DOM. Once this has happened however, all bets are off, and async components rerender independently of siblings according to the enqueuing mechanism. If you want async child components to rerender together, you must unmount all of them, so that the same async coordination process can begin again.

That is what has been confusing me for some time so I am happy that you clarified it with this comment. So, assuming P, C1, C2 are all async components to be more general, lets suppose that P produces C1>...<C1/><C2>...<C2/>. This implies the following process for rendering (not committing) of P:

• render P -> promise0
• render C1 -> promise1
• render C2 -> promise2
• [promise 1, promise2] --fulfills-> promise 0 fulfills with vDOM from P, C1 and C2

Later on, C1 and C2 can independently (this.refresh) generate future vDOM on their own independently of each other, but also of P is that correct?

Second question:

• what happens when P rerenders (with this.refresh) when:
  • C1 or C2 are called with the same parameters?
  • C1 or C2 are called with different parameters?
• what happens when P rerenders (due to P's parent)?

PS: I have read a couple of times a month ago or so https://crank.js.org/blog/writing-crank-from-scratch but I was lost somewhere around the middle of the expose, I will have a third look again this week-end.

[brainkim]

Later on, C1 and C2 can independently generate future vDOM on their own independently of each other, but also of P is that correct?

For the initial render, the renderer will only insert P’s DOM nodes (which are also the concatenation of C1 and C2’s DOM nodes) when both C1 and C2 fulfill for the first time. If P is rendered again, we go through the same process, except if the children render the same root DOM nodes, these DOM nodes are updated as the child components resolve, without regard for any other siblings.

function Parent() {
  return <><Child1 /><Child2 /></>;
}

// Globals are for demonstrative purposes.
let i = 0;
async function Child1() {
  await new Promise((resolve) => setTimeout(resolve, 1000));
  return <div>{i++}</div>;
} 

let j = 97;
async function Child2() {
  await new Promise((resolve) => setTimeout(resolve, 500));
  return <div>{String.fromCharCode(j++)}</div>;
}

await renderer.render(<Parent />, document.body);
// renders <div>0</div><div>a</div>
await renderer.render(<Parent />, document.body);
// renders <div>0</div><div>b</div> after Child2 fulfills
// renders <div>1</div><div>b</div> after Child1 fulfills

This behavior occurs because the DOM nodes are already in the live document. Neither Child1 nor Child2 have knowledge of sibling component executions so they simply update the DOM nodes they control, independently of each other. By contrast, if Child1 or Child2 rendered different DOM nodes than were previous created, like if it returned a div in the first render and a span in the second, then the insertion of these new DOM nodes would again be deferred to the point when all children have fulfilled, because the linking of parent and child DOM nodes is still deferred to the fulfillment of all the parent’s children. Maybe this behavior is surprising, I‘ve personally found it to work predictably when you make sure to lift asynchrony as high up in the tree as you can.

If C1 or C2 refresh independently of each other, they will independently cause their DOM nodes to be rendered, regardless of when their siblings resolve. This is because the last step of a refresh() call is to find the ancestor host element and update its children according to the current state of the element tree. We call this process arranging or rearranging in the codebase and literature.

The reality is, if you have an element tree like <P><C1/><C2/></P>, all of the components in this tree have the same ancestor host element, so refreshing any of these components will cause the ancestor host element to be rearranged. Therefore, it’s very unlikely that any suspense-like mechanism would be able to coordinate components independently refreshing.

what happens when P rerenders when:

• C1 or C2 are called with the same parameters?
• C1 or C2 are called with different parameters?

In all situations, the rendering of C1 and C2 happen independently upon rerender. Depending on whether C1 and C2 have fulfilled, another async execution is called immediately, or the async execution is deferred until the pending async execution resolves. Because the tags of the elements, AKA P, C1 and C2 remain the same, all components will follow the enqueuing strategy described in the Crank from Scratch blog post.

On the other hand, the only reason Suspense works in Crank is that we render different tags in the same position, which causes the different subtrees to be raced via the chasing strategy. The consequence of this is that the Suspense component will forcibly unmount and remount its children elements every time the component rerenders. This means that stateful child components would be reset, and DOM nodes are blown away and recreated for each Suspense update. Ironically, this might mean that any Crank Suspense implementation would have to be coupled with a cache, but at the same time, I still prefer the ability to implement this explicitly, and of course, without throwing promises.

This also hints at a limitation of the proposed Suspense and SuspenseList parity plan and async schedule() callbacks, which is that it only prevents the insertion of new DOM nodes, not the mutation of DOM nodes which already exist in the tree. Given the current definitions of async components, it’s not likely that we’ll be able to “freeze” element trees so that DOM props or nested children can change without those changes being reflected in the DOM. Because Suspense works based on the insertion and removal of DOM nodes, it will only ever work if we recreate the tree each render, which is non-ideal. It would be nice if we could have some sort of continuity/state preservation between renders, but I haven’t really thought of a way to do that yet.

All in all, lots to think about, lots to explain, but I remain confident that Crank is further ahead with regard to async rendering than any other framework out there, and even if I dilly dally I’ll probably still be able to ship this stuff before Concurrent Mode is ever released officially

PS: I have read a couple of times https://crank.js.org/blog/writing-crank-from-scratch but I was lost somewhere around the middle of the expose, I will have a third look again this week-end.

If you have feedback about what was unclear, I’d love to hear it. Any editing help is appreciated given that it’s like 10,000 words and I haven’t had the energy as of late to reread it.

[brucou]

I am sorry, I had a typo in my question. P, the parent component renders as <C1/><C2/>. Meaning there is no <P><C1/><C2/><P/>. Also when I said async components, I meant async generators (C1 and C2). Then this:

what happens when P rerenders when:

C1 or C2 are called with the same parameters?
C1 or C2 are called with different parameters?

is about knowing whether you rerun the generators (thus recreating iterators from scratch) or you iterate the iterator you already have. My understanding is that if C1 or C2 are called with the same parameters the async generator component should not be rerun. In the other case, it should be.

[brainkim]

Async generator components hitch, async function components enqueue. We use hitching for async generator functions because they’re constantly resuming, and trying to use enqueuing has caused strange deadlocks in testing. This might mean that when the async generator component settles, it won’t have responded to the latest props yet. Async generator components can only guarantee to have rendered something rather than a tree which reflects the latest props, but this usually doesn’t matter because the async generator component will inevitably render again. At some point I think it might be nice to write some logic like having the async generator components settle only after props have been pulled from the async iterator, but I haven’t gotten around to implementing that logic yet.

[brainkim]

I tried to simulate that in the dev tools with the Network tab (slow3G) and I lost one button click, i.e. the application only processed two buttons clicks.

The child component doesn’t read props, so it’s unclear how you might have lost a click. When all promises settle, you are guaranteed to have an element tree which reflects the latest props. The problem for async generator components is that, because they hitch, there are some edge cases where render() or refresh() fulfills earlier than the entire tree settling.

[brucou]

You can see it here:
.

Three clicks, two requests. Actually you won't see the three clicks they are too fast for the recorder app. But the network tab shows the requests

[brainkim]

We can’t guarantee that the component loop will run exactly the same amount of times as it was rerendered (for async components). Doing so would be a memory leak for a sufficiently slow or hanging component. We only care about the “latest” props which have been passed. The RandomDog example doesn’t exactly demonstrate this because it doesn’t respond to props.

PS you should upgrade the crank version to latest (0.3.7). 0.3.4 fixed a Suspense fallback bug if you’re experimenting with async stuff.

[brucou]

upgraded

[brucou]

@brainkim Thanks for taking the time to write all these explications. I am keen on writing some extra docs (assuming I did figure out correctly how Crank works). The truth is the information is probably already there but it would be more a question of proposing a different organization. Not sure yet what form that would take (could be a tutorial, an how to, or could be a concept link).

That aside, I am still in the process of formalizing some semantics that would be general enough to comprise any kind of scheduling. More later on that.

[brucou]

Brian apologies, it's been a while. Let me quickly write my ideas here otherwise I will never do it if I wait to perfect them before writing them.

1. There are two concurrent things happening in Crank component trees

• what I call horizontal concurrency is happening on the time axis on a single component. That component may for instance produce a promise that contains a future DOM tree. Every run on this component possibly produces a concurrent DOM tree, and you need a strategy to select which DOM tree to use.
• What I call vertical concurrency relates to parent and its children. A parent component must produce DOM trees based on its own specifications and the production of its children. When we talk about Suspense, ordering, and all that, this is the strategy by which a parent determines its production from the production of its children.

So my idea was to have those two concurrencies appears at the API level in the shape of a parameter that would default to the current Crank behavior. So the user would only use this parameter for infrequent customizations such as Suspense.

Vertical concurrency:

• <P scheduler=your sheduling strategy here> <C1><C2> </P>
  • that is the most complex thing to implement I assume. You have two cases:
    • the tree does not change. I mean the component tree, not the DOM tree assembled from the production of the components. In this case, you can apply some ordering, e..g wait for the first production of C1 before displaying the first production of C2 etc.
    • the tree does change
      • <P scheduler=your sheduling strategy here> <C1><C2> </P> and then later at a P refresh time
      • <P scheduler=your sheduling strategy here> <C3> </P> (note that we should forbid the scheduling strategy to change here in order not to complicate it even more)
      • In this case, I believe your racing strategy is a good default, e.g. show C1 and C2 if they complete first, and then C3. Optimally there should be a way to let the user configure this behavior in the form of a scheduling strategy. It does not have to be easy, as there will be not a thousand interesting behavior, maybe max 3, and smart people can do that for the rest of the users to use without thinking.
        • for instance you could transition smartly from C1 C2 to C3, waiting for C3 to produce content (or a min. time) to remove C1 C2 from screen) --- another version of Suspense that can be applied when transitionning between tabs
        • thinking about it, maybe there two parameters here, one scheduler as here, and a new one, transition for the transition strategy corresponding to tree changes.
      • note that case when P itself is replaced by let;s say Z is already handled here. (Z = C3 for some parent of P)

Horizontal concurrency:

• <C concurrency=your concurrency strategy here/>
  • in Rxjs, you have flatMapFirst, flatMap, flatMapLatest, concatMap and some other time-windowed concurrency operators that could give some inspiration. The Crank default if I remember well is flatMapFirst or close to, e.g. a component execution must produce a result, before another component execution happens.
  • flatMapLatest (aka switchMap) may be a valuable option for the user. Component execution are run everytime without wait, and the results of previous runs are discarded or cancelled.
  • windowed operator may be useful too, e.g. you take whatever productions of the component in a given time window.

To be able to operate, this parameter should be a function that receives all (and only) the info it needs from Crank internals. I don't remember what that is, it has been some time since I looked at the code. Maybe what I am recommending might mean some refactoring? I wonder.

Also note that the concurrency props I added have a different name would it only be because a parent can be a child to another component.

Anyways, just writing that out before another two months pass and I forget all about it.

[brucou]

trying out some mermaid format (https://mermaid-js.github.io/mermaid/#/gantt, live editor):

gantt
    title Crank horizontal concurrency: first things first option
    dateFormat  D
    axisFormat  

    section Component
    A1 :active, a1, 1, 4d
    A2      :done, a2, 2, 6d
    A3      :active, a3, 10, 3d

    section Displays
    - :done, 1, 4d
    A1      :after a1, 13
    A3      :A3, after a3, 5d

Ok, this seems to be working. If you install the Markdown diagrams extension, you should be able to see a beautiful (well...) graph instead of the markup. If you see that graph, if you double click on it you see the markdown code.

So the idea of this graph is to represent a component asynchronous production. A filled bar represent the time lapse between when a promise is created and that promise resolve to some DOM snippet. So here we imagine that we have an app that is just <Component> and that we start from an empty display (e.g., Crank runs the component for the first time). The displays section shows what is actually displays on the user screen.

That particular graph represent the default strategy used by Crank. That is that is Component is run a second time while it has not produced a DOM, then it is not run (grey colour) . As I was saying, that is a flatMapFirst strategy in RxJS.

Here is the flatMapLatest strategy:

gantt
    title Crank horizontal concurrency: latest wins
    dateFormat  D
    axisFormat  

    section Component
    A1 :active, a1, 1, 4d
    A2      :active, a2, 2, 6d
    A3      :active, a3, 10, 3d

    section Displays
    nothing :done, 1, 7d
    A2      :after a2, 13
    A3      :A3, after a3, 5d

Next strategy flatMap:

gantt
    title Crank horizontal concurrency: as it comes
    dateFormat  D
    axisFormat  

    section Component
    A1 :active, a1, 1, 4d
    A2      :active, a2, 2, 6d
    A3      :active, a3, 10, 3d

    section Displays
    nothing :done, 1, 4d
    A1: after a1, 3d
    A2      :after a2, 13
    A3      :A3, after a3, 5d

Other Crank default mergeLatest:

gantt
    title Crank horizontal concurrency: as it comes latest
    dateFormat  D
    axisFormat  

    section Component
    A1 :active, a1, 1, 4d
    A2      :active, a2, 2, 6d
    A3      :active, a3, 4, 3d

    section Displays
    nothing :done, 1, 4d
    A1: after a1, 2d
    A3      :A3, after a3, 5d

Those strategies show that for the same productions of components, the application can choose several ways to compute the screen. Other time-based strategies could be debouncing or throttling.

Implementation-wise, maybe this could work as follow. The parameter in <C concurrency=f/> could receive a list of promises and return one promise that is the intercepted production of the component.

So flatMapFirst strategy would be:

• C first run: f(promise 1) -> promise 1 (only one promise in array -> return that)
• C second run: f([promise 1, promise 2]) -> return promise 1
• C third run: f(promise 3) -> promise 3 (only one promise in array -> return that)

flatMapLatest strategy would be:

• C first run: f(promise 1) -> promise 1 (only one promise in array -> return that)
• C second run: f([promise 1, promise 2]) -> return promise 2
• C third run: f(promise 3) -> promise 3 (only one promise in array -> return that)

The framework takes care of maintaining an array of concurrent promises, and passing that to the concurrency function everytime the component refreshes or is started the first time. Don't know if that's actually possible just thinking out loud. It may instead to work with () =>promise instead of promises directly if you want not to even run some production --- as in default flatMapFirst.

[brucou]

I have to think more about vertical concurrency, but it seems simpler that I originally thought. The case when <P scheduler=g> <C1><C2> </P> switched to <P scheduler=g> <C3> </P> is actually a case of horizontal concurrency (where the default is as-they-come-but-latest, and the concurrent productions are P(C1 C2) vs.P(C3)). The case when C1 and C2 do not change, but they produce new values may be solved by running the scheduling function every time a new Cx value/promise is produced with the full list of latest production of all children. That is like a combineLatest in RxJS. But I have to think some more about it to see if that actually may work.

• P first run: g([promise 1, promise 2]) -> return orderedRace([promise 1], [promise 1, promise 2])
• if C1 or C2 refreshes (is that possible? they haven't produced anything yet), then g needs to rerun. That is the confusing part for me, I believe that in Crank, child refreshes are independent of the parent.
• orderedRace(orderedProductions) -> orderedProductions.reverse().find(productionX => productionX.every(promise => isResolvedPromise(promise)) ) or sth like that. The idea is to pick the array of promises that have all its members already fulfilled. Here we want the largest of such arrays.