Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feedback for discussion #338

Open
curtis-h opened this issue Nov 14, 2024 · 0 comments
Open

Feedback for discussion #338

curtis-h opened this issue Nov 14, 2024 · 0 comments

Comments

@curtis-h
Copy link
Contributor

curtis-h commented Nov 14, 2024

Proposed feature

Some feedback from implementing the CLI demo:

exports

  • PR TS transpiling into commonJs, expects a "default" export but there isn't one. Not sure if this is a bug in our build, or TS transpilation expectations, leaning towards the latter, as raw commonJs works (proven in the integration-tests)
    the built demo js has this function, which when the __esModule variable is present (which it is in our SDK build) it expects there to be a default property (which we don't have).
var __importDefault = (this && this.__importDefault) || function (mod) {
    return (mod && mod.__esModule) ? mod : { "default": mod };
};
  • the exported interface could do with some consideration, things like protocols and component functions being exported (which should be encapsulated in the relevant component or namespace). And some things that aren't being exported, like the Agent.state enum, which forces consumers to use string comparisons :(

agent.acceptInvitation(invitation);

  • if used multiple times without the optional alias it will use the same default alias. We should try to use a unique alias when none provided.

  • also this function has no return value, as a consumer I have no feedback on what functionality has run. At the very least we should improve function documentation to explain what this function does based on the type of invitation, after that we can consider informative and interrogatable return values.

Agent.start()

how much should we handle automagically? for instance currently we begin mediation on agent.start(), which forces the mediationDID requirement earlier in the flow, and prevents the user from using the Agent until mediation has begun. Personally I think mediation should be considered as a connection and created separately after the Agent has been started. We can then provide options to Agent.start() for it to handle startup features, such as checking for a saved mediator and reconnecting, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant