Lmao, love it. #javascript

https://github.com/TodePond/C/blob/main/wallpaper_dont_upload.png

This is interesting. It looks like GitHub are using some sort of list of Mastodon instances, so when you add a Mastodon link to your profile, it automatically adds the little Mastodon icon next to it.

This is done through an API request, which makes sense. It's presumably a list because when I enter something like infoses.exchange, it responds with "unknown". #webdev

Brainstorming, re: asynchronous services in TypeDI.

There's been a proposal in TypeDI for quite a while regarding asynchronous services. Essentially, an asynchronous service is just like a regular service, but its initialisation is asynchronous (instead of just a new call).

This is largely a good idea. Consider an example of a DatabaseService: you'd most likely want it to start up when a service depends on it (as it's depending on the database), but how would you ensure that?

Currently, the only way to do that is to make a RootService which starts up your DatabaseService, waits, and then starts up anything else that relies on the database. This is really inelegant, and makes for very fragile code (and a RootService that can grow quite large).

Asynchronous services do solve this problem, but they come with unintended downsides. For instance, what if you don't *want* your DatabaseService to start straight away?
Or, what if you want a quasi weak reference to the DatabaseService, where you can use it only in certain paths (environmental variables?) but not *always*?

For those two, you'd most likely have to reach for HostContainer, which is essentially the service locator pattern. That's not an acceptable solution, IMO.

One possible solution could be buffered services. A buffered service would be just like a regular service, though you'd have a few members that would ensure the service is started before they're run.

Something along the lines of a "bufferWhen" decorator would do, which would allow the consumer to wait for (and initialise) a Promise before running the method.

You'd also need a mechanism to start the promise in the first place. Consider the example of our DatabaseService: what happens if the database isn't started, and a method is called?
It would go (roughly) something like this:
1. The method is called.
2. The bufferWhen decorator checks the buffering status of the service.
3. If false, bufferWhen starts the buffered service.
4. Once the service is started, the method is called.
5. Any subsequent calls wouldn't be buffered, assuming the service has started.

There could also be a buffered flag, to allow dependent services to check whether a call to a certain method would initiate the service.