Stop abusing Composer architecture

[IlyaSemenov]

So far I've been using grammy-scenes with 2 bots, ~15 scenes, and ~100 "steps", and I wanted to share my observations.

What I like:

• The whole concept of do/wait/resume. The code base is concise yet flexible. It surely gets things done.
• Nested scenes. What is especially useful is the ability to return value from a nested scene.
• Scene-local session storage with strong typings.
• scene.call / ctx.scene.call (goto, exit, etc.) counterparts, where the former is simply a shortcut for the latter.

What I don't like:

• Abusing composer architecture, relying on the composer implementation details (on the fact that all composer API methods end up with .use()).
• Unnamed (numbered) steps. This is easy for the developer but breaks UX for users that were in the middle of a scene when it gets slightly updated.
• .always() feels counter-intuitive.

So I'm thinking on blending the two approaches, the one that I've used initially with the current one. I'm thinking like this:

const scene = new Scene<Context, LocalSession>("scene_name") // scene is again not a composer

scene.use() // <-- to be called always, such as for injecting ctx.something

scene.step().use(...) // reintroduce "step" as a building block

scene.wait("enter_xx").on(...) // always label wait blocks for reliability

scene.step("mylabel").use(...) // sometimes label steps, for goto

scene.goto("mylabel") // goto, call, exit, etc. work as before

[IlyaSemenov]

After playing around I went with a bit less radical approach. I cleaned the internals and stopped relying on composer internals. However, the API is almost the same and in most cases no changes to user code will be required. The scene still has use/do and wait as main building blocks as before, with all other previously publicly documented methods (label, goto, etc.) available.

The unnumbered steps problem was not addressed in this release, it will be covered separately.

[IlyaSemenov]

Oops! Seems like semantic release didn't recognize the breaking changes.

https://github.com/semantic-release/commit-analyzer/issues/231

[IlyaSemenov]

Released in v8.0.0.