I am involved in creating a [React.Js][1] and [Flux][2] based module in OpenMRS. The tutorials/documentation available online is not exactly past the basic examples and though I am past the basic tutorial stage there are some use cases that have no solution which are obvious in any common front end environment. (If any developers are just starting out to do something in react and flux I might be able to help or point you in the right direction.)
I wanted to reach out to the community to see if anyone had worked on React.js and Flux or is fairly familiar with them to help us out if they have faced any of the issues we are facing.
[1]: https://facebook.github.io/react/
[2]: https://facebook.github.io/flux/
I’ve been interested to try out react.js, as people say good things about it, but sadly, don’t have the time.
I’m curious if there is a particular reason you wouldn’t consider using AngularJS for whatever it is that you’re doing. Because more has been done with OpenMRS and Angular, and you’re more likely to find informed advice on that front…
Haha, I think you should try it , I will have someone to bug around if I have some issues.
It is actually the reboot of the PHR modules (personalhr, lancearmstrong, phrjournal,phrmessaging). We are trying to build a WebAPI back-end based single module for them and the front end was chosen as React.Js as Angular is going through a phase change and version 2 will be released which is apparently not similar to its version 1. The person working on the frontend decided to go with React as it was going to have a long term support.
I am pretty new to both of them and my solutions are usually Jquery based which is not encouraged in these “new front end technologies”
You imply that just because AngularJS 2 is very different than v1, it will not have any upgrade path. That’s as silly as saying OpenMRS – which is much smaller – would leave all its developers stranded when upgrading to a major new version with no backward compatibility. As you can see with what we’re doing with Spring/Hibernate/Java upgrades, no one actually does that.
AngularJS 1.4.0 was just released 2 weeks ago, so development is still active and support will be around for quite a long time. Definitely long enough to develop clean upgrade paths.
Also @lluismf makes a really important point, we should try to unify around the same framework as much as possible if we want to maximize our ability to collaborate and help each other.
I would also like to add to the last point made by @lluismf in the previous email that the versioning for the frameworks(spring, hibernate) and for the modules(specially core modules) should happen across all the openmrs platforms to achieve consistency and unification with any new processes and developments that are happening with the system.
As for the front end development, the framework that would be suitable as per the user needs should be given more consideration. If AngularJS does that then yes this should be the way to go.
I would definitely echo Michael that ruling out Angular “because Angular 2
is coming” is flawed logic.
If the project is primarily building OpenMRS modules, and a UI in OpenMRS,
and wants to share effort and learnings with the community, I would
strongly suggest choosing Angular over React. If there are other
considerations, or this app has to fit in with other things in a
React-based stack, then the choice is understandable.
I am not sure if you are referring to React and Flux, if yes, then they are not exactly two different frameworks rather, both were created to go hand in hand by Facebook. I might not be able to point out the exact advantages of having them both together. As far as I can understand react introduces their basic concepts (this can get messy soon like all js) and flux is a way of organizing and managing them.
It is not flawed but is a different way to look at it. The person was new to both Angular and React and wanted to choose, rather choosing something that is in a phase shift he chose something that is not in any phase shift. This removes the overhead of not having an upgrade path sooner. React might also have a different version but not in the near future at least.
I agree to the point that we should try and unify around same frameworks as much as possible to maximize our ability to collaborate.
But, the whole point of shifting towards and API based architecture is allowing different UI frameworks to be compatible. And these will continue to arise, and we will have to continue accommodating them.
In this regards, I did recommend angular, I would have definitely chosen Angular as I am aware of the support from the community but, the decision was left to the front end developers as they would be developing it for the most part. I am joining development when most of the part has been completed. I have the work of making the developed code build and load as an OpenMRS module.
In a way it does makes sense similar to have parallel development as we are creating in module and module-ui structure implemented in the new modules like allergy and allergy-ui but, yeah having to figure out something new will always result in these complications.
Wanted to find out if anyone did try to meddle with React and OpenMRS, looks like we came early to the party, but I am hoping it would not be very different to integrating an Angular JS front end as finally they are pages that are depending on json content.
Ignoring whether “flawed” is too strong a word, I think the point is that “angular will shift to 2.0” is a bad reason to avoid developing an OpenMRS module in Angular, because there would be significantly more sharing of code and ideas from choosing the same technology as others are using.
But as you say, the app is already mostly written, and the priority was not to work closely with the OpenMRS community (which is not a problem); Flux and React are a fine set of tools, and we have REST web services that will work equally well with any JS framework. (Which is to say, per my other email today, that they work, but there are lots of gotchas!)
I’m quite curious to see how nicely things can be done with Flux and React. I can certainly imagine them making it easy to write a nice dashboard-of-widgets…
But looking at our transitions from Dojo, JQuery, Angular, am very sure we
shall learn a lot from your attempts to try out React.js
May be your efforts will result into making us now shift to React.js?
May be it will result into us improving our UI code to be less tightly
coupled to the JavaScript library? Looking at how fast new ones keep
popping up.
May be it will result into us confirming why we should really stick to
Angular in the meantime?
etc…
In summary, for all the past transitions, one has to make a first attempt,
against all the odds.
And there’s also Ember.js, Polymer … we can’t be sure which of them will be alive in a few years. Look at GWT dropped by Google mercilessly. Or Yahoo’s YUI also dead. For what I’ve read, some people like/don’t like Angular or React for different reasons.
@darius, @dkayiwa, @lluismf, I agree that with so many popping up there is no guarantee for any JS library, but the decision was not only based on the just on angular being phased out but that is one of the reasons I remember.
As for future support, I cannot guarantee but hope it will stay as Facebook has most of it’s code built on it, Instagram completely built on it, Khan Academy, Netflix and Yahoo Mail are also shifting to it.
There are two main advantages that I seem to notice:
The concept of unidirectional flow - this only allows the data to pass from a top down approach. This in my belief helps keep the code clean.
The concept of Virtual DOM - When an event occurs the the changes are implemented through updating the top portion of the code. With the new/modified data coming in, the Virtual DOM checks for what part of the page has any data change and refreshes only that part instead of refreshing the whole page.
So in conclusion as you might have guessed, it is the best fit for seamless UI experiece for large data display as tested here. But when a complete page reload is commonplace it doesn’t give the best results.I might be biased as I have meddled with React more than Angular for obvious reasons.
If the thing I’m trying works as I’m trying to plug a pure JS based UI in a module, it would be a great boost to parallel development in OpenMRS as it would allow any front end to be developed simultaneously and plugged in an API later and have it working. Which conceptually is what we are aiming at.
True in the case of Khan Academy and Netflix but, Instagram and Yahoo Mail handle CRUD operations at a great scale where R>C>D and rarely U is the scenario.Which is the use case even in OpenMRS but with more focus on patient record.
And actually they match this patient portal module in a way as it kind of is a network of people communication and updates. rather than record management.
I do agree to most of the points made by others earlier but my intention is not to convince everyone towards adopting React in the community rather testing it out and finding who among the community has any experience with React and networking with them
but Looking forward to try it(because of the freedom and simplicity it gives us) once i am completely done with AngularJS 
