writing a misskey client

[ghost]

yesterday i started writing a client for misskey, i've made quite a lot of progress and learned a fair bit, this being my first gui program.

i have a lot more left to do, but the basics of the home timeline are done, as is async loading of user avatars which was quite a challenge. i tried several things, including doing the async fetch before populating the gui, but in the end the best/cleanest way was to use spawn_future in my timeline factory, send a message to the parent component to update the factory data, and finally use the factory's update method to change the actual widgets.

(writing this out in case anyone googles this later)

thanks for your hard work, i'm really happy with how easy this was to pick up and how much it can do.

[AaronErhardt]

Wow, that looks awesome!

Have you read this chapter in the book? https://aaronerhardt.github.io/relm4-book/book/threads_and_async.html

It seems to me that either using an async worker or spawning a new thread with a tokio runtime could be an even better option.

[ghost]

i'm still learning how rusts async works, it's pretty new as i'm used to other languages with promises and generally more reference counting. i tried to implement it as an async worker yesterday but kept running into trouble, mainly in that i somehow made it blocking.

for now a simple approach where each avatar makes it's own http request is fine, but i'll definitely be revisiting it as i learn more.

one thing i have not yet worked out and i'm not sure if it's possible, can factories have components? I get that factories work well for simple lists and maybe not for something as complex as a twitter/misskey/mastodon timeline, but i'm not sure what the alternative is?

anyhow, that's what i'll be poking at today, more async stuff and investigating the above. here's a screenshot from where i left it last night:

[AaronErhardt]

@bunnegirl I've now added a proper feature for such a use-case. It's called message handler and should work nicely for fetching avatar images: https://aaronerhardt.github.io/relm4-book/book/message_handler.html

It's not released yet, but it will ship in version 0.1.0 that will likely be relaesed tomorrow.

[ghost]

oh that's excellent. end of last week i tried to implement my own trait to do basically this, but i was feeling a bit under the weather and couldn't quite get it working. i made a little test app for myself (https://github.com/bunnegirl/async-relm) and i'll give these changes a test now in a new branch.

[ghost]

ok, some thoughts on this approach.

if say i need to access avatars over http from multiple components, then i'd need to define multiple MessageHandler<Model>s. that means having multiple runtimes enabled for the same task. this limits it's usefulness somewhat because there's no way to say, implement a limit to how many http requests are being made at one time, nor is it possible to implement caching of those requests in a way that is shared between components.

ideally you'd define the runtime once, send messages to it, and then have a trait to translate messages from AsyncHandlerMsg to the app or component's own message type:

trait MessageUpdate<ParentModel: Model> {
    type Msg;

    fn update(msg: Self::Msg, _parent_model: &ParentModel, parent_sender: Sender<ParentModel::Msg>);
}

impl MessageUpdate<AppModel> for AsyncHandler {
    type Msg = AsyncHandlerMsg;

    fn update(msg: Self::Msg, _parent_model: &AppModel, parent_sender: Sender<AppMsg>) {
        match msg {
            AsyncHandlerMsg::DoSomething => {
                parent_sender.send(AppMsg::SomethingWasDone).unwrap();
            }
        };
    }
}

this is a complete guess at what this looks like, i'm working on 3hrs sleep. i think this would require a new type initialised alongside the app to contain the runtime and handle the incoming messages.

[ghost]

keep in mind i have no experience using relm outside of relm4, and thus no idea how these problems have previously been solved. i'm just guessing, but i will take a look at relm and see if i can find examples.

[AaronErhardt]

Regarding caching, you can actually store state in a message handler. You could, for example, use a HashMap that has the url as key and the image data as values. If the url wasn't used before the message handler will send a request and put the image into the HashMap. On the next request the HashMap is already filled and no request needs to be sent. You can find an example of a stateful message handler here.

Or you could have that HashMap in the root component and just fill it using the message handler. For sharing you could use a smart pointer like Arc.

Limiting is also pretty simple if you store state (e.g. how many requests are made currently) in your message handler. But I don't think you need rate limiting for your requests as async HTTP is pretty cheap apart from network bandwidth, of course.

If you want to send messages between components you either need to forward them through the root component or you can also create a channel for your message handler in the model of the root component and then you can share this sender with all components.

So I think what you want to do is possible with message handlers.

[ghost]

anyhow, here's the code so everyone can see the mess i'm making: https://github.com/bunnegirl/bunnieverse