OHIF / Viewers

OHIF zero-footprint DICOM viewer and oncology specific Lesion Tracker, plus shared extension packages
https://docs.ohif.org/
MIT License
3.37k stars 3.39k forks source link

[Feature Request] expose zustand stores in a more native way #4527

Open JamesAPetts opened 3 days ago

JamesAPetts commented 3 days ago

What feature or change would you like to see made?

With 3.9 we got rid of the state sync service and are instead using zustand stores.

From within any other extension, we could previously get these in a kind of "native" ohif manner by:

const { stateSyncService } = servicesManager.services;
const { toggleOneUpViewportGridStore } = stateSyncService.getState();

Whereas now these are just exports straight off of the extension at top level, we should probably expose them in the utility module or have another module for such stores.

Internally the cornerstone extension grabs these from the monorepo:

import { useToggleOneUpViewportGridStore } from '../../default/src/stores/useToggleOneUpViewportGridStore';

Which is fine internally, but annonying if you have an external extension that wants to write/read to this state.

Why should we prioritize this feature?

It feels like a regression from 3.8's StateSyncService