JavaScript framework/library for OpenLMIS

In preparation of upcoming OpenLMIS/eLMIS Gap analysis workshop (April 11-13, 2018), we are reaching out to the developer communities to learn from your experience, observation and recommendations.

If you can give us your feedback along the following lines that would be wonderful:

  • What is your opinion about current JavaScript libraries and framework being used in OpenLMIS?

  • What are the pain points, programming challenges, performance issues you may have faced with the current JavaScript libraries?

  • Do you recommend that OpenLMIS stays with AngularJS 1.x, upgrade to higher versions of Angular or adopt some other JavaScript framework? Which Specific JavaScript Framework or libraries do you recommend?

  • Please tell us a bit about how the alternate JavaScript framework will help address the pain points and put OpenLMIS in a better footing for future?

  • Do you have any recommendations about how AngularJS 1.x and new JavaScript framework can co-exists? Or, do you think that it is better to bite the bullet and rewrite everything into the new JavaScript framework?

Thanks for your feedback.

Thanks Ashraf,

I thought it’d be useful to link to the AngularJS version support page: https://docs.angularjs.org/misc/version-support-status

Which points out that the last AngularJS 1.x version with LTS (3yr) is planned to be 1.7, which is not yet released.

I’d also like to add to this discussion a few points that I think are important today when considering the bigger picture:

  • v3 currently has > 20k lines of AngularJS 1.x code.
  • We’ll need to continue to deliver new functionality and maintain current capability.
  • We have a desire to build a mobile app, however it’s yet-to-be-funded.
  • There currently isn’t any specific funding to re-write the front-end.

Of course some of these things will change.

Given what the bigger picture looks like today, there’s obvious interest in exploring how the UI can evolve incrementally. Today we have the UI more or less split into domain verticals like the services are (Requisition, Stock Management, etc), and we have a URI based router for loading and navigating code and screens in workflows - key in enabling extension.

So I too would like to hear people’s thoughts on the questions Ashraf has put forth, and I’d put extra emphasis on the last one (rephrased): What is a path forward which avoids a drop-everything and re-write?

Best,
Josh

···

On Thursday, March 29, 2018 at 6:31:34 AM UTC-7, ashraf_islam@jsi.com wrote:

In preparation of upcoming OpenLMIS/eLMIS Gap analysis workshop (April 11-13, 2018), we are reaching out to the developer communities to learn from your experience, observation and recommendations.

If you can give us your feedback along the following lines that would be wonderful:

  • What is your opinion about current JavaScript libraries and framework being used in OpenLMIS?
  • What are the pain points, programming challenges, performance issues you may have faced with the current JavaScript libraries?
  • Do you recommend that OpenLMIS stays with AngularJS 1.x, upgrade to higher versions of Angular or adopt some other JavaScript framework? Which Specific JavaScript Framework or libraries do you recommend?
  • Please tell us a bit about how the alternate JavaScript framework will help address the pain points and put OpenLMIS in a better footing for future?
  • Do you have any recommendations about how AngularJS 1.x and new JavaScript framework can co-exists? Or, do you think that it is better to bite the bullet and rewrite everything into the new JavaScript framework?

Thanks for your feedback.

I can’t speak to the current state of OpenLMIS, since I’ve never written any code for it, but I can share something that ThoughtWorks did on the Bahmni project.

Bahmni has a large Angular 1.x codebase, but over time many of our devs began preferring to work in ReactJS, having seen it work better on other projects. But of course a full rewrite was not in the cards.

There’s an “ngReact” plugin which lets you use React components inside an Angular 1.x application, and when it came time to do a big new piece of complex functionality (our wysiwyg form editor and rendering engine) we built this in React and just plugged it into the existing application. It worked out great:

  • much better dev experience for this feature

  • much faster performance for this specific component (as compared to its predecessor which was written in Angular)

-Darius

···

On Fri, Mar 30, 2018 at 12:12 AM, Josh Zamor josh.zamor@villagereach.org wrote:

Thanks Ashraf,

I thought it’d be useful to link to the AngularJS version support page: https://docs.angularjs.org/misc/version-support-status

