So, after months of research and prep work, I bit the bullet and rewrote a lot of the Clinical Meteor boilerplate into React. Generally speaking, I’m really happy with everything, and it’s working great. The initial UI renderings were basically everything I had hoped they would be, and React is proving to be the right decision.
However. We had a number of constraints which prevented us from using the typical tutorials and walkthroughs. Constraints including Material UI design, opacity rendering requirements, an interest in avoiding mixins, and wanting to leapfrog to using
extends React.Component syntax. So, we sort of started with the libraries that we really wanted to use for our user interface (React-Toolbox, SCSS, etc) and worked backwards.
Everything is working really great… except for props. We’re basically just using Session variables, and bypassing the props cascade entirely. Using
this.data instead of
this.props. That’s worked for the past few months; but it’s come with costs and technical debt. We’ve got a console log full of warnings and error messages, which I’m not entirely sure how to debug.
The app works surprisingly well despite all these warnings. However, as you might imagine, there’s noticable refresh lag. Recently, things have deteriorated to the point that clicking on the account signin/signout button will cause the entire app to pause for a few seconds and refresh.
So… it’s time to pay down the technical debt. And frankly, on this one, I could use some help. If there are any React wizards out there in the audience, I could really use some help in sorting out what’s going on with these props and figure out an architecture strategy for the React classes in my app. I’m hoping for a half-day or full-day working session maybe?
I sort of need for this graduate school and a pending client project; so I can compensate hours worked (payment through venmo?); and the code will remain open-source.
Source code to the app is at http://github.com/clinical-meteor/meteor-on-fhir