UI Extension Example: Extending directives

Dear dev-

Here is an example of extending a directive using AngularJS’s decorator syntax. I have created a sample pull request to the OpenLMIS-Malawi/mw-ui repository to show an example of what a MW-267 could look like if refactored.

https://github.com/OpenLMIS-Malawi/mw-ui/pull/1

NOTE: this won’t be merged, I thought it would be the simplest way to show the changes…

Tomorrow at the Tech Committee, we will discuss this example – as it is still a work in progress

(it doesn’t really work according to my unit tests)

The goal of this work, is to create ‘lighter’ extension mechanisms, as implementers are generally making changes to the UI behavior – which has been a large cause of forking in previous versions of OpenLMIS.

I would like feed back on:

(1) Is this too much boiler plate to be worth the effort for an implementer?

(2) Does the file naming convention make sense? (ie naming the folder ‘*-override’)

(2)
The second unit test
is to make sure the original contract stays in place --> is this reasonable?

(3) If extending services is simpler than extending directives, would it make more sense to only extend the services?

– nick –

···

Nick Reid | nick.reid@villagereach.org

Software Developer, Information Systems Group

VillageReach** *** Starting at the Last Mile
*2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

CELL: +1.510.410.0020

SKYPE: nickdotreid

www.villagereach.org

Hi Nick,
This solution certainly needs more work from an implementer, but I think it might be worth it in a long run. Currently each time after introducing new releases of the core components to the Malawi implementation, I need to go through all files and check whether something changed in the forked files. I have to check which methods where chaged by the Malawi team, and which were changed by the core team (the core team has commits history, so it’s easy, but in Malawi first occurence of the file in the commits history is when it’s copied and already changed file from the core - so I don’t know immediatly what’s different from the core version of the file). In such decorator, it is clear what is changed and why. There is less code and it seems to me that it’s more clear, but it’s possible that there are places in the code, where it’s better to just fork and change the file.

The naming convention makes sense to me, but I don’t have a strong preference for this or any other option.

Regarding unit tests, will original tests from the directive also run during build? If yes, I understand that they will run on the original directive, without decorator? I’m not sure whether we should just run one control test to make sure that the original contract stays in place, or run all tests from the original directive (besides the ones testing “isReadOnly” method). Is there a possibility to somehow override unit tests?

Best regards,
Weronika



Weronika Ciecierska

Software Developer

wciecierska@soldevelo.com

SolDevelo Sp. z o. o. [LLC]

Office:  +48 58 782 45 40
/ Fax:  +48 58 782 45 41
 Al. Zwycięstwa 96/98
 81-451, Gdynia

[http://www.soldevelo.com](http://www.SolDevelo.com)

 Place of registration: Regional Court for the City of Gdansk
 KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585,
 Share capital: 60,000.00 PLN
···

On Tuesday, 25 July 2017 04:36:55 UTC+2, Nick Reid wrote:

Dear dev-

Here is an example of extending a directive using AngularJS’s decorator syntax. I have created a sample pull request to the OpenLMIS-Malawi/mw-ui repository to show an example of what a MW-267 could look like if refactored.

https://github.com/OpenLMIS-Malawi/mw-ui/pull/1

NOTE: this won’t be merged, I thought it would be the simplest way to show the changes…

Tomorrow at the Tech Committee, we will discuss this example – as it is still a work in progress

(it doesn’t really work according to my unit tests)

The goal of this work, is to create ‘lighter’ extension mechanisms, as implementers are generally making changes to the UI behavior – which has been a large cause of forking in previous versions of OpenLMIS.

I would like feed back on:

(1) Is this too much boiler plate to be worth the effort for an implementer?

(2) Does the file naming convention make sense? (ie naming the folder ‘*-override’)

(2)
The second unit test
is to make sure the original contract stays in place --> is this reasonable?

(3) If extending services is simpler than extending directives, would it make more sense to only extend the services?

– nick –

Nick Reid | nick...@villagereach.org

Software Developer, Information Systems Group

VillageReach** *** Starting at the Last Mile
*2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

CELL: +1.510.410.0020

SKYPE: nickdotreid

www.villagereach.org

hello Nick,

This solution gives me new inspiration, I think it is worth it in the long run. Actually our team meets the same question, we have two choices “AngularJS’s decorator syntax” or “replacing the whole HTML file”, we want to learn more Malawi experience, Should we do in the new service if we need extension Html files? Because we refer to Malawi’s’ code. we found replace the whole file is the main way, we want to know the reason behind it?

Best regards,
jingjing