Which points out that the last AngularJS 1.x version with LTS (3yr) is planned to be 1.7, which is not yet released.

I’d also like to add to this discussion a few points that I think are important today when considering the bigger picture:

  • v3 currently has > 20k lines of AngularJS 1.x code.
  • We’ll need to continue to deliver new functionality and maintain current capability.
  • We have a desire to build a mobile app, however it’s yet-to-be-funded.
  • There currently isn’t any specific funding to re-write the front-end.

Of course some of these things will change.

Given what the bigger picture looks like today, there’s obvious interest in exploring how the UI can evolve incrementally. Today we have the UI more or less split into domain verticals like the services are (Requisition, Stock Management, etc), and we have a URI based router for loading and navigating code and screens in workflows - key in enabling extension.

So I too would like to hear people’s thoughts on the questions Ashraf has put forth, and I’d put extra emphasis on the last one (rephrased): What is a path forward which avoids a drop-everything and re-write?

Best,
Josh

On Thursday, March 29, 2018 at 6:31:34 AM UTC-7, ashraf_islam@jsi.com wrote:

In preparation of upcoming OpenLMIS/eLMIS Gap analysis workshop (April 11-13, 2018), we are reaching out to the developer communities to learn from your experience, observation and recommendations.

If you can give us your feedback along the following lines that would be wonderful:

  • What is your opinion about current JavaScript libraries and framework being used in OpenLMIS?
  • What are the pain points, programming challenges, performance issues you may have faced with the current JavaScript libraries?
  • Do you recommend that OpenLMIS stays with AngularJS 1.x, upgrade to higher versions of Angular or adopt some other JavaScript framework? Which Specific JavaScript Framework or libraries do you recommend?
  • Please tell us a bit about how the alternate JavaScript framework will help address the pain points and put OpenLMIS in a better footing for future?
  • Do you have any recommendations about how AngularJS 1.x and new JavaScript framework can co-exists? Or, do you think that it is better to bite the bullet and rewrite everything into the new JavaScript framework?

Thanks for your feedback.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/5c6841d4-efe0-4554-beef-41afbc2b1c3d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Darius JazayeriPrincipal Architect - Global Health
Email
djazayeri@thoughtworks.com

Telephone
+1 617 383 9369

ThoughtWorks

Thanks Darius, this is a great pointer.

For the OpenLMIS folks most passionate about the UI, have you investigated/used ngReact? Should we run a quick spike right after release on figuring out how widely it can be applied and what happens to cross-cutting concerns?

I’d think the spike might look something like:

  • Is it possible and what general changes would be required to use ngReact to build/re-write UI-components in React - ideally leveraging as much as we already have such as the UI Router and UI Extension.
  • What effects would we see to cross-cutting concerns (e.g. SASS, translations, grunt/build process, etc).

The other obvious way to write this spike is to go bottom-up instead of top-down. See if some of our large tables that can be slow and tricky can be improved with ngReact+React.

Thoughts?

Best,

Josh

···

On Fri, Mar 30, 2018 at 12:12 AM, Josh Zamor josh.zamor@villagereach.org wrote:

Thanks Ashraf,

I thought it’d be useful to link to the AngularJS version support page: https://docs.angularjs.org/misc/version-support-status

Which points out that the last AngularJS 1.x version with LTS (3yr) is planned to be 1.7, which is not yet released.

I’d also like to add to this discussion a few points that I think are important today when considering the bigger picture:

  • v3 currently has > 20k lines of AngularJS 1.x code.
  • We’ll need to continue to deliver new functionality and maintain current capability.
  • We have a desire to build a mobile app, however it’s yet-to-be-funded.
  • There currently isn’t any specific funding to re-write the front-end.

Of course some of these things will change.

Given what the bigger picture looks like today, there’s obvious interest in exploring how the UI can evolve incrementally. Today we have the UI more or less split into domain verticals like the services are (Requisition, Stock Management, etc), and we have a URI based router for loading and navigating code and screens in workflows - key in enabling extension.

So I too would like to hear people’s thoughts on the questions Ashraf has put forth, and I’d put extra emphasis on the last one (rephrased): What is a path forward which avoids a drop-everything and re-write?

Best,

Josh

On Thursday, March 29, 2018 at 6:31:34 AM UTC-7, ashraf_islam@jsi.com wrote:

In preparation of upcoming OpenLMIS/eLMIS Gap analysis workshop (April 11-13, 2018 ), we are reaching out to the developer communities to learn from your experience, observation and recommendations.

If you can give us your feedback along the following lines that would be wonderful:

  • What is your opinion about current JavaScript libraries and framework being used in OpenLMIS?
  • What are the pain points, programming challenges, performance issues you may have faced with the current JavaScript libraries?
  • Do you recommend that OpenLMIS stays with AngularJS 1.x, upgrade to higher versions of Angular or adopt some other JavaScript framework? Which Specific JavaScript Framework or libraries do you recommend?
  • Please tell us a bit about how the alternate JavaScript framework will help address the pain points and put OpenLMIS in a better footing for future?
  • Do you have any recommendations about how AngularJS 1.x and new JavaScript framework can co-exists? Or, do you think that it is better to bite the bullet and rewrite everything into the new JavaScript framework?

Thanks for your feedback.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/5c6841d4-efe0-4554-beef-41afbc2b1c3d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Darius JazayeriPrincipal Architect - Global Health
Email
djazayeri@thoughtworks.com

Telephone
+1 617 383 9369

ThoughtWorks

Hi everyone,

I’ve casually played with React and ngReact in the past. Before investing time delving into approaches for adopting them in OpenLMIS, I suggest doing a quick spike comparing React with Vue.js. The latter is newer and has gained significant traction in the developer community. I’ve personally never preferred JSX and am thus naturally drawn to Vue. It offers ngVue as a way of incrementally moving away from Angular, and can be used with NativeScript for cross-platform (mobile) development.

It may be that React’s component-based model better fits OpenLMIS’ emphasis on extensibility and customization. I suggest against blind investment in it, though, given that Vue is a newer and potentially compelling alternative.

Kind regards,

Ben

···

On Friday, March 30, 2018 at 10:30:47 AM UTC-7, Josh Zamor wrote:

Thanks Darius, this is a great pointer.

For the OpenLMIS folks most passionate about the UI, have you investigated/used ngReact? Should we run a quick spike right after release on figuring out how widely it can be applied and what happens to cross-cutting concerns?

I’d think the spike might look something like:

  • Is it possible and what general changes would be required to use ngReact to build/re-write UI-components in React - ideally leveraging as much as we already have such as the UI Router and UI Extension.
  • What effects would we see to cross-cutting concerns (e.g. SASS, translations, grunt/build process, etc).

The other obvious way to write this spike is to go bottom-up instead of top-down. See if some of our large tables that can be slow and tricky can be improved with ngReact+React.

Thoughts?

Best,

Josh

On Mar 29, 2018, at 5:25 PM, Darius Jazayeri djaz...@thoughtworks.com wrote:

I can’t speak to the current state of OpenLMIS, since I’ve never written any code for it, but I can share something that ThoughtWorks did on the Bahmni project.

Bahmni has a large Angular 1.x codebase, but over time many of our devs began preferring to work in ReactJS, having seen it work better on other projects. But of course a full rewrite was not in the cards.

There’s an “ngReact” plugin which lets you use React components inside an Angular 1.x application, and when it came time to do a big new piece of complex functionality (our wysiwyg form editor and rendering engine) we built this in React and just plugged it into the existing application. It worked out great:

  • much better dev experience for this feature
  • much faster performance for this specific component (as compared to its predecessor which was written in Angular)

-Darius

On Fri, Mar 30, 2018 at 12:12 AM, Josh Zamor josh....@villagereach.org wrote:

Thanks Ashraf,

I thought it’d be useful to link to the AngularJS version support page: https://docs.angularjs.org/misc/version-support-status

Which points out that the last AngularJS 1.x version with LTS (3yr) is planned to be 1.7, which is not yet released.

I’d also like to add to this discussion a few points that I think are important today when considering the bigger picture:

  • v3 currently has > 20k lines of AngularJS 1.x code.
  • We’ll need to continue to deliver new functionality and maintain current capability.
  • We have a desire to build a mobile app, however it’s yet-to-be-funded.
  • There currently isn’t any specific funding to re-write the front-end.

Of course some of these things will change.

Given what the bigger picture looks like today, there’s obvious interest in exploring how the UI can evolve incrementally. Today we have the UI more or less split into domain verticals like the services are (Requisition, Stock Management, etc), and we have a URI based router for loading and navigating code and screens in workflows - key in enabling extension.

In preparation of upcoming OpenLMIS/eLMIS Gap analysis workshop (April 11-13, 2018 ), we are reaching out to the developer communities to learn from your experience, observation and recommendations.

If you can give us your feedback along the following lines that would be wonderful:

  • What is your opinion about current JavaScript libraries and framework being used in OpenLMIS?
  • What are the pain points, programming challenges, performance issues you may have faced with the current JavaScript libraries?
  • Do you recommend that OpenLMIS stays with AngularJS 1.x, upgrade to higher versions of Angular or adopt some other JavaScript framework? Which Specific JavaScript Framework or libraries do you recommend?
  • Please tell us a bit about how the alternate JavaScript framework will help address the pain points and put OpenLMIS in a better footing for future?
  • Do you have any recommendations about how AngularJS 1.x and new JavaScript framework can co-exists? Or, do you think that it is better to bite the bullet and rewrite everything into the new JavaScript framework?

Thanks for your feedback.

So I too would like to hear people’s thoughts on the questions Ashraf has put forth, and I’d put extra emphasis on the last one (rephrased): What is a path forward which avoids a drop-everything and re-write?

Best,

Josh

On Thursday, March 29, 2018 at 6:31:34 AM UTC-7, ashraf...@jsi.com wrote:

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

To post to this group, send email to openlm...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/5c6841d4-efe0-4554-beef-41afbc2b1c3d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Darius JazayeriPrincipal Architect - Global Health
Email
djaz...@thoughtworks.com

Telephone
+1 617 383 9369

ThoughtWorks

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

To post to this group, send email to openlm...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAOKb-R7EOCisBvqAsu%3D3GSLNThQOy%2B3mOsS3Fd%2Bm8D5hvxuExg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

Thanks Ben,

I found Vue’s comparison page useful: https://vuejs.org/v2/guide/comparison.html

Reading through that I’m left with the impression that one spike could look at ngReact and ngVue given the similarities. And another separate spike could be done on the eco-systems of both: particularly the routing+global state of both.

Thoughts?

Best,

Josh

···

On Mar 31, 2018, at 1:20 AM, Ben Leibert benleibert@gmail.com wrote:

Hi everyone,

I’ve casually played with React and ngReact in the past. Before investing time delving into approaches for adopting them in OpenLMIS, I suggest doing a quick spike comparing React with Vue.js. The latter is newer and has gained significant traction in the developer community. I’ve personally never preferred JSX and am thus naturally drawn to Vue. It offers ngVue as a way of incrementally moving away from Angular, and can be used with NativeScript for cross-platform (mobile) development.

It may be that React’s component-based model better fits OpenLMIS’ emphasis on extensibility and customization. I suggest against blind investment in it, though, given that Vue is a newer and potentially compelling alternative.

Kind regards,

Ben

On Friday, March 30, 2018 at 10:30:47 AM UTC-7, Josh Zamor wrote:

Thanks Darius, this is a great pointer.

For the OpenLMIS folks most passionate about the UI, have you investigated/used ngReact? Should we run a quick spike right after release on figuring out how widely it can be applied and what happens to cross-cutting concerns?

I’d think the spike might look something like:

  • Is it possible and what general changes would be required to use ngReact to build/re-write UI-components in React - ideally leveraging as much as we already have such as the UI Router and UI Extension.
  • What effects would we see to cross-cutting concerns (e.g. SASS, translations, grunt/build process, etc).

The other obvious way to write this spike is to go bottom-up instead of top-down. See if some of our large tables that can be slow and tricky can be improved with ngReact+React.

Thoughts?

Best,

Josh

On Mar 29, 2018, at 5:25 PM, Darius Jazayeri <djaz...@thoughtworks.com > wrote:

I can’t speak to the current state of OpenLMIS, since I’ve never written any code for it, but I can share something that ThoughtWorks did on the Bahmni project.

Bahmni has a large Angular 1.x codebase, but over time many of our devs began preferring to work in ReactJS, having seen it work better on other projects. But of course a full rewrite was not in the cards.

There’s an “ngReact” plugin which lets you use React components inside an Angular 1.x application, and when it came time to do a big new piece of complex functionality (our wysiwyg form editor and rendering engine) we built this in React and just plugged it into the existing application. It worked out great:

  • much better dev experience for this feature
  • much faster performance for this specific component (as compared to its predecessor which was written in Angular)

-Darius

On Fri, Mar 30, 2018 at 12:12 AM, Josh Zamor josh....@villagereach.org wrote:

Thanks Ashraf,

I thought it’d be useful to link to the AngularJS version support page: https://docs.angularjs.org/misc/version-support-status

Which points out that the last AngularJS 1.x version with LTS (3yr) is planned to be 1.7, which is not yet released.

I’d also like to add to this discussion a few points that I think are important today when considering the bigger picture:

  • v3 currently has > 20k lines of AngularJS 1.x code.
  • We’ll need to continue to deliver new functionality and maintain current capability.
  • We have a desire to build a mobile app, however it’s yet-to-be-funded.
  • There currently isn’t any specific funding to re-write the front-end.

Of course some of these things will change.

Given what the bigger picture looks like today, there’s obvious interest in exploring how the UI can evolve incrementally. Today we have the UI more or less split into domain verticals like the services are (Requisition, Stock Management, etc), and we have a URI based router for loading and navigating code and screens in workflows - key in enabling extension.

In preparation of upcoming OpenLMIS/eLMIS Gap analysis workshop (April 11-13, 2018 ), we are reaching out to the developer communities to learn from your experience, observation and recommendations.

If you can give us your feedback along the following lines that would be wonderful:

  • What is your opinion about current JavaScript libraries and framework being used in OpenLMIS?
  • What are the pain points, programming challenges, performance issues you may have faced with the current JavaScript libraries?
  • Do you recommend that OpenLMIS stays with AngularJS 1.x, upgrade to higher versions of Angular or adopt some other JavaScript framework? Which Specific JavaScript Framework or libraries do you recommend?
  • Please tell us a bit about how the alternate JavaScript framework will help address the pain points and put OpenLMIS in a better footing for future?
  • Do you have any recommendations about how AngularJS 1.x and new JavaScript framework can co-exists? Or, do you think that it is better to bite the bullet and rewrite everything into the new JavaScript framework?

Thanks for your feedback.

So I too would like to hear people’s thoughts on the questions Ashraf has put forth, and I’d put extra emphasis on the last one (rephrased): What is a path forward which avoids a drop-everything and re-write?

Best,

Josh

On Thursday, March 29, 2018 at 6:31:34 AM UTC-7, ashraf...@jsi.com wrote:

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

To post to this group, send email to openlm...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/5c6841d4-efe0-4554-beef-41afbc2b1c3d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Darius JazayeriPrincipal Architect - Global Health
Email
djaz...@thoughtworks.com

Telephone
+1 617 383 9369

ThoughtWorks

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

To post to this group, send email to openlm...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAOKb-R7EOCisBvqAsu%3D3GSLNThQOy%2B3mOsS3Fd%2Bm8D5hvxuExg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/aba0861e-2a18-4d37-99ab-9592a4396bed%40googlegroups.com
.

For more options, visit https://groups.google.com/d/optout.

Hi Josh,

That’s a good link, and I think you’re right that two different spikes would be reasonable. Would the ng* spike call for a proof of concept with either (or both) frameworks? Either way, I think it’s great that an incremental upgrade to the UI’s stack is under discussion.

Thank you,

Ben

···

On Saturday, March 31, 2018 at 7:55:43 AM UTC-7, Josh Zamor wrote:

Thanks Ben,

I found Vue’s comparison page useful: https://vuejs.org/v2/guide/comparison.html

Reading through that I’m left with the impression that one spike could look at ngReact and ngVue given the similarities. And another separate spike could be done on the eco-systems of both: particularly the routing+global state of both.

Thoughts?

Best,

Josh

On Mar 31, 2018, at 1:20 AM, Ben Leibert benle...@gmail.com wrote:

Hi everyone,

I’ve casually played with React and ngReact in the past. Before investing time delving into approaches for adopting them in OpenLMIS, I suggest doing a quick spike comparing React with Vue.js. The latter is newer and has gained significant traction in the developer community. I’ve personally never preferred JSX and am thus naturally drawn to Vue. It offers ngVue as a way of incrementally moving away from Angular, and can be used with NativeScript for cross-platform (mobile) development.

It may be that React’s component-based model better fits OpenLMIS’ emphasis on extensibility and customization. I suggest against blind investment in it, though, given that Vue is a newer and potentially compelling alternative.

Kind regards,

Ben

On Friday, March 30, 2018 at 10:30:47 AM UTC-7, Josh Zamor wrote:

Thanks Darius, this is a great pointer.

For the OpenLMIS folks most passionate about the UI, have you investigated/used ngReact? Should we run a quick spike right after release on figuring out how widely it can be applied and what happens to cross-cutting concerns?

I’d think the spike might look something like:

  • Is it possible and what general changes would be required to use ngReact to build/re-write UI-components in React - ideally leveraging as much as we already have such as the UI Router and UI Extension.
  • What effects would we see to cross-cutting concerns (e.g. SASS, translations, grunt/build process, etc).

The other obvious way to write this spike is to go bottom-up instead of top-down. See if some of our large tables that can be slow and tricky can be improved with ngReact+React.

Thoughts?

Best,

Josh

On Mar 29, 2018, at 5:25 PM, Darius Jazayeri <djaz...@thoughtworks.com > wrote:

I can’t speak to the current state of OpenLMIS, since I’ve never written any code for it, but I can share something that ThoughtWorks did on the Bahmni project.

Bahmni has a large Angular 1.x codebase, but over time many of our devs began preferring to work in ReactJS, having seen it work better on other projects. But of course a full rewrite was not in the cards.

There’s an “ngReact” plugin which lets you use React components inside an Angular 1.x application, and when it came time to do a big new piece of complex functionality (our wysiwyg form editor and rendering engine) we built this in React and just plugged it into the existing application. It worked out great:

  • much better dev experience for this feature
  • much faster performance for this specific component (as compared to its predecessor which was written in Angular)

-Darius

On Fri, Mar 30, 2018 at 12:12 AM, Josh Zamor josh....@villagereach.org wrote:

Thanks Ashraf,

I thought it’d be useful to link to the AngularJS version support page: https://docs.angularjs.org/misc/version-support-status

Which points out that the last AngularJS 1.x version with LTS (3yr) is planned to be 1.7, which is not yet released.

I’d also like to add to this discussion a few points that I think are important today when considering the bigger picture:

  • v3 currently has > 20k lines of AngularJS 1.x code.
  • We’ll need to continue to deliver new functionality and maintain current capability.
  • We have a desire to build a mobile app, however it’s yet-to-be-funded.
  • There currently isn’t any specific funding to re-write the front-end.

Of course some of these things will change.

Given what the bigger picture looks like today, there’s obvious interest in exploring how the UI can evolve incrementally. Today we have the UI more or less split into domain verticals like the services are (Requisition, Stock Management, etc), and we have a URI based router for loading and navigating code and screens in workflows - key in enabling extension.

In preparation of upcoming OpenLMIS/eLMIS Gap analysis workshop (April 11-13, 2018 ), we are reaching out to the developer communities to learn from your experience, observation and recommendations.

If you can give us your feedback along the following lines that would be wonderful:

  • What is your opinion about current JavaScript libraries and framework being used in OpenLMIS?
  • What are the pain points, programming challenges, performance issues you may have faced with the current JavaScript libraries?
  • Do you recommend that OpenLMIS stays with AngularJS 1.x, upgrade to higher versions of Angular or adopt some other JavaScript framework? Which Specific JavaScript Framework or libraries do you recommend?
  • Please tell us a bit about how the alternate JavaScript framework will help address the pain points and put OpenLMIS in a better footing for future?
  • Do you have any recommendations about how AngularJS 1.x and new JavaScript framework can co-exists? Or, do you think that it is better to bite the bullet and rewrite everything into the new JavaScript framework?

