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.
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
__esModulevariable is present (which it is in our SDK build) it expects there to be adefaultproperty (which we don't have).~~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.