Labs Feedback: @lit-labs/task

[e111077]

The @lit-labs/task package is a package that helps you centralize your async work (e.g. fetch or database queries) and provides helpers so that you do not have to bookkeep your task's status.

• Status: Under development

• Issues: [labs/task]

• Docs: README

• npm: @lit-labs/task

Please try @lit-labs/task and tell us about your experience. Leave comments with your thoughts; highlight what issues or missing features you're blocked on; give a link to a project that uses it; etc.

And so we can have some numbers to look at, you can add reactions to this comment to indicate your experience with this package:

🚀 I have tried this package and it works great. I need it. Ship it!
👍 I have tried this package and it seems like a good idea.
😕 I have tried this package and would use it, but it has serious bugs or missing features.
👀 I am interested, but haven't tried the package yet.
👎 I'm not interested in this package.

Note: other reactions like 😄, 🎉, and ❤️ don't mean anything as part of this scheme. You probably mean, and please use, 🚀, 👍, or 👀.

[drk-mtr]

When I try and follow the README example, the this.userId property doesn't exist (I'm assuming this is meant to be this._userId).

After making that tweak, everything works, but I see the following warning in the console:

Element my-element scheduled an update (generally because a property was set) after an update completed, causing a new update to be scheduled. This is inefficient and should be avoided unless the next update can only be scheduled as a side effect of the previous update. See https://lit.dev/msg/change-in-update for more information.

I'm not sure whether this is something I'm doing wrong, whether it's expected behaviour etc. Just let me know if you'd like me to raise a bug with proper repro steps. I'm using the template that results from doing npm create vite@latest rather than the lit starter template, so it's probably just user error.

[e111077]

Great catch on _userId will submit an update to the docs in a minute.

Here is a reproduction with a bit of modification

What you're running into is expected but might not necessary. Though this only happens on the first render which may not necessarily be much of an issue. Thanks for bringing this up, hopefully people can upvote your comment if they agree this should be changed

[drk-mtr]

Wow that was quick, thanks @e111077 !

[waldronmatt]

Hi @e111077 love this controller so far. Quick question on what the purpose is for initial task status and when might we use it for rendering? Any good use cases? I can't seem to render the contents unless I'm not calling the task.

initial: () => html`inital render`,

https://studio.webcomponents.dev/edit/XlfSrBJgu8hrptGm02hE

[e111077]

Use the second constructor to set autoRun: false good for showing a button to ask for window.navigator permissions like camera since you need user interaction to even request it like

I'll be exemplifying this in my talk on Monday

[e111077]

Heya, the video is now up on YouTube. Here's a link to the specific section where initial comes in handy

[waldronmatt]

Thanks!