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

Lifecycle hook(s) for menus #99

Open
phils-hub opened this issue Jun 11, 2020 · 1 comment
Open

Lifecycle hook(s) for menus #99

phils-hub opened this issue Jun 11, 2020 · 1 comment
Labels
enhancement New feature or request pinned Prevent from automatically closing due to inactivity

Comments

@phils-hub
Copy link

It would be interesting to have a sort of menu lifecycle hook that is triggered before this menu and any of its components (such as menu.select) are rendered. A subset of hooks such as the lifecycle hooks of Vue could be provided.

An example - assuming we had a beforeRendered hook the following would then be possible:

const menuOfTeams = new MenuTemplate(ctx => `You have ${ctx.state.teams.length} teams. Here they are:`)

menuOfTeams.chooseIntoSubmenu('details', ctx => ctx.state.teams.map(team => team.name), teamDetailsMenu)

menuOfTeams.beforeRendered(ctx => ctx.state.teams = restApi.getTeams())

The hook could easily be used to execute API calls to populate shared state, after which menu components can then access that state during rendering.

This would be more intuitive and simpler to use than configuring separate middleware. The non-lifecycle hook approach (as of today) would require something like:

bot.action(/^\/my\/relevant\/path\//, (ctx, next) => {
  ctx.state.something = 'hello world!'
  return next()
})

const menuTemplate = new MenuTemplate(ctx => ctx.state.something)
@phils-hub phils-hub added the enhancement New feature or request label Jun 11, 2020
@phils-hub phils-hub mentioned this issue Jun 11, 2020
7 tasks
@EdJoPaTo EdJoPaTo added this to the v5 milestone Jun 11, 2020
@EdJoPaTo
Copy link
Owner

Hooks do not seem as easy as I have hoped for. I think for now this is a bit annoying to implement.
Personally I can work without them so I think they are not a high priority currently.

When the menu is generated the first thing done is always the body so you can preload stuff at the body. For functions like do or set this is not the case as they are independent of the resulting visible menu. As interactions for example might change things the menu has to load the same stuff again to have everything up to date what changed with the interaction. That might be the same with preloading via a hook.

I would like 2 different hooks: one for going into the path and one only for the exact menu. Implementing this would requiring a different internal approach for MenuMiddleware.
The good thing here is that this will probably not be a breaking change as it only changes within the MenuMiddleware. Because of this I think I will not continue to think about this until v5 stable is released.

@EdJoPaTo EdJoPaTo removed this from the v5 milestone Jun 24, 2020
@EdJoPaTo EdJoPaTo added the pinned Prevent from automatically closing due to inactivity label Feb 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request pinned Prevent from automatically closing due to inactivity
Projects
None yet
Development

No branches or pull requests

2 participants