Thanks for your feedback.

So I too would like to hear people’s thoughts on the questions Ashraf has put forth, and I’d put extra emphasis on the last one (rephrased): What is a path forward which avoids a drop-everything and re-write?

Best,

Josh

On Thursday, March 29, 2018 at 6:31:34 AM UTC-7, ashraf...@jsi.com wrote:

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

To post to this group, send email to openlm...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/5c6841d4-efe0-4554-beef-41afbc2b1c3d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Darius JazayeriPrincipal Architect - Global Health
Email
djaz...@thoughtworks.com

Telephone
+1 617 383 9369

ThoughtWorks

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

To post to this group, send email to openlm...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAOKb-R7EOCisBvqAsu%3D3GSLNThQOy%2B3mOsS3Fd%2Bm8D5hvxuExg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

To post to this group, send email to
openl...@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/aba0861e-2a18-4d37-99ab-9592a4396bed%40googlegroups.com
.

For more options, visit https://groups.google.com/d/optout.

Hi everyone,

I think that investigating both of the frameworks sounds really great! I would also like to mention that in the current state of the UI we would still have to rewrite a lot of code, but with the v7 architecture and our current mindset the code we are writing is becoming more and more class-driven rather than AngularJS-driven (we are still using Angular for dependency injection as we don’t have ES6 yet) - to put it in other words, we are trying to use AngularJS purely as a presentation layer (same we would do with React.js). I think the first thing we should do, even before spiking/introducing ngReact and/or ngVue, is adding the ES6 support as it would enable us to make a lot of code, that only uses AngularJS for dependency injection, AngularJS-free and thus easily reusable with other frameworks.

Best regards,
Nikodem


SolDevelo
Sp. z o.o. [LLC] / www.soldevelo.com
Al. Zwycięstwa 96/98, 81-451, Gdynia, Poland
Phone: +48 58 782 45 40 / Fax: +48 58 782 45 41

···

On Mon, Apr 2, 2018 at 6:35 PM, Ben Leibert benleibert@gmail.com wrote:

Hi Josh,

That’s a good link, and I think you’re right that two different spikes would be reasonable. Would the ng* spike call for a proof of concept with either (or both) frameworks? Either way, I think it’s great that an incremental upgrade to the UI’s stack is under discussion.

Thank you,

Ben

On Saturday, March 31, 2018 at 7:55:43 AM UTC-7, Josh Zamor wrote:

Thanks Ben,

I found Vue’s comparison page useful: https://vuejs.org/v2/guide/comparison.html

Reading through that I’m left with the impression that one spike could look at ngReact and ngVue given the similarities. And another separate spike could be done on the eco-systems of both: particularly the routing+global state of both.

Thoughts?

Best,

Josh

On Mar 31, 2018, at 1:20 AM, Ben Leibert benle...@gmail.com wrote:

Hi everyone,

I’ve casually played with React and ngReact in the past. Before investing time delving into approaches for adopting them in OpenLMIS, I suggest doing a quick spike comparing React with Vue.js. The latter is newer and has gained significant traction in the developer community. I’ve personally never preferred JSX and am thus naturally drawn to Vue. It offers ngVue as a way of incrementally moving away from Angular, and can be used with NativeScript for cross-platform (mobile) development.

It may be that React’s component-based model better fits OpenLMIS’ emphasis on extensibility and customization. I suggest against blind investment in it, though, given that Vue is a newer and potentially compelling alternative.

Kind regards,

Ben

On Friday, March 30, 2018 at 10:30:47 AM UTC-7, Josh Zamor wrote:

Thanks Darius, this is a great pointer.

For the OpenLMIS folks most passionate about the UI, have you investigated/used ngReact? Should we run a quick spike right after release on figuring out how widely it can be applied and what happens to cross-cutting concerns?

I’d think the spike might look something like:

  • Is it possible and what general changes would be required to use ngReact to build/re-write UI-components in React - ideally leveraging as much as we already have such as the UI Router and UI Extension.
  • What effects would we see to cross-cutting concerns (e.g. SASS, translations, grunt/build process, etc).

