You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, this will spew a bunch of errors on the console, "resource is already being fetched". It violates the expectation that in
const r1 = new Resource("/path");
const r2 = new Resource("/path");
const r3 = r1.clone();
all three resources could be used interchangeably. This is not true, because r1 and r2 can run at the same time, but r1 and r3 cannot.
I'm not totally clear on what the comment means about "breaking the request scheduler", so I'm sure there are implications to consider, but on the face of it, I think clone() needs to always make a new Request. If it isn't going to make a new one, the docs need to carefully explain the implications of clone(), and describe how a clone is different from a first-class Resource.
In the short term, getDerivedResource({}) (note the empty object as sole argument) is basically a drop-in replacement for how I expected clone() to work.
The text was updated successfully, but these errors were encountered:
The reason is that clone creates a shallow copy, so the internal Request object is shared. The Request object is managed by one of the underlying systems within Cesium (eg Terrain, Imagery, etc), so making a copy would break a lot of stuff.
The clone method was there so that we can make a copy of a resource passed into other Cesium classes as an argument, preventing the user from changing resource properties without us knowing. clone should probably be marked private as this behavior doesn't make sense if used outside the Cesium code. Another alternative is fix clone to make a deep copy and add a private method with the current functionality for internal use.
Either of those options sounds good -- I know it's a new class and the API is probably not set in stone just yet. I mentioned a few similar (small) things in #6205 . I don't expect it any time soon but maybe an example (blog post or Sandcastle) showing a few use cases for Resource would help clarify?
Read this comment then consider this code:
Currently, this will spew a bunch of errors on the console, "resource is already being fetched". It violates the expectation that in
all three resources could be used interchangeably. This is not true, because r1 and r2 can run at the same time, but r1 and r3 cannot.
I'm not totally clear on what the comment means about "breaking the request scheduler", so I'm sure there are implications to consider, but on the face of it, I think
clone()
needs to always make a new Request. If it isn't going to make a new one, the docs need to carefully explain the implications ofclone()
, and describe how a clone is different from a first-class Resource.In the short term,
getDerivedResource({})
(note the empty object as sole argument) is basically a drop-in replacement for how I expectedclone()
to work.The text was updated successfully, but these errors were encountered: