n0-computer / n0-computer/iroh-docs

Typing Ergonomics for Docs and Authors Client

Open
#20 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
74
Forks
16
PR merge metrics
No merged PRs in 30d

Description

When implementing user code that needs to type a parameter that should be either a Doc or Author Client, it currently requires adding quic-rpc as a dependency. The following example shows the current situation:

use iroh_docs::rpc::client::authors::Client;
use iroh_docs::rpc::client::docs::Doc;
use iroh_docs::rpc::proto::{Request, Response};
use quic_rpc::transport::flume::FlumeConnector;

pub struct ApplicationClient {
    // ... //
    blobs: iroh_blobs::rpc::client::blobs::MemClient,
    docs: iroh_docs::rpc::client::docs::MemClient,
}

impl ApplicationClient {
    // ... //
    fn authors(
        &self,
    ) -> Client<FlumeConnector<Response, Request>> {
        self.docs.authors()
    }
    
    async fn create_doc(
        &self,
    ) -> anyhow::Result<Doc<FlumeConnector<Response, Request>>> {
        self.docs.create().await
    }
}

Both the Doc and Blobs Clients have a special type declared to avoid having to make quic-rpc a hard dependency in user code. Could such types be created for both Doc and the Author Client?

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Read src/rpc/client/docs.rs, especially the special client type near line 43, then compare the Doc and Author Client definitions in docs.rs and authors.rs. Done means both client types can be used in user-facing parameter and return signatures without requiring users to add quic-rpc as a hard dependency.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
api
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Clearly specified
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.