Cornerstone + JS Frameworks

[mow...@reflexionmedical.com]

Hi, all;

I wanted to see if anyone had any luck integrating Cornerstone with a modern JavaScript framework like Angular2 or React. I've been working with Cornerstone and Angular2 and am finding it less than intuitive to get the two to interact seamlessly (mostly centered around timing of DOM events and passing data from Angular2 to Cornerstone and vice versa).

I'd love to talk through some of the issues with someone who has more experience integrating Cornerstone into a JS framework who might have experienced some of these same issues.

Thanks,

--

Michael Owens

@mko

[Leonardo M. Ramé]

I don't know Angular2 and React, but I use Cornerstone+Angular 1 without issues.

[mow...@reflexionmedical.com]

When you're interacting with Cornerstone enabled images, are you passing data in real-time to your Angular1 instance or are you doing pure DOM manipulation to manage your real-time Cornerstone interactions and then passing the data to Angular1 upon a specific event (i.e. a save button or similar)?

My biggest issue seems to be using event data generated by Cornerstone (or maybe more accurately CornerstoneTools) to manage UI state in Angular2, so maybe it's an issue more of my limited experience with Cornerstone (only been using it a couple of weeks now).

Thanks for the quick reply.

--

Michael Owens

@mko

[Chris Hafey]

If anyone has any suggestions on how to make cornerstone more flexible with respect to other frameworks, feel free to let me know!

[mow...@reflexionmedical.com]

Most of the issues might have to be worked around until cornerstone is updated to an ES6-compatible module. I'm finding that—in general—Angular2 and packages using jQuery for DOM manipulation and data exchange don't work wonderfully together. It's mostly centered around application and component lifecycle based heavily around Observables not matching the expected "run whenever this script is executed" pattern that ES5 and jQuery-based code uses.

The biggest issue seems to be with the image loaders and cornerstoneTools implementations, not the cornerstone-core, anyway. I've checked just about everything (and was able to confirm CORS is not the problem), but I continue to get the error message "loadImage: no image loader for imageId" associated with an undefined value for the imagePromise from loadImage, and it's not obvious how that comes to pass. CornerstoneWADOImageLoader seems to be registering image loaders properly, but using a valid wadouri or even the deprecated dicomweb or the plain http URL as the imageId never seems to work. The URLs were tested via some of the cornerstone demos and a non-Angular2 local cornerstone app, and they worked, so I know the issue isn't with the URL either. 

--

Michael Owens

@mko

[Chris Hafey]

Sounds like a scoping issue - are you loading the cornerstone files via some Angular mechanism?  If so, it may wrap each one in a closure hiding the modules from each other.  Angular may have a way of not doing this (and thus polluting global namespace) - I know meteor does.  Alternatively you could combine all of the cornerstone files into one big file so everything is scoped to a single closure.

Chris

[mow...@reflexionmedical.com]

After a few days away, I tackled the problem a little more in-depth today. It is definitely a scoping issue, but the cause of the scoping issue still eludes me. I found a workaround though.

I've found that I can get the DICOM images to load properly from localhost using the WADOImageLoader as expected in a barebones Angular2 + Cornerstone app. Using that same process in our actual app, I found that I was still running into an issue wherein the WADOImageLoader gets all the way to the getImagePromise step of loadImage or loadAndCacheImage call prior to resolving the ImagePromise and can't load because it finds the wadouri scheme properly but has an empty imageLoaders object (i.e. cornerstone.registerImageLoader failed to register the imageLoaders object). Interestingly, removing the cornerstone.registerImageLoader code from the JS closure didn't help resolve the scoping issue with cornerstone.loadImage but removing the cornerstoneWADOImageLoader function loadImage from the closure and using it directly as a global function loaded the image properly.

I think this goes back to the style by which Cornerstone is written being fairly incompatible with the ES6 / Angular2 way of doing things with scoping to a specific module/component being preferred over creating global namespaces or closures. Additionally, really interacting with the DOM directly is kind of frowned upon. The preferred mechanism is to have your own renderer render a component (so you could, for example, render components all in web workers and stitch the rendered components together in the browser or server-side). I understand the reasons why cornerstone does direct DOM manipulation (honestly, I'm not sure any graphics manipulation like cornerstone, d3.js, and similar libraries will be done in that manner without significant rewrites).

Anyway, end result is that I'm going to likely hand-roll an alternative to the cornerstoneWADOImageLoader that works better with Angular2, since the core cornerstone libraries besides the ImageLoaders seem to work fine with Angular2. The big problem is being able to communicate the data from the Angular2 app into the image loader, load the image, and propagate data from cornerstone and DOM events back into Angular2 when it's time to update data in the database.

- Michael

[Chris Hafey]

It could be the order in which angular loads the files.  Cornerstone.js must be loaded before cornerstoneWADOImageLoader.js.  A few other comments:

cornerstone was designed almost two years ago before ES6 modules even existed.  I do have plans to do a version 2.0 of cornerstone which will be based on ES6 modules (and other breaking changes) - hopefully this effort will start later this year.

The only DOM manipulation cornerstone does is create a canvas element under the div.  I am open to exploring ways to better integrate with the modern DOM controlling JS frameworks if that is required in the version 2.0 effort.

Chris

[Michael Owens]

I'm actually not using Angular to load the imaging libraries at all anymore. I removed that possibility last week.

I'm happy to help prepare for and author cornerstone 2.0, as we're going to do a LOT with imaging over the next two years and are entirely ES6 / TypeScript based.

- MKO

Sent from my iPhone

--
You received this message because you are subscribed to a topic in the Google Groups "cornerstone platform" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cornerstone-platform/c8sHSwZaBBQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cornerstone-plat...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cornerstone-platform/cce5c2cc-8f19-46bc-9012-d5f2ce24232c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Chris Hafey]

OK cool, maybe I should just start the effort - nothing better than an itch that needs scratching eh?

To unsubscribe from this group and all its topics, send an email to cornerstone-platform+unsub...@googlegroups.com.

[Michael Owens]

Sure. Let me know what I can do to help. I'm happy to start the effort as well. I'm already heavily involved in authoring TypeScript and ES6 modules.

- MKO

Sent from my iPhone

To unsubscribe from this group and all its topics, send an email to cornerstone-plat...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cornerstone-platform/f6f267c1-763a-4b75-8492-64c8ff284690%40googlegroups.com.