async qualifier

[JakeIsMeh]

Currently, async components are automatically detected by the compiler, through the presence of await in the component body.

This behaviour, while convenient, may be surprising to some. For example, one may treat the component as just a variant of function, and thus assume that they still need to qualify their async component declaration with async.

Additionally, as of now, async components do not render unless they are within a try...async block, which as projects scale will make it harder to debug.

Luckily, we are a compiler, so we can easily just emit warnings as we parse, but what the default behaviour should be is still up in the air.

export component App() {
  try {
    <Test/>
  } async {
    <h1>{"loading..."}</h1>
  }
}

// works
component Test() {
  await new Promise(r => setTimeout(r, 2000));
  <h1>{"hi"}</h1>
}

// Doesn't work
// async component Test() {
//   await new Promise(r => setTimeout(r, 2000));
//   <h1>{"hi"}</h1>
// }

[trueadm]

I'm leaning towards also agreeing, but also changing the async in the try statement to be pending instead:

export component App() {
  try {
    <Test/>
  } pending {
    <h1>{"loading..."}</h1>
  }
}

async component Test() {
  await new Promise(r => setTimeout(r, 2000));
  <h1>{"hi"}</h1>
}

[ansarizafar]

In my opinion, there is no need for async qualifier. We are not using component as a function in a JavaScript/typescript file, we are using it like a Dom element. I also don't find it confusing, await keyword clearly indicates an async operation.

[leonidaz]

I was also thinking that try is not very intuitive sounding as far as awaiting for a component to resolve and not having to read in reverse, e.g. what's awaiting in the top try block seems synchronous and the second async block seems asynchronous but in fact it's rendered immediately.

So, what if we call it await instead of try and for async use nowait or some other word that indicates that it's immediately rendered. pending still sounds like it's waiting on something. Using await opens up possibilities to also use await all or await.all and other variations any, allSettled, race when working with multiple async components.

export component App() {
  await {
    <Test/>
  } nowait {
    <h1>{"loading..."}</h1>
  } catch (e) {
      <div>{'An error occurred! ' + e.message}</div>
  }
}

async component Test() {
  let x = await new Promise(r => setTimeout(r, 2000));
  <h1>{"hi"}</h1>
}

with await any:

export component App() {
  await any {
    <Test/>
    <OtherTest />
  } nowait {
    <h1>{"loading..."}</h1>
  }
}

As far as async component declaration, I think it makes a lot of sense since you could be doing some internal await's that don't actually make the component async.

[leonidaz]

and if we want to keep try how about instead using try await so at least to differentiate it from regular try/catch blocks?

[trueadm]

I actually quite like the idea of try await, for me though, the try block is the only block that makes sense. It doubles as a Suspense/Error boundary. However nowait sounds terrible, it should be pending to indicate something is happening.

[trueadm]

Or maybe:

export component App() {
  try async {
    <Test/>
    <OtherTest />
  } await {
    <h1>{"loading..."}</h1>
  }
}

[leonidaz]

I guess pending really translates to pending completion of try await render the following code.

I think try async semantically is probably better than try await, as you're trying an async operation. await is the more standard js jargon to kickoff the async operation.

For the second block, I think I'd prefer pending to await as it seems like i'm awaiting that block like it's also async.

[trueadm]

Let's maybe go with:

export component App() {
  try await {
    <Test/>
    <OtherTest />
  } pending {
    <h1>{"loading..."}</h1>
  }
}

Sounds good? Any alternatives or objections? I guess the usage of await is problematic in the sense that the component you're in isn't async, but that's the only thing I can think of.

[JakeIsMeh]

Gave it some thought. I'd like to suggest await...pending, composable with try...catch to become try await...pending...catch.

Reasoning:

• I think error boundaries should be semantically separate from suspense boundaries.
  • This gives us the possibility of rendering async components without fallbacks, without having to put void(0) in the fallback block. (Though I believe this is bugged right now)
  • Signals intent very clearly: suspend here, error boundary parent, OR suspend here, could error here.
