Sample: Password input activity

[compulim]

Fix #1547 and fix #1413

Background

This sample will add a custom activity that show a password input and the content will be submitted thru postback.

The custom activity looks like:

{
  "name": "passwordInput",
  "type": "event"
}

Design considerations

Today, we are hiding activities thru a predicate function named shouldShowActivity in BasicTranscript.js. Although this approach make timestamp grouping logic straightforward, the user has no control on what type of activities will be visible. Currently, we only show message activity and bot's typing activity.

We are moving hide/show logic to activity middleware instead. So all activity middleware will be able to process all types of activity and decide which should be show or hidden.

For our default activity middleware, we will show message and bot's typing activity, and hide empty message, event, postback and user's typing. For all other unhandled activity type, they will show up as an error box.

Since custom middleware are always executed before default middleware, any new activity type should be handled by custom middleware. Middleware can choose to override visibility. For example, in this sample, the middleware has chosen to show event activity as a password input box, before sinking the activity to the default middleware, which will hide the event activity.

For this change, we are forced to group timestamp only after render complete (after middleware finish). Thus, we will need to use CSS to filter out timestamp on render time, instead of JavaScript logic as of today.

Changelog

Fixed

• component: Fix #1547. Fixed unhandled activity type should be forwarded to custom middleware, by @compulim in PR #1569

Samples

• component: Password input activity, in #1569

[coveralls]

Pull Request Test Coverage Report for Build 781

• 23 of 27 (85.19%) changed or added relevant lines in 3 files are covered.
• 1 unchanged line in 1 file lost coverage.
• Overall coverage decreased (-0.04%) to 47.906%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
packages/component/src/BasicTranscript.js	12	13	92.31%
packages/component/src/Middleware/Activity/createCoreMiddleware.js	10	13	76.92%

Files with Coverage Reduction	New Missed Lines	%
packages/component/src/Utils/Timer.js	1	33.33%

Totals
Change from base Build 765:	-0.04%
Covered Lines:	784
Relevant Lines:	1475

---

💛 - Coveralls

[corinagum]

Nitpicky things

[compulim]

@corinagum all comments fixed. 😄

[cwhitten]

What is the plan to address the coverage?

[compulim]

@cwhitten Post 4.3, we will start writing tests. And in this mode, we will reject any PRs with decreased coverage. I don't know how far we could go if we strictly enforce it, but I suggest we should try this strategy out first and see how far we can stretch.

For tests that is not visual (no UI), for example, speech, I already have a plan on how to make this feature visible for our visual regression test engine (hint: via middleware and ponyfill).

For now, with only 1 test (Corina is adding some), the coverage number usually fluctuate +/- 2%. IMO, this is acceptable before we start writing comprehensive tests.

[compulim]

@corinagum can you review this again for me? I made some change to the timestamp grouping to fix test failures.

[corinagum]

Minor comments & one question :)