The more I work on #ONI, which is basically a web components frontend for an as basic as possible #ActivityPub client to server service, the more I realize I'm just not built for JavaScript programming.
-
The more I work on #ONI, which is basically a web components frontend for an as basic as possible #ActivityPub client to server service, the more I realize I'm just not built for JavaScript programming.
Despite having put in the hours every day for a number of months, the whole Promise paradigm just doesn't seem to click for me.
Now I'm struggling to create a throbber component (easy) while fetches happen in the background (easy) and then have it replaced (not easy) by actual content (easy).
Gaaah!!! -
The more I work on #ONI, which is basically a web components frontend for an as basic as possible #ActivityPub client to server service, the more I realize I'm just not built for JavaScript programming.
Despite having put in the hours every day for a number of months, the whole Promise paradigm just doesn't seem to click for me.
Now I'm struggling to create a throbber component (easy) while fetches happen in the background (easy) and then have it replaced (not easy) by actual content (easy).
Gaaah!!! @mariusor FWIW, I'm working on a similar thing, and I've settled into a pattern like this - the component has a spinner, a viewer, and a no-data message, then have a dataBind() method like:
```
dataBind(data, binder) {
if (data) {
this.#spinner.style.display = 'none';
this.#viewer.style.display = null;
this.#noData.style.display = 'none';
} else {
this.#spinner.style.display = 'none';
this.#viewer.style.display = 'none';
this.#noData.style.display = null;
}
}
``` -
@mariusor FWIW, I'm working on a similar thing, and I've settled into a pattern like this - the component has a spinner, a viewer, and a no-data message, then have a dataBind() method like:
```
dataBind(data, binder) {
if (data) {
this.#spinner.style.display = 'none';
this.#viewer.style.display = null;
this.#noData.style.display = 'none';
} else {
this.#spinner.style.display = 'none';
this.#viewer.style.display = 'none';
this.#noData.style.display = null;
}
}
```@OpinionatedGeek litjs has an idiomatic way of achieving this kind of logic.
It has an `until(promise, fallback)` function which waits for the promise to resolve and display fallback until then.
Even with this simple setup I still get issues.
It's definitely a "me" problem. I'm holding it wrong somehow, but I haven't seen any examples in the wild of "holding it right".
-
@OpinionatedGeek litjs has an idiomatic way of achieving this kind of logic.
It has an `until(promise, fallback)` function which waits for the promise to resolve and display fallback until then.
Even with this simple setup I still get issues.
It's definitely a "me" problem. I'm holding it wrong somehow, but I haven't seen any examples in the wild of "holding it right".
@mariusor That sounds so frustrating! (I feel your pain. I've given up in the past on libraries/add-ons that did complicated jobs but had no docs to tell me how to use them. I love examples!)
I do like the sound of that `until()` approach. I went with an ever-more-complex databinding approach that causes me some problems with large ActivityPub objects...
-
@mariusor That sounds so frustrating! (I feel your pain. I've given up in the past on libraries/add-ons that did complicated jobs but had no docs to tell me how to use them. I love examples!)
I do like the sound of that `until()` approach. I went with an ever-more-complex databinding approach that causes me some problems with large ActivityPub objects...
Hey @OpinionatedGeek I see you're working on ActivityPub stuff, is the code public to look at?
-
@mariusor That sounds so frustrating! (I feel your pain. I've given up in the past on libraries/add-ons that did complicated jobs but had no docs to tell me how to use them. I love examples!)
I do like the sound of that `until()` approach. I went with an ever-more-complex databinding approach that causes me some problems with large ActivityPub objects...
@OpinionatedGeek I finally got a workable version, though I am not very satisfied with it.
You can see it in action on my metal releases bot/ActivityPub playground: https://releases.bruta.link/outbox
The tab at the top corresponds to the outbox collection of the actor it gets loaded in the background to show an eventual icon/name change.
-
@OpinionatedGeek I finally got a workable version, though I am not very satisfied with it.
You can see it in action on my metal releases bot/ActivityPub playground: https://releases.bruta.link/outbox
The tab at the top corresponds to the outbox collection of the actor it gets loaded in the background to show an eventual icon/name change.
@mariusor Nice! I like the way the data flows through the `it` attribute.
FWIW here's how your post looks in my C2S code. Depending on circumstances, each of the main bits (the profile picture, name, each addressee, the replied-to actor, and the content) may be demand-loaded.
-
@mariusor Nice! I like the way the data flows through the `it` attribute.
FWIW here's how your post looks in my C2S code. Depending on circumstances, each of the main bits (the profile picture, name, each addressee, the replied-to actor, and the content) may be demand-loaded.
@OpinionatedGeek nice, I like that you display explicitly the recipients.
So far everyone seems to want to paper over that whole mechanism with the "public" "followers" "mentions" model that Mastodon engendered.