• No change in semantics. Just like we await async functions, we await async blocks.
  • Straightforward to teach, due to little change in semantics. (aside from awaiting a scope rather than a function (but also, functions are also scopes))
• It flows well, 'directionally' speaking. Using async to "await" a suspense boundary doesn't feel nice.

edit: examples

export component App() {
  <Sidebar>
    try {
      <Page />
    } catch (e) {
      console.error(e)
      throw e
    }
}

component Page() {
  <h1>{"Header"}</h1>
  await {
    <Failable />
  } pending {
    <Spinner />
  }
  <h1>{"Footer"}</h1>
}

async component Failable() {
  const res = await fetch('unreliable.api');
  <h1>{res.text}</h1>
}

component KitchenSink() {
  <h1>{"Header"}</h1>
  try await {
    <Failable />
  } pending {
    <Spinner />
  } catch (e) {
    console.error(e)
    throw e
  }
  <h1>{"Footer"}</h1>
}

Alternatives considered:
do...await (weird and do...whiles are rarely used)

[trueadm]

Gave it some thought. I'd like to suggest await...pending, composable with try...catch to become try await...pending...catch.

Can you provide some code examples?

[leonidaz]

Sounds good? Any alternatives or objections? I guess the usage of await is problematic in the sense that the component you're in isn't async, but that's the only thing I can think of.

👍 sounds good to me.

As far as async, we could require the usage of async for any component that uses await or try await (including App in our example) inside of it to follow the JS specification. Components are actually functions.

Also, if I create functions inside components with await JS will complain that I didn't declare them with async. So, I wonder if we should stay consistent?

It does add a tiny bit of extra effort but makes the code ultimately more readable and brings it more in line with JS convention. Perhaps, various tooling can also work better in this case.

Gave it some thought. I'd like to suggest await...pending, composable with try...catch to become try await...pending...catch.

@JakeIsMeh I'm not sure I'm fully following, could you provide some code examples?

[JakeIsMeh]

export component App() {
  <Sidebar>
    try {
      <Page />
    } catch (e) {
      console.error(e)
      throw e
    }
}

component Page() {
  <h1>{"Header"}</h1>
  await {
    <Failable />
  } pending {
    <Spinner />
  }
  <h1>{"Footer"}</h1>
}

async component Failable() {
  const res = await fetch('unreliable.api');
  <h1>{res.text}</h1>
}

component KitchenSink() {
  try await {
    <Failable />
  } pending {
    <Spinner />
  } catch (e) {
    console.error(e)
    throw e
  }
}

It's not the strongest examples, but I think it should show the semantic flow quite well

[trueadm]

It's not the strongest examples, but I think it should show the semantic flow quite well

So you don't want async to be on component?

[JakeIsMeh]

hmm, hold on, let me edit the example Should be clearer now.

[leonidaz]

from your example, it would be technically incorrect because Page is async but not declared as such and then App in fact should be using try await.

export component App() {
  <Sidebar>
    try {
      <Page />
    } catch (e) {
      console.error(e)
      throw e
    }
}

component Page() {
  await {
    <Failable />
  } pending {
    <Spinner />
  }
}

What I'm leaning towards from out discussions:

• I'd require async for anything that does await (has await inside).
• for anything calling async, use try await
• for anything non-async, use try
• so just two options try and try await
• with try await
  • both pending and catch would be optional. just not sure if always to throw with no catch or if pending provided just console.log the error.
  • if no catch it would just go up to the next error boundary.
  • no pending, it would be implicit, rendering something like an empty string.

[kenwheeler]

Because the component keyword is objectively distinct I don’t think an await keyword is necessarily required on the basis that because it’s compiled, you don’t have to take on the overhead of an awaited function in the final source if awaits aren’t in the body, so perhaps it’s better implicit.

With regards to try/await syntax, I’d lobby for implementing a pattern matching some/none monad style for that.

[kenwheeler]

^ also you aren’t muddying the functionality of built ins for both of the above proposals.

[kenwheeler]

An example might be like

match (val) {
  | some => <p>{val}</p>
  | none => <spinner/>
};

