Question regarding behavior of generator based components

[mcjazzyfunky]

@brainkim (or who else likes to help)

One of the killer features of Crank is something like the following (this Loader component shows a text like 'Loading...' for 4 seconds and finishes with a text like 'Finished!').

async function* Loader() {
  for await (const { loadingText = 'Loading...', finishText = 'Finished!' } of this) { 
    yield <div>{loadingText}</div>
    await wait(4000)
    yield <div>{finishText}</div>
  }
}

The problem is that by the nature of the concept this Loader component starts reloading each time some props have been changed or the parent component has been refreshed.
Now my question: When does anybody really require/want this behavior in a real world application?
Are there really any use cases where this is desired?
Do I just miss something?

Please find below two demos (I hope the demos are self-explaining).
The React Loader component behaves exactly as I would expect it to behave in real world.
The Crank Loader component on the other hand is completely useless.

React:
https://codesandbox.io/s/loving-volhard-515x8?file=/src/index.js

Crank:
https://codesandbox.io/s/jolly-architecture-o1xhv?file=/src/index.js

Does really nobody have a problem with this component behavior in Crank?
Thank you very, very much for your help.

[lazeebee]

If you change the loader component in the Crank example to the following then it will behave like the React example.

async function* Loader() {
  let rendered = false;
  for await (const { loadingText = 'Loading...', finishText = 'Finished!' } of this) { 
    yield <div>{loadingText}</div>
    if (!rendered) await wait(4000)
    yield <div>{finishText}</div>
    rendered = true;
  }
}

The reason for this, in the React example the usePromise hook runs only on the first render as it has a dependency array, so when the component refreshes, it doesn't run the promise again so it doesn't set the loading text again. But in the Crank example the promise is executed each time, so in the above code the promise is only executed on the first render.

[mcjazzyfunky]

Thanks @lazeebee
A bit interesting that after that fix, the implementation of that Crank component has actually become more complicated (at least in lines of code/characters of code) than the React version. Of course the React version is just that simple because the example itself is quite simple, but same for the fix, that fix is also just that simple because my example is that simple. In cases where the component uses several promises all depending on certain prop values and resolving some values, things are getting a bit more hairy.

@brainkim This is a good example of why I sometimes tend to criticizes a bit that currently most Crank examples do not really cover real world patterns. In the real world - at least in non-trivial applications - there's a good chance that a lot of your components have multiple props, are localizable and themeable (let's say using a css-in-js solution) and have side-effects that depend on some prop values.
They have to be prepared that in almost any moment the context value for the current theme can change or the used language or some props in general.

So this simple

yield await something(...)
yield await somethingElse(...)
...

pattern will actually in many cases not really work in this simplicity.
Maybe adding some more sophisticated examples to the Crank documentation sometime in future would be really helpful - thanks for that in advance :-)

Thanks a lot to everybody ... will close this issue now...

[brainkim]

Sorry I didn’t get to respond before it closed. One thing you could do is keep track of promises in the async generator component, and only kick off an async request if props require it. So you could do something like:

async function *Loader(props) {
  let fetchResult;
  for await (const newProps of this) {
    if (fetchResult == null || needsFetch(props, newProps)) {
      yield <div>Loading...</div>;
      fetchResult = await myFetchAPI(newProps);
      props = newProps;
    }
    yield <Result>{fetchResult.toString()</Result>;
  }
}

Essentially, with generators you get useMemo for free!

[lazeebee]

It is fixable in user land

async function* Loader() {
  let rendered;
  let value;
  for await (const { loadingText = "Loading...", finishText = "Finished!" } of this) {
    if (!value) yield <div>{loadingText}</div>;
    else yield <div>{finishText}</div>;
    if (!rendered) wait(4000).then(() => {
      value = "value";
      this.refresh();
    });
    rendered = true;
  }
}

[mcjazzyfunky]

@lazeebee Thank you very much.
@brainkim @lazeebee But it's still a bug in the Crank core that has to be fixed, isn't it?

[mcjazzyfunky]

Maybe I have to rephrase my latest sentences a bit: Whether Cranks behavior in the above mentioned case is correct or not, without any doubt there really has to be a more comfortable way to implement such use cases in Crank. Let's not forget that the React version of that Loader component can easily be written in one or two minutes and is 100% declarative and easy to read (of course given, you are familiar with the custom hook function that it is using), while the only working version in Crank that we have so far is really way more complicated. Crank claims that using generators for effectful components will make things easier... we really have to prove that.

[brainkim]

@mcjazzyfunky I’m not 100% on what you’re trying to go for on the button example. But the reason you can’t change the loading text when you’re awaiting the second promise is that the async generator is currently paused on the await and nothing Crank can do can resume it. The solution is to move the async code inside another async function like follows:

async function Finish({ finishText }) {
  await wait(4000);
  return <div>{finishText}</div>;
}

async function* Loader() {
  for await (const {
    loadingText = "Loading...",
    finishText = "Finished!"
  } of this) {
    yield <div>{loadingText}</div>;
    yield <Finish finishText={finishText}/>;
  }
}

Then, nothing in the async generator function will block and it can respond to new updates immediately.

The rules for async (generator) functions can be tricky, but I firmly believe with a little bit of engineering we can handle any advanced async use-case. I would make sure I understood what was going on in the examples in https://crank.js.org/guides/async-components before trying anything advanced.

As far as not being able to do things that React does easily; it comes at a cost of executional transparency. I guarantee you, when you have something like a useInterval or usePromise hook, your code doesn’t actually run the way you think it does in your head. Hooks make your code opaque, and while we might not know exactly how to replicate all their behavior, I’m sure we’ll eventually be able to implement a lot of functionality you find in React directly in userspace.

[mcjazzyfunky]

@brainkim Many thanks for your response. I've the feeling that often things I am saying are a bit misunderstandable and maybe sometimes a bit subtle. So please allow me trying to say things in a bit more direct way.
It's really a bit confusing to me that nobody seems to have a problem with the fact that all three tiny little React components that I've presented (the function body of that 'Metronome' component had 3 lines of code, the function body of the 'Loader' component that we are talking about at the moment had 4 lines of code and my first example with that ticker had a function body of 13 lines of code) have turned out to be remarkable challenging in Crank. It was either not very easy to make those tiny React components behave correctly or the Crank code of this components was quite a lot larger than the React version. It's really a bit ambitious to claim that pattern A is superior to pattern B if the implementation in pattern A has 23 lines of code while the implementation B has just 3 lines of code.

For example your latest proposal for that Loader component is still not working properly, moreover it needs an extra component which does not really look like an ideal solution (at least not in 2020).
And what's really concerning, is that if I interpret your and @lazeebee's answers correctly it means that in a sufficient complex component where I have a couple of props and side-effects that depend on a subset of those props, I cannot use the await keyword within the for loop in the async generator function as it will kinda "block" and will not allow that prop changes are handled properly while the promise is pending.

I’m not 100% on what you’re trying to go for on the button example

I'm trying to show the same problem that I am trying to show over and over again the last couple of days (even in my very lastest sentence I have mentioned it):

Complex real world components have multiple props that can change almost at any time. Good working components always have to handle those prop changes in a reasonable and defined manner.
Especially most side effects of the components depend on certain props (and maybe even other values). Often they have to be re-run as soon as one of the dependent props has changed and they must NOT re-run if others props have changed which are unimportant for that particular side effect.

Maybe it would have been better to ask just two little questions:

• What is Crank's answer to the second argument of React's useEffect function?
• What is Crank's anwer to React hooks?

But obviously, it seems I am the only one who's of the opinion that those two questions are very, very, very major ones. I frankly really don't get it why everybody is already talking about things like Crank tooling, Hyperscript, Chinese documentation, SSR etc. while trying to find answers to really important and by the way really, really tough questions regarding critical design decisions seem to have quite a low priority.

The other day you've told me (quote) "One thing about Crank is that you can do side-effects right in the main loop and not have to feel guilty about it".
Maybe you are right that this is a good thing... but what if not?
Again, if props change, this has often an impact on side effects. Again, they have often to be restarted then (=> see second argument of useEffect). It's really hard for me to see the advantage of everybody performing side-effects almost everywhere (s)he wants [EDIT: in an uncontrolled manner] - honestly, I just see a lot of trouble there. Also I have no clue how it will be possible in 2022 to publish "Crank Version 5.0 - the one with the fibers!" if everybody is running side effects almost everywhere ... but of course I am open for everything new - so just surprise me 😉

Again, thank you very much to all of you guys for your kind help and for taking some time for our nice discussions. I think I've understood what you've said above ... I think at least at the moment it's not important to spend more time to discuss this "less than half a dozen LOC" component :-)

[brainkim]

I’ve also signed up the repository for GitHub discussions so if you’d like to ask questions without worrying about when to close the issue you can hit up the discussions tab!