Bug 899434 Implement sdk/ui/menuitem

[erikvold]

No description provided.

[Gozala]

Why not just keep those constants here, I don't think we need that extra module.

[erikvold]

I'm using the MENUS constants in sdk/ui/menuitem.js and sdk/ui/menuitem/view.js

[erikvold]

@Gozala do you see the bug in cdcfcfd ? This is just one example why I and others have ben asking for a WindowTracker replacement since it was deprecated.

[Gozala]

Just use arrow functions, they were invented exactly to fix self pattern.

[Gozala]

Just pointed out thing about arrow functions, although I want events to be handled by separate controller.

[Gozala]

I think it would be easier to explain what I want here than inline:

1. I want to separate concerns as much as possible which means, models (instances of MenuItem) have no direct
   relation with views, neither they observe views or event bus' to do it implicitly.

2. On construction model creates view via makeView(options, [window]) function. It does not passes second
   argument implying to create views for each window.

3. On destruction model disposes view via disposeView(options, [window]) function. It does not passes socond
   argument implying to dispose view for each window.

4. Views have no idea about models or our event system, all they do is assemble DOM nodes and inject them
   in the right place. In other words:

   const makeView = (options, target) =>
      target ? makeViewAt(options, target) :
      readyWindows.forEach(window =>makeViewAt(options, window)

   Also if there's no better way makeViewAt registers event handlers that dispatch observer notifications when
   they're clicked with some subject that can be used to track model (id, or view instance itslef).

5. Controller is a part deals with events, it observes menu item click notifications on the menu items that we're
   aware of, finds a right model (instance of MenuItem) for and emits event on it. That implies some, ideally
   minimal mapping from view / id to a model.

6. Controller tracks windows, whenever there's new one ready, it goes through active menuitems and does
   makeView(menuitem, window).

[Gozala]

This makes views and models unaware of each other, or events. makeView only knows how to create view on given or existing windows. Controller#1 just knows how to find a model for notification to and dispatch event on it.
Controller#2 just knows to call makeView(menuitem, window) for all known menuitems when window becomes ready.

You could also go and hook updates into observer notifications to allow ultimate extensibility as we talked before.
That way other add-on would be able to modify menu item labels and states without having to interact with our objects at all.

[Gozala]

Now that I think more about it, in fact I would also make view creation and view disposal also controllers concern. I would just send update notifications like id: { label: "foo", ... } and { id: null } and let controller keep track of alive
menuitems and also let it add / remove nodes as appropriate.