Suggestion: Frontend code refactoring / improvements
Posted: Saturday 06 August 2016 12:56
I tried to work with the Domoticz front-end code and it seems that:
- Modularization is not really applied (comparing with the backend code), e.g. the HardwareController.js contains 5000+ LOC and the configuration of almost every device.
- Lots of global javascript variables are used that might possible conflict.
- No separation of model, view and controller. Making skinning etc difficult, e.g. a lot of HTML is just being assigned an ID and that is mention then everwhere in the javascript.
But there are not only `bad-parts`. I think its great that it is using AngularJS + Router to separate the different views! So why stop there. Maybe we could write-up some examples and rewrite some parts so they use AngularJS more, this gives great possibilities to extend Domoticz web-ui without adding more global variables and mixing of HTML, CSS and Javascript together.
As example i worked a bit on the ZWave Hardware component (WIP!!! the User codes are not yet working since i don't have a security device):
https://github.com/sjoerdmulder/domotic ... fb5376df39
Changes applied are:
- Move all ZWave specific javascript and html in a app/hardware/ZWave.js and views/hardware/zwave.html files (so HardwareController and hardware.html are clean and only managing the "Hardware" page)
- Adding a /Hardware/ZWave/:name/:idx url so parameters are passed in through the URL making refreshing a page work and not ending up at the /Hardware page again.
- Using angular's $scope so that the function are only available for the Zwave component and not globally floating around.
- Using angular's ng-model for two-way binding, so whenever the input is updated the variable in javascript is also updated (e.g. $scope.current.Name) and vice-versa (e.g. setting $scope.current.Name will automaticly set the value to the input-field).
What do you guys think? I think it would be great too move in this direction to have a Domoticz that is more future-proof and better maintainable. We could start by when new devices are added requiring them to follow this pattern. (e.g. using the Router and separate Javascript and HTML files)
- Modularization is not really applied (comparing with the backend code), e.g. the HardwareController.js contains 5000+ LOC and the configuration of almost every device.
- Lots of global javascript variables are used that might possible conflict.
- No separation of model, view and controller. Making skinning etc difficult, e.g. a lot of HTML is just being assigned an ID and that is mention then everwhere in the javascript.
But there are not only `bad-parts`. I think its great that it is using AngularJS + Router to separate the different views! So why stop there. Maybe we could write-up some examples and rewrite some parts so they use AngularJS more, this gives great possibilities to extend Domoticz web-ui without adding more global variables and mixing of HTML, CSS and Javascript together.
As example i worked a bit on the ZWave Hardware component (WIP!!! the User codes are not yet working since i don't have a security device):
https://github.com/sjoerdmulder/domotic ... fb5376df39
Changes applied are:
- Move all ZWave specific javascript and html in a app/hardware/ZWave.js and views/hardware/zwave.html files (so HardwareController and hardware.html are clean and only managing the "Hardware" page)
- Adding a /Hardware/ZWave/:name/:idx url so parameters are passed in through the URL making refreshing a page work and not ending up at the /Hardware page again.
- Using angular's $scope so that the function are only available for the Zwave component and not globally floating around.
- Using angular's ng-model for two-way binding, so whenever the input is updated the variable in javascript is also updated (e.g. $scope.current.Name) and vice-versa (e.g. setting $scope.current.Name will automaticly set the value to the input-field).
What do you guys think? I think it would be great too move in this direction to have a Domoticz that is more future-proof and better maintainable. We could start by when new devices are added requiring them to follow this pattern. (e.g. using the Router and separate Javascript and HTML files)