Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move Viewer functionality to CesiumWidget class #11967

Closed
jjspace opened this issue May 3, 2024 · 2 comments · Fixed by #12202
Closed

Move Viewer functionality to CesiumWidget class #11967

jjspace opened this issue May 3, 2024 · 2 comments · Fixed by #12202

Comments

@jjspace
Copy link
Contributor

jjspace commented May 3, 2024

Feature

There is functionality that's currently in the @cesium/widgets Viewer class that is not in the @cesium/engine CesiumWidget class that is not directly related to the widgets we provide in @cesium/widgets but is valuable and useful to developers from an API perspective. Recently there was discussion of users wanting to use Cesium for the 3d view but roll their own UI and widgets. Installing only @cesium/engine and using the CesiumWidget is a great way to do that and reduce dependencies but there's more convenience we could offer like the Viewer does.

Things like:

  • Easy access to an entityCollection that's already set up to render in the viewer
  • a data source display already synced with the clock to update every tick (like needed in this forum question)
  • convenience functions like flyTo, zoomTo and trackedEntity

These make it harder and more confusing to developers that CesiumWidget is not a drop in replacement for Viewer when they don't want the extra widgets like the timeline or geolocator. I think we should move all the code in Viewer that doesn't interact with @cesium/widgets classes/components into the CesiumWidget so Viewer is more of a direct extends type class.

In other words I would expect:

const viewer = new CesiumWidget('container', { ...options });

to function the same as

const viewer = new Viewer('container', {
  ...options,
  baseLayerPicker: false,
  selectionIndicator: false,
  timeline: false,
  geocoder: false,
  // etc...
});
@cavencj
Copy link

cavencj commented May 13, 2024

Totally agree, nowadays the vast majority of instances don't need to use widgets and have to set false one by one during initialization

@jfayot
Copy link
Contributor

jfayot commented Sep 17, 2024

Is there any plan to work on this one soon?
If not, can I give it a try?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment