WIP: Migrate UI to React

[swederik]

This issue tracks the progress of migration to React / Redux from Meteor for the OHIF Viewer application.

Live demo: https://deploy-preview-321--ohif.netlify.com/demo/

We have had a significant amount of requests to migrate off of Meteor to allow the OHIF application and components to be more easily reused in other applications. This change will also make it easier to decouple the application from the server-side component, which is unnecessary if you aren't using DIMSE to communicate with PACS. This Issue will track the work on that front.

If you want to contribute: Please make a comment in this issue to claim some components that you will work on. You can make Pull Requests to the 'react' branch which will be reviewed and merged.

We do not have a timeline for when this work will be completed. If you want it to be done faster, pick up some of the work and help us get it done.

Migration Plans

1. Consolidate packages and push logic out of OHIF into lower-level libraries (e.g. dcmjs, dicomweb-client, cornerstoneTools) (https://github.com/OHIF/Viewers/pull/297)
2. Start depending on NPM versions of packages (e.g. moment.js) instead of Atmosphere versions
3. Port the Blaze UI to React, but continue to use Meteor's build process. Start with the Viewer, then move to the Study List. Use Crowds Cure Cancer code as necessary.
4. Switch application state management to Redux. Remove Session, Tracker, ReactiveVar, and ReactiveDict usage.
5. Gap analysis: What prevents us from switching to create-react-app and dropping the Meteor build process? (e.g. Minimongo?, SimpleSchema?)
6. Move OHIF UI to NPM packages
7. Remove 'blaze-html-templates' and other blaze-specific packages.
8. Switch Routing to use react-router(-dom) instead of Iron / Clinical Router
9. Remove any remaining dependencies on Meteor packages (e.g. cultofcoders:persistent-session) (this has actually been done already on a private fork. Will merge this back ASAP)
10. Revisit our choice of Stylus as a CSS language (what would be easiest for consumers of the components? Pure CSS? Can we still do theming with another build process?)
11. Switch to create-react-app / Webpack instead of Meteor for the build process.

Viewer UI Migration Checklist (Updated Feb 19th, 2019)

Components TODO:

• CINE Play / Pause button
• Measurement Table (@galelis)
• Study List context menu
• Viewport right-click context menu (we have this in crowds cure cancer, should port it over)
• Theme selection dialog
• Server Information dialog in the Settings menu.

Non-Component TODO:

• StudyLoadingListener (broken after switch to plugins)
• StudyPrefetcher (broken after switch to plugins)
• Hanging Protocols (@swederik)

Other missing things:

• FEAT: Add Next / Previous Display Set buttons
• FEAT: Double-click thumbnail to load stack in active Viewport
• FEAT: Arrow Annotation tool + callback in react-cornerstone-viewport
• FEAT: Add the About modal
• FEAT: Stack scroll linking is not possible
• FEAT: Animate the transition between study list and viewer

Note: The Lesion Tracker-specific components can be done last, and will not block merging of React branch into master.

@vsoch @JamesAPetts

[EsrefDurna]

Hello @swederik this is a great news ! I will work with items under. -User Preferences

Thank you

Ash Durna

[swederik]

Short update on the React transition:

• @EsrefDurna you were right that it’s going to be easier to create a new folder. Initially the transition inside the Meteor app was working fine, but it seems like there is something wrong with the build process because it begins to ‘update npm dependencies’ on nearly every change. This takes > 1 minute, so development grinds to a halt.

• I added a folder here: https://github.com/OHIF/Viewers/tree/fc5bd73c1ed247b233bfc7ebed1fb00c990f98d5/OHIFViewer-react to start doing the transition.

• I have been consolidating the OHIF:* meteor packages into a single package here (https://github.com/ohif/ohif-core). Much of it will still be trimmed. It doesn’t do much yet. (There’s an even more in-progress branch there called ‘wip’)

• If anyone wants to help, the best thing you can do is pick a piece of the UI and start converting it from Blaze to React, and then contribute the updated version back to https://github.com/OHIF/react-viewerbase.

Hopefully next week the ohif-core package can be more useful and we can start filling things into that app. Note: It will not start at all if you try it right now, I’ve been trying to clean up the issues with dependencies in ohif-core (I would welcome any help with that!).

Some good places to start:

• The StudyList. Currently just renders Blaze inside the React template. [edit 12/14/2018 - work-in-progress by @maltempi] [edit 12/21/2018 - done by @maltempi] (https://github.com/OHIF/Viewers/blob/fc5bd73c1ed247b233bfc7ebed1fb00c990f98d5/Packages/ohif-study-list/client/components/StudyList.js#L17)
• The Measurement Table (@galelis)
• The page header
• User Preferences and the dependent form components [edit 12/21/2018 - work-in-progress by @maltempi][edit 01/04/2019 - done by @maltempi ]

My short term goal is to get the create-react-app version working with the study list and basic viewer (minus the measurement table) first, and then continue from there. Most of the re-usable logic should be in the ohif-core NPM package (on github, but unpublished), and the UI components within ohif/react-viewerbase. The actual application should be very small.

Some minor stuff:

• I’ve been trying to keep components ‘presentation-only’ as much as possible. They may have some internal state, but they know nothing of any components outside of themselves. They are given callbacks as properties (e.g. onThumbnailDrop or something). The react-viewerbase package is essentially just UI which knows when to call callbacks that is has been provided. The callbacks can be provided using Redux’s connect, and using mapDispatchToProps to hook up Redux actions to the callbacks that are provided. This seems like the cleanest way to do things. Eventually we could set up a design system for OHIF (e.g. like Shopify has: https://polaris.shopify.com/components/structure/card#navigation) which could be great for helping people build OHIF-based apps. Our awesome designer Dan is excited to help with this.
• Meteor Minimongo collections are being switched to arrays in the Redux store (not sure what else would be better)
• Meteor Session variables are also being pushed into the Redux store
• Iron Router has been replaced with react-router
• I’ve switched from the SimpleSchema package on Atmosphere to the newest version from npm (simpl-schema). I haven’t tested enough to know if this will cause issues. Upon review, it does look like we are using simple schema in a lot of places, many of which might not be necessary. I’m not sure what a better alternative would be (JSON Schema?).
• OAuth is temporarily removed, but will be replaced with the Auth.js class in Crowds Cure Cancer
• There is no longer any server-side component. We will have to figure out what to do with DIMSE support (create a separate node application?) later on. For now, I am avoiding that problem.
• Since there is no WADO Proxy anymore, you will encounter CORS issues if you try to test it. You’ll need to run a proxy in front of your PACS, if you aren’t already.
• We have a bunch of UI stuff (bounded, dimensional, draggable, dropdown, notifications, resizable) which seem to be jQuery plugins. I’ll keep these as-is for now, but I guess we will have to turn them into react components as well (or mixins or whatever their version of that is). We can look for off-the-shelf alternatives for these if they exist.

[vsoch]

hey everyone! I don't use react a lot, but I'd really like to help and learn - would it be feasible to assign a small and scoped task for me to do? If you can describe the basic steps, files involved, for going about this I can give it a go! If it's too complicated, then maybe we can figure out another way that I could help?

[EsrefDurna]

Hello @vsoch Thats a great idea and this project is a great way to learn react. I will have a look during this weekend and will try to find some tasks for you as well.

Thank you so much

[diaztula]

This is a fantastic initiative! I currently use Standalone OHIF Viewer within a React app but it has several limitations. Having OHIF implemented in React would open many new possibilities!

I would like to contribute to this project as well.

Cheers

[jamesg1]

Great work @swederik ! I use React regularly and working on a medical product using image viewers. Cornerstone/OHIF has been interesting to look into but I have a lack of knowledge on meteor.

Happy to help on some tasks to get the ball rolling.

Styled components is interesting around theming as it would be possible to switch out the theme.js file with different set of attributes to quickly change the look of ohif for clients. That or css modules are common now.

[onluiz]

This is an excelent initiative. React is a greate framework and I believe the final work here will be awesome.

I have worked with cornerstone for a couple of years now and I was always making plans to learn meteor so I could understand OHIF more deeply. Now with react I believe it will be easier!

I will be more than happy to contribute to this project as well.

[eggachecat]

Great! I have some experience in angular.js and vue.js.. I would like to contribute to this project ! And I think the interfaces of measurement may need some improved since it is pretty tricky to add some preloading measurement

[atony88]

@swederik @pieper Amazing work on migrating the Front-end to ReactJs.

I was able to run the react-app and now I am trying to connect it to our own DICM server. I changed the config file in /react-config/ccc.json and set the wadoUri, run

REACT_APP_CONFIG=$(cat ../../config-react/ccc.json)
yarn start

But I am still connecting to the same server and studies. It's also not clear to me where exactly the server settings are getting set. Is there any other configurations that needs to be done to connect it to another server?

[alvarosan]

Great work! also willing to contribute.

@swederik , what would be the way to go if I wanted to integrate a vtk.js-based custom visualization? My viewport is currently encapsulated in a React component. I saw you recently integrated OHIFVTKExtension (using that as a base for now), I will post here how it goes.

[TZubiri]

I know that mobile isn't officially supported, but it seems that the tech stack used provides an operative second-class citizen mobile app for cheap.

The react version is better than the meteor version in mobile, the old version required that the user request the desktop version through the browser to get a full view of the image, now the viewport fits almost entirely (my 1920*1080 screen at least) by default.

Here is a small list of mobile bugs: Images with series begin with the series list open, which hides the viewport rightmost half. The toolbar appears as a vertical unscrollable dropdown list. I can only choose length and angle, but they both seem to work as expected.

This means that CR images are viewable from mobile!

Congratulations.

[matthiasg]

If the important parts are written runtime independently so they could only be wrapped in React it would open the door to also use Vue (which is more friendly to UX Designers than React). I would offer to invest some time into this if this is a compatible long term goal.

[dannyrb]

We've silently pushed react to master as our new version 2. Expect an announcement early this week. Some features/functionality still need to be ported, but they will be completed iteratively instead of in this large batch form.

More information to come on how individuals can best contribute their varying skillsets to move things forward.