OHIF Viewer within React

[EduardoSantanaSeverino]

I am trying to run the OHIF Viewer inside a simple react application but I am getting the error posted below.

Is OHIF Viewer within React even supported?

Any suggestion to run OHIF Viewer inside a React App?

I went through the following steps:

Sample React App from: https://create-react-app.dev/docs/getting-started/
GitHub repo: https://github.com/EduardoSantanaSeverino/OhifViewerReact

1:

npx create-react-app my-app
cd my-app
yarn add @ohif/viewer

2. add OHIF Viewer inside the app.js, please see the repo for details.

yarn start

3. then got the following errors:

Starting the development server...


<--- Last few GCs --->

[30813:0x3f29ab0]    61422 ms: Mark-sweep 2016.0 (2051.1) -> 2015.1 (2051.1) MB, 1890.1 / 0.1 ms  (average mu = 0.188, current mu = 0.099) allocation failure scavenge might not succeed
[30813:0x3f29ab0]    64409 ms: Mark-sweep 2016.2 (2051.3) -> 2015.4 (2051.3) MB, 2784.6 / 0.0 ms  (average mu = 0.126, current mu = 0.068) allocation failure GC in old space requested


<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x13725d9]
Security context: 0x16340b4808a1 <JSObject>
    1: mark [0x33f926fe4a31] [/home/eduardosantana/code-work/wimtach/test-viewer2/my-app/node_modules/@babel/generator/lib/source-map.js:~45] [pc=0x307bf0218b94](this=0x0189bc0034d9 <SourceMap map = 0x3697629b4a01>,432437,126,197244,100,0x0234db9801b1 <null>,0x0234db9801b1 <null>,0x0234db9806e1 <false>)
    2: token [0x53e2ddc3e01] [/home/eduardosantana/code-work...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

Writing Node.js report to file: report.20200216.211915.30813.0.001.json
Node.js report completed
 1: 0x9d8da0 node::Abort() [/home/eduardosantana/.nvm/versions/node/v12.13.0/bin/node]
 2: 0x9d9f56 node::OnFatalError(char const*, char const*) [/home/eduardosantana/.nvm/versions/node/v12.13.0/bin/node]
 3: 0xb37dbe v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/home/eduardosantana/.nvm/versions/node/v12.13.0/bin/node]
 4: 0xb38139 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/home/eduardosantana/.nvm/versions/node/v12.13.0/bin/node]
 5: 0xce34f5  [/home/eduardosantana/.nvm/versions/node/v12.13.0/bin/node]
 6: 0xce3b86 v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [/home/eduardosantana/.nvm/versions/node/v12.13.0/bin/node]
 7: 0xcefa1a v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/home/eduardosantana/.nvm/versions/node/v12.13.0/bin/node]
 8: 0xcf0925 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/home/eduardosantana/.nvm/versions/node/v12.13.0/bin/node]
 9: 0xcf3338 v8::internal::Heap::AllocateRawWithRetryOrFail(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [/home/eduardosantana/.nvm/versions/node/v12.13.0/bin/node]
10: 0xcb9c67 v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType) [/home/eduardosantana/.nvm/versions/node/v12.13.0/bin/node]
11: 0xfefcf9 v8::internal::Runtime_AllocateInOldGeneration(int, unsigned long*, v8::internal::Isolate*) [/home/eduardosantana/.nvm/versions/node/v12.13.0/bin/node]
12: 0x13725d9  [/home/eduardosantana/.nvm/versions/node/v12.13.0/bin/node]
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

[EduardoSantanaSeverino]

@dannyrb
Thanks for your time. I am looking to add a feature request. but I am facing this error.

[dannyrb]

You'll notice all of our own npm scripts set a flag to allow for more than the default amount of memory: --max_old_space_size=4096

Until we reign in our app's size, you'll likely need to do something similar when consuming @ohif/core.

We have some guidance around "embedding" the viewer, but not with your current approach: https://docs.ohif.org/deployment/#embedded-viewer

We could have better tests/support for what you're attempting, but I am curious how much demand their is for embedding/usage with this approach, and the reasons users are opting for it. If you're using all of @ohif/viewer, why not just host it at a /viewer or something similar?

[leoc]

I am also trying to integrate the viewer within my React App. I want to interface with other components outside the viewer. The direct attempt seemed most plausible to me.

I am using an ejected create-react-app template with:

  "scripts": {
    "start": "node --max_old_space_size=8192 scripts/start.js",
    "build": "node --max_old_space_size=8192 scripts/build.js",
    "test": "node --max_old_space_size=8192 scripts/test.js"
  },

A size of 4096 does not cut it. And even with 8192 I get:

<--- Last few GCs --->

[276661:0x55bb116506d0]   325288 ms: Mark-sweep 8155.6 (8201.7) -> 8154.3 (8201.2) MB, 4125.3 / 0.0 ms  (average mu = 0.119, current mu = 0.020) allocation failure scavenge might not succeed
[276661:0x55bb116506d0]   325950 ms: Scavenge 8155.0 (8201.2) -> 8154.4 (8201.2) MB, 661.9 / 0.0 ms  (average mu = 0.119, current mu = 0.020) allocation failure 


<--- JS stacktrace --->

==== JS stack trace =========================================

    0: ExitFrame [pc: 0x55bb0f33cbd9]
Security context: 0x1ae3be900921 <JSObject>
    1: SourceMapConsumer_allGeneratedPositionsFor [0x30261dbad9e9] [/home/arthur/projects/integration-view-component/node_modules/@babel/core/node_modules/source-map/lib/source-map-consumer.js:~178] [pc=0x3d1d6d219d9](this=0x30261dbbfbd9 <BasicSourceMapConsumer map = 0x1a0b4c719bc1>,0x02ae57c40169 <Object map = 0x1a0b4c70bcf1>)
    2: /* anonymous...

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

Writing Node.js report to file: report.20200303.102504.276661.0.001.json
Node.js report completed
 1: 0x55bb0e9d7711 node::Abort() [/usr/bin/node]
 2: 0x55bb0e9d9d05 node::OnFatalError(char const*, char const*) [/usr/bin/node]
 3: 0x55bb0eb4d382 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [/usr/bin/node]
 4: 0x55bb0eb4d5e8 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [/usr/bin/node]
 5: 0x55bb0ecd7906  [/usr/bin/node]
 6: 0x55bb0ecd7a49  [/usr/bin/node]
 7: 0x55bb0ecea22d v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [/usr/bin/node]
 8: 0x55bb0eceaf58 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/usr/bin/node]
 9: 0x55bb0eced48c v8::internal::Heap::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/usr/bin/node]
10: 0x55bb0eced4f4 v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/usr/bin/node]
11: 0x55bb0ecb299b v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/usr/bin/node]
12: 0x55bb0efe3540 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [/usr/bin/node]
13: 0x55bb0f33cbd9  [/usr/bin/node]
error Command failed with signal "SIGABRT".
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

I followed the advice on the "Embedding the viewer" documentation page:

installViewer is a convenience method that pulls in some dependencies that may not be compatible with existing react apps. @ohif/viewer also exports App which is a react component that takes the configuration outlined above as props. You can use it as a reusable component, and to avoid react version conflict issues.

[dannyrb]

There is a related issue for this floating around. We do need to address this. I believe part of the issue is building everything from source. The other part is likely the large codecs bundle from cornerstone-wado-image-loader.

Unfortunately, we're a bit short on bandwidth and resources, and this is not prioritized for the core team. I am more than happy to review a PR that addresses the underlying issue, and welcome any feedback/guidance from the community that may help us solve this. If this is a blocker for you, you can investigate and author a pull request, or reach out to an OHIF consultant.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[codecraft302]

The problem is active, did the same as the creator of the issue, used --max_old_space_size = 8192.
Are there solutions?

[codecraft302]

Found a solution.
GENERATE_SOURCEMAP=false
in .env file

[EduardoSantanaSeverino]

Hi Guys, back then, it worked for me with:

--max_old_space_size = 8192

But I am not longer using the library.

Regards,

Eduardo

[danihodovic]

We could have better tests/support for what you're attempting, but I am curious how much demand their is for embedding/usage with this approach, and the reasons users are opting for it. If you're using all of @ohif/viewer, why not just host it at a /viewer or something similar?

In our case we want to re-use the viewer, study list and tools from @ohif/ui. We want to build an app around components in @ohif/ui.

The OHIF docs state that @ohif/ui “is a React Component library that contains the reusable components that power the OHIF Viewer.”...Aims to “aid rapid application development for context specific viewers“."

It seems like OHIF isn't composable because packaging it in an existing React app causes memory errors.

If you are using OHIF to build "context specific viewers", how do you go about using it as a library rather than embedding the entire @ohif/viewer app?

I've managed to build the project by disabling sourcemaps (GENERATE_SOURCEMAP=true), but that makes the development / debugging process much harder.

[ketki-kerkar]

Hello,
We were trying to integrate OHIF Viewer with GCP and ReactJs. W e are running ohif viewer on port 3000 locally. In another reactjs Application we have iframe. In this iframe we are opening ohif viewer. When we give local host 3000 it loads the initial page and works fine. However when we try to open a particular image by giving its url in src of iframe eg.:http://localhost:3000/viewer?StudyInstanceUIDs=1.2.840.113619.2.15.1008000062035011254.825190719.2.31 Then the image is not loading.
The console shows following error

We have already gone through documentation. If anyone has the solution to this it will be really helpful.
Thank you in advance for any assistance.