But maybe there’s a better way to express it while lacking polymorphic variant types.

[leonidaz]

I've been thinking it through, and it seems we should just leave it as is. It's so flexible and there are less concepts to learn, no need to prefix components with async. The frameworks just figures out if the components should be with await or without.

We could rename try / async into try / pending or try / fallback actually may make more sense, since fallback seems like a familiar convention.

Currently, having a fallback block doesn't mean that it will ever be rendered if let's say all components in the try block as synchronous. I think it's mostly a good thing, if let's say you ever change an async component into sync. And just generally less to worry about.

Also, if someone marks component with async, maybe just disallow it since it's automatically detected.

try / async currently does not allow catch or maybe it's broken. I think it would definitely be great to have it.

I wonder if it would be possible later to make async components appear with a somewhat different color for component name in editor plugins or to show that it's async on mouseover.

[ansarizafar]

Most of the comments are based on our prior knowledge of typescript and other frameworks. A component is not a Typescript function, and we are not writing TS in a .ripple file (.rpl should be allowed)

I see it differently, In my view we are creating RippleScript or Ripple lang. A new Typescript like/compatible compiled language and we can only write it in ,ripple files even If we are not creating a component (A reuseable function with reactive variables). We can start from first principles.

I view a component like a DOM element, A container that can hold other components/elements and provide specific functionality. We don't think in terms of async or non async about DOM elements so like typescript a function can be async in RippleScript and a component can run an async function but we should not use async keyword with a component. let the compiler do the magic.

In Typescript we use await to execute an async function and try/catch for error handling. We can do the same in RippleScript there is no need to invent something new just add an optional fallback block to try/catch

	component Page() {
		try {
			const data = await getUsers()
			<UserList  {data} />
		} fallback {
			<Spinner />
		} catch (e) {
			<ShowError />
		}
	} 

Unlike other complicated and over engineered frameworks, simple and easy to understand.

[erikras]