The other obvious way to write this spike is to go bottom-up instead of top-down. See if some of our large tables that can be slow and tricky can be improved with ngReact+React.

Thoughts?

Best,

Josh

On Mar 29, 2018, at 5:25 PM, Darius Jazayeri <djaz...@thoughtworks.com > wrote:

I can’t speak to the current state of OpenLMIS, since I’ve never written any code for it, but I can share something that ThoughtWorks did on the Bahmni project.

Bahmni has a large Angular 1.x codebase, but over time many of our devs began preferring to work in ReactJS, having seen it work better on other projects. But of course a full rewrite was not in the cards.

There’s an “ngReact” plugin which lets you use React components inside an Angular 1.x application, and when it came time to do a big new piece of complex functionality (our wysiwyg form editor and rendering engine) we built this in React and just plugged it into the existing application. It worked out great:

  • much better dev experience for this feature
  • much faster performance for this specific component (as compared to its predecessor which was written in Angular)

-Darius

On Fri, Mar 30, 2018 at 12:12 AM, Josh Zamor josh....@villagereach.org wrote:

Thanks Ashraf,

I thought it’d be useful to link to the AngularJS version support page: https://docs.angularjs.org/misc/version-support-status

Which points out that the last AngularJS 1.x version with LTS (3yr) is planned to be 1.7, which is not yet released.

I’d also like to add to this discussion a few points that I think are important today when considering the bigger picture:

  • v3 currently has > 20k lines of AngularJS 1.x code.
  • We’ll need to continue to deliver new functionality and maintain current capability.
  • We have a desire to build a mobile app, however it’s yet-to-be-funded.
  • There currently isn’t any specific funding to re-write the front-end.

Of course some of these things will change.

Given what the bigger picture looks like today, there’s obvious interest in exploring how the UI can evolve incrementally. Today we have the UI more or less split into domain verticals like the services are (Requisition, Stock Management, etc), and we have a URI based router for loading and navigating code and screens in workflows - key in enabling extension.

In preparation of upcoming OpenLMIS/eLMIS Gap analysis workshop (April 11-13, 2018 ), we are reaching out to the developer communities to learn from your experience, observation and recommendations.

If you can give us your feedback along the following lines that would be wonderful:

  • What is your opinion about current JavaScript libraries and framework being used in OpenLMIS?
  • What are the pain points, programming challenges, performance issues you may have faced with the current JavaScript libraries?
  • Do you recommend that OpenLMIS stays with AngularJS 1.x, upgrade to higher versions of Angular or adopt some other JavaScript framework? Which Specific JavaScript Framework or libraries do you recommend?
  • Please tell us a bit about how the alternate JavaScript framework will help address the pain points and put OpenLMIS in a better footing for future?
  • Do you have any recommendations about how AngularJS 1.x and new JavaScript framework can co-exists? Or, do you think that it is better to bite the bullet and rewrite everything into the new JavaScript framework?

Thanks for your feedback.

So I too would like to hear people’s thoughts on the questions Ashraf has put forth, and I’d put extra emphasis on the last one (rephrased): What is a path forward which avoids a drop-everything and re-write?

Best,

Josh

On Thursday, March 29, 2018 at 6:31:34 AM UTC-7, ashraf...@jsi.com wrote:

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

To post to this group, send email to openlm...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/5c6841d4-efe0-4554-beef-41afbc2b1c3d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Darius JazayeriPrincipal Architect - Global Health
Email
djaz...@thoughtworks.com

Telephone
+1 617 383 9369

ThoughtWorks

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

To post to this group, send email to openlm...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CAOKb-R7EOCisBvqAsu%3D3GSLNThQOy%2B3mOsS3Fd%2Bm8D5hvxuExg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

To post to this group, send email to
openl...@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/aba0861e-2a18-4d37-99ab-9592a4396bed%40googlegroups.com
.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to openlmis-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/30804999-b2d2-42e6-b12e-d1ea0b698294%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Nikodem Graczewski

Software Developer

ngraczewski@soldevelo.com