On Asynchronicity in Blaze

blaze
1

Half a year ago I wrote On Asynchronicity in Blaze, where I summarized our progress of, well, making Blaze async. We made some significant progress since that time, so here’s a follow up: On Asynchronicity in Blaze (again).

Let me know what you think, and what else (async-wise) you’d like to see in Blaze! I have the following things on my list (in no particular order):

  • Support for async attribute splats, e.g…, <div {getAttributesAsync}>.
  • Some ordering of lifecycle events, e.g., Template.example.onCreated(async () => ...) would delay, e.g., onRendered.

(Oh, I’d forgot: as always, I encourage you to bump a Meteor-related thing on r/programming and r/meteor!)

5 Likes
2

I really like your blog posts, keep them coming :clap:

3

Loved this one! I hope we find a solution for awaiting components.

Maybe something in the likes of Suspense? Since we are similar in someways to what react does for rendering?

4

Thank you @radekmie ! So good that you’re working on blaze and upgrading it!

I think it’s also very good to be used and/or reused as documentation going forward in how to use the new async blaze! You’re always doing a bang-up job including both tests as well as delivering great documentation!

5

I have to admit you really got me thinking. I spent the last few days thinking about the possible API, and I don’t think it makes sense in Blaze. I mean, #let allows you to do basically everything that <Suspense> would, including granular updates. The only thing “left” is the automatic suspension of the closest one, instead of manual (i.e., using #let).

I found @svelte-drama/suspense (Svelte has only builtin #await which is basically Blaze’s #let) and… I can’t say I like it.

While I think it’d be possible to do a <Suspense>-like behavior in Blaze (i.e., bubble up the loading state up the tree), I’m not sure we need one yet. Maybe we will once more people will use async values in Blaze and they’d voice usability concerns.

2 Likes