Aside from the major change in the internal API of the menu widget, the number of fixe to the menu widget is quite small: just 10 fixes since the version we currently use (2.0.5). The current version is 2013v1.6.
Looking at the version history (http://wijmo.com/wiki/index.php/Version_Histories) shows that the last modification to the menu widget was made for version 2.3.4. The changes to the menu widget are listed below.
VERSION 2.3.4
- Changed the default value "[]" to "null" of "items" option.
VERSION 2.3.3
- Changed the default value "[]" to "null" for the "items" option.
VERSION 2.3.2
- Fixed an issue that 'navigateUrl' is not working properly in sub menu after navigating through keyboard when 'mode' property is set to 'sliding'
VERSION 2.2.2
- Fix an issue when setting "direction" option to 'rtl', the 'header' and 'separator' items don't float to right.
Update the 'showing' event, when it return false, it will be cancled.
- Add the 'shown', 'hidding' and 'hidden' event to the menu.
- And when the 'hidding' event return false, it will be cancled.
VERSION 2.2.0
- Fixed a UI issue in sliding mode when set width.
VERSION 2.1.7
- Fixed an issue where submenuitem's text is not shown correctly when templating.
- Fixed an issue where the variable self.domObject is not set to null when killing element.
VERSION 2.1.6
- Fixed an issue that submenuitem's text is not shown correctly when templating.
VERSION 2.1.4
- Stop event propagation when menu is shown as a context menu.
VERSION 2.1.3
- Added a new option "direction", its value is "ltr" or "rtl" to support right-to-left rendering.
- Fixed an issue in the deactivate method.
VERSION 2.0.8
- Removed “wijmo-wijmenu-link” class when templating.
- Fixed a bug where the menu could not be displayed above other elements depending on the triggerElement.
Most of the changes are bug fixes, some of which we have already fixed on our own. There's not much more in terms of new features. The menu widget doesn't seem to be getting much attention lately, there's nothing much more to add to a menu after all.
Instead of just replacing the source code we have with the newest version and then try to re-apply all of our custom fixes, I could just go through all the different versions of the menu source code on the github repository, diff with the previous version, and apply those changes to our code. That would be easier and less regression-prone. This is the way we could go about for future updates to the menu widget.
Instead of building our own menu widget from scratch, we might as well just keep the current version of the wijmo menu widget that we have, and just apply any fixes that would be beneficial for us, in the way described in the last paragraph, and we can also add any other custom features and bug fixes of our own. Creating a menu widget from scratch would take a substantial amount of effort, and woould give us little benefit: just a menu widget that would be as functional as the one we have and which would do the same things.
Given the extensive changes and effort required to move to the newer Wijmo version we should also review to see if refactoring the menu components to remove Wijmo altogether might be feasible.