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

Create wrappers for most of the Node BotBuilder fluent APIs #33

Open
billbliss opened this issue Jun 13, 2017 · 3 comments
Open

Create wrappers for most of the Node BotBuilder fluent APIs #33

billbliss opened this issue Jun 13, 2017 · 3 comments

Comments

@billbliss
Copy link
Contributor

Consider the following TypeScript code:

        let msg = new msTeamsBuilder.TeamsMessage(session)
            .textFormat(builder.TextFormat.markdown)
            .text(": Retrieving incident IM10272...");
        (msg as msTeamsBuilder.TeamsMessage).addMentionToText({id: "test", name: "@nat.infra"}, msTeamsBuilder.MentionTextLocation.PrependText);

In particular, note the goofy (msg as msTeamsBuilder.TeamsMessage) cast before the botbuilder-teams addMentionToText method. If it's not there, it breaks, saying that addMentionToText is not a method of botbuilder.Message.

Which it isn't - it's a method of TeamsMessage -- but why the error? Because with the Fluent-style APIs used in botbuilder, an explicit cast back to botbuilder.Message is made with every method call (in this case, to .textFormat and .text).

The only way around this, I think, is to create wrappers for all the fluent calls in the TeamsMessage.js library which calls super. That way the objects aren't cast back to the superclass type on every method call of botbuilder.

As it stands now, this is completely mysterious and makes the SDK harder to use.

@iceNuts
Copy link
Contributor

iceNuts commented Jun 14, 2017

Thanks Bill, let me figure out. I think this is a very important finding which has to be fixed.

@RamjotSingh
Copy link
Member

@BillZengMSFT Are we still tracking this?

@iceNuts
Copy link
Contributor

iceNuts commented Sep 20, 2017

yes we do but I am just too busy to prioritize it

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

3 participants