This discussion is a continuation of a discussion that started on PR 14228.

Before #14228, there were two types of menu items, ActionItem and CheckableItem, and you could create a menu in BokehJS like so:

plot.context_menu = new Menu({
  items: [
    new ActionItem({
      label: "Save plot",
      action: () => save_tool.do.emit("save"),
    }),
    new CheckableItem({
      label: "Wheel zoom",
      action: toggle_wheel_zoom,
      checked: () => wheel_zoom.active,
    }),
  ],
})

After 14228, the menu takes a single class, MenuItem, like so:

plot.context_menu = new Menu({
  items: [
    new MenuItem({
      label: "Save plot",
      action: () => save_tool.do.emit("save"),
    }),
    new MenuItem({
      label: "Wheel zoom",
      action: toggle_wheel_zoom,
      checked: () => wheel_zoom.active,
    }),
  ],
})

Before 14228, the class inheritance diagram was:

• MenuItem (abstract)
  • ActionItem (concrete)
    • CheckableItem (concrete)

After 14228, there's just MenuItem.

This brings BokehJS into alignment with frameworks like Qt and Windows Forms, as well as HTML.

But there's a catch. As @bryevdv pointed out, with the API introduced in 14228, if you want to construct a menu that shows checkable menu items as actually checkable (by creating a column for check marks), you must set the checked property on one of the menu items to true or false or a function that returns a boolean, otherwise the property defaults to null. If the menu does not encounter any menu items with a non-null checked property when it renders, then it does not create a column for check marks.

In the following example, the menu item's checked property is set to a boolean function, so the menu will show the item as checkable:

let isChecked = true
plot.context_menu = new Menu({
  items: [
    new MenuItem({
      label: "Example Item 1",
      action: () => isChecked = !isChecked,
      checked: () => isChecked,
    }),
  ],
})

But if the checked property is not specified at the time the menu is constructed, as in the following example, then the menu item is not shown as checkable (there is no column in the menu for check marks). However, if the user clicks a menu item and it responds by setting the checked property, then the next time the user opens the menu, there will be a column for check marks:

const menuItem = new MenuItem({
  label: "Example Item 1",
  action: () => menuItem.checked = !menuItem.checked,
})
plot.context_menu = new Menu({
  items: [menuItem],
})

Whether one menu item is shown as checkable initially can depend on the other menu item, as the following pair of examples show:

// The resulting menu will initially show neither item as checkable,
const menuItem = new MenuItem({
  label: "Example Item 1",
  action: () => menuItem.checked = !menuItem.checked,
})
plot.context_menu = new Menu({
  items: [
    menuItem,
    new MenuItem({
      label: "Example Item 2",
    }),
  ],
})

// The resulting menu will initially show both items as checkable
let isChecked = true
const menuItem = new MenuItem({
  label: "Example Item 1",
  action: () => menuItem.checked = !menuItem.checked,
})
plot.context_menu = new Menu({
  items: [
    menuItem,
    new MenuItem({
      label: "Example Item 2",
      action: () => isChecked = !isChecked,
      checked: () => isChecked,
    }),
  ],
})

The question is: are we happy with this API? Or do think it should be modified, and if so, how?

Are the above examples too contrived? Can we think of examples that are more realistic that demonstrate an actual need to specify a menu item's checked property after the menu has been constructed and rendered? Why do other frameworks provide two separate properties: is checkable versus is checked?