Great discussion, guys! I like each suggestion more than the last (except Ken's 🫶). The fallback keyword feels right to my React-infested brain (tho, I like pending, too). I think the async keyword can be implied by the use of await, and therefore is unnecessary.

[devagrawal09]

Strongly agreed that components don't need to be marked async for any awaits to work inside.
Javascript requires marking functions as async because the consumers of async functions also need to await them. However Ripple components can be consumed the same way by directly placing them in JSX regardless of async or not, so there is no reason to be marking them as async. Also since the compiler can detect that automatically, it's better for the developer to not have to worry about doing this themselves.

This is one of my favorite things about Solid 2.0's async model over React and Svelte, the fact that bringing async data doesn't require marking the entire component as async. It's one less thing for the developer to add to their mental model.

As for the blocks, I kinda like try - pending - catch. Similar to try - catch - finally, the try blocks can have multiple successors, so it makes sense to allow defining both pending and catch on the same try block. However it might need different semantics in terms of delegating upwards - in regular js try-catch, if you don't add a catch block, the error is going to be ignored. But here if you have a try with a pending and without a catch, the error should be caught by the next parent try block that has a catch block. Same with pending, it should keep traversing the tree upwards until it finds a try block with a pending block, instead of silently failing at the first one.

The other alternative is that if you have a try block without a catch block, the error gets silently ignored, and the way to delegate upwards would be to catch(e) { throw e } manually. But you can't really do anything else in this catch block, as the parent's catch block is going to show its UI and ignore whatever is rendered inside this catch block. Also how do you do this with pending? There's nothing to throw there.

What about try - catch, await - pending, and try await - catch - pending? I don't really see a good reason to force the developer to add an await keyword when wanting to handle a pending state at the same level as an existing try - catch, or vice versa. Also with code folding you can collapse the contents of the try block and clearly see which fallbacks have been added under it, so an extra keyword upfront doesn't add anything in terms of readability/understanding.

[leonidaz]

i would stick with just one syntax, so it's easy to learn.

so, just the whole enchilada: try - (async / pending / fallback) - catch - finally (pending only matters on async).

pending / fallback doesn't do anything on sync calls but if you have async in the try but don't specify pending / fallback then it errors at compile time to define the pending / fallback (that's how it currently works)

down the road we can have a version of try with all, race, allSettled, any modifiers (e.g. try any, or maybe it should go to the pending any block). Haven't fully thought this through if it even makes sense.

as far as catching, it should go up the tree to the next catch if the current try block didn't provide its own.

for pending / fallback I think we should do as React does once we have SSR:

• fallback on the server, replaced by the successful try once it resolves
• if error on the server show the pending / fallback, don't rethrow and keep the fallback
• on the client, while showing the fallback, retry again. If errors again, show the try's catch block if provided or go up the tree to find the closest catch. (React doesn't have a catch on suspense)

[JakeIsMeh]

I'm still leaning towards try...catch[...finally], await...{pending, fallback}[...finally] and try await...{pending, fallback}...catch[...finally], though I'm aware that it looks weird to have use an await block without having to declare the component async.

My concern is explicitness. Yes, we can say 'the user should be aware of it', but when someone's debugging why a try...catch isn't rendering but also isn't emitting errors before they've had their coffee, it's sorta counter-intuitive. Especially if we're leaning towards not having an async qualifier for components (which I think is nice to have), as projects grow in size, the chances that you unknowingly opt into having a suspense boundary when you use a try block grow quite fast. With more explicitness, the user can convey their intention to the compiler and devtools better, which in turn, has enough information to tell the user they're holding it wrong. Maybe I'm inexperienced, but it reminds me of React vs the world in terms of opt-out vs opt-in reactivity.

I don't think any of the options brought up here are wrong, but rather which is "right" depends on how explicit Ripple wants the user to be, and I think that try await strikes a good balance (personally speaking).

Or maybe I'm not in the right mindset yet?

[devagrawal09]

@JakeIsMeh i think my proposal accounts for these. I'll restate for clarity.

• A try block has to be followed by either a pending block, a catch block, or both. Atleast one has to be present.
• If something inside a try block suspends, it is caught by corresponding pending block. If it doesn't have a pending block, it is propagated up the tree to the closest ancestor try block with a pending block. This was there are no silently uncaught pending states.
• Similarly, if something inside a try block throws an error, it is caught by the corresponding catch block, or the closest ancestor's catch block, ensuring no errors are uncaught.

This way you can't opt in-to a suspense boundary without knowing, you have to add a pending block.

With your proposal, what I am imagining is that I have an existing try catch block, I want to add a pending indicator there, I add the pending block without adding the await, and the compiler yells at me "you can't add a pending block to a try block without adding the await qualifier". This case feels very weird, if the compiler is smart enough to know I need an await, just add it automatically, why is that extra step needed?

[JakeIsMeh]

That's fair. I'm more agreeable to it in that case.

Regarding try await, I prefer it for glance-ability. It's much easier to read top down, since seeing the await keyword at the beginning of the block is enough for me to know "there's an suspense boundary here", rather than having to continue reading down to find whether its a catch or pending block.

[trueadm]

I'm going update the current try/async to be try/pending then, that's that sorted. catch should work with it too, it's bugged as to why it's not working now.

[devagrawal09]

@JakeIsMeh if you have code folding then it shouldn't be a problem. This is very glance-able.

try {...}
pending {...}
catch (err) {...}

[yamiteru]

I'd argue most frontend devs (which by extension are React devs) are used to the wording of suspense and fallback so I think this is better:

suspense {
	const data = await getUsers()
	<UserList  {data} />
} fallback {
	<Spinner />
}

Additionally I don't think that (by default) combining 2 concepts (awaiting and error catching) into 1 is a good choice.

The first reason is that it's not intuitive and obvious.

The second, arguably more important, reason is that I believe most apps have some kind of top-level error boundary instead of wrapping every suspense in its own error boundary.

So I don't think that most apps will looks like this:

try {
	suspense {
		const data = await getUsers()
		<UserList  {data} />
	} fallback {
		<Spinner />
	}
} catch (error) {
	<Error {error} />
}

[trueadm]

Resolved now, thanks for the feedback