Closed pixelzoom closed 1 year ago
Here's the complete set of ObservableArrays that are featured in natural-selection-overrides.js. None of these can currently be migrated.
"naturalSelection.introScreen.model.graphs.proportionsModel.previousCounts": {
"phetioFeatured": true
},
"naturalSelection.labScreen.model.graphs.proportionsModel.previousCounts": {
"phetioFeatured": true
},
"naturalSelection.introScreen.model.graphs.populationModel.dataPoints.brownFurPoints": {
"phetioFeatured": true
},
"naturalSelection.introScreen.model.graphs.populationModel.dataPoints.totalPoints": {
"phetioFeatured": true
},
"naturalSelection.introScreen.model.graphs.populationModel.dataPoints.whiteFurPoints": {
"phetioFeatured": true
},
"naturalSelection.labScreen.model.graphs.populationModel.dataPoints.brownFurPoints": {
"phetioFeatured": true
},
"naturalSelection.labScreen.model.graphs.populationModel.dataPoints.floppyEarsPoints": {
"phetioFeatured": true
},
"naturalSelection.labScreen.model.graphs.populationModel.dataPoints.longTeethPoints": {
"phetioFeatured": true
},
"naturalSelection.labScreen.model.graphs.populationModel.dataPoints.shortTeethPoints": {
"phetioFeatured": true
},
"naturalSelection.labScreen.model.graphs.populationModel.dataPoints.straightEarsPoints": {
"phetioFeatured": true
},
"naturalSelection.labScreen.model.graphs.populationModel.dataPoints.totalPoints": {
"phetioFeatured": true
},
"naturalSelection.labScreen.model.graphs.populationModel.dataPoints.whiteFurPoints": {
"phetioFeatured": true
},
@arouinfar can you please comment on the desired instrumentation capabilities/defaults/flexibility for ObservableArray? Specifically:
ObservableArray
without featuring its elementAddedEmitter
, elementRemovedEmitter
and lengthProperty
?Once we hear about the design recommendations, we can adjust the implementation accordingly.
Two days ago in "When should Emitters be instrumented?", @zepumph summarized in https://github.com/phetsims/phet-io/issues/1896#issuecomment-1544537238:
From PhET-iO meeting today, we will add some technical-guide documentation and call it a day:
- Most likely you don't need to instrument Emitters during initial dev first pass.
- Some Emitters are important to the functionality of the sim (CCK circuitChangedEmitter or elementAddedEmitter).
- Emitters can be instrumented to assist in a more rich data stream (we aren't currently designing this too much)
- We aren't going to eagerly or consistently instrument emitters in common code.
The current implementation of ObservableArray doesn't seem to be at all consistent with those conclusions. Not only does featuring an ObservableArray cause its Emitters to be featured (with no way to opt out), but the Emitters also inherit the featured-ness of the ObservableArray (again with no way to opt out).
Also noting that requiring the Emitters to be instrumented if the ObservableArray is instrumented doesn't "assist in a more rich data stream". It results in spamming of the data stream in cases where there are many dynamic elements - for example bunnies in Natural Selection, particles in Gas Properties, etc.
@samreid asked:
- Should you be able to feature the ObservableArray without featuring its elementAddedEmitter, elementRemovedEmitter and lengthProperty?
Absolutely. And PhET has an established pattern for doing that, which was not done here. Like Node's visiblePropertyOptions
and enabledPropertyOptions
, ObservableArray should have elementAddedEmitterOptions
, elementRemovedEmitterOptions
, and lengthPropertyOptions
.
- Should you be able to specify arbitrary featured-ness for all 4 of those things? Are any of them connected?
Yes, via elementAddedEmitterOptions
, elementRemovedEmitterOptions
, and lengthPropertyOptions
. And no, they should not be connected.
- What should the defaults be? Should any of the defaults be connected to options (like if the ObservableArray is featured, that would default the children to featured too? But maybe that is confusing and complicated and things should just be independent).
I defer to designers. But defaults should be designed. But again, the same pattern used by Node should be used here.
I changed the title of this issue to reflect the fact that the "brokenness" of ObservableArray's API is not limited to phetioFeatured
. It's a broader problem, including how elementAddedEmitter
, elementRemovedEmitter, and
lengthProperty` are instrumented, and how their metadata is specified.
I added observableArray.elementAddedEmitterOptions, elementRemovedEmitterOptions, and lengthPropertyOptions. In running precommit hooks, the only API that was altered by this was CCK, so I committed https://github.com/phetsims/circuit-construction-kit-common/commit/43cf0dfef5f5d035c983551b85b675f84170139b to keep those featured aspects the same. However, I wasn't sure that the circuitElements.lengthProperty should be featured, or if that was just by happenstance. @arouinfar can you please comment on that?
@pixelzoom can you review this change or do you want to run it past @zepumph first?
@arouinfar can you please comment on that?
I'm not familiar with ObservableArray, so it would be helpful to review in the context of a few sims. Can you point me to some phetioIDs of ObservableArray @samreid? I see some reference to Natural Selection in this issue, but I wouldn't say I know that sim very well. Examples from another sim or two would be helpful.
@pixelzoom can you review this change or do you want to run it past @zepumph first?
Three problems with https://github.com/phetsims/axon/commit/93206adfad3b4df82459005ca2bfbf888b43f3f8.
(1) The types of elementAddedEmitterOptions
, elementRemovedEmitterOptions
, and lengthPropertyOptions
are incorrect. They allow options that are the responsibility of ObservableArray.
(2) There is still no way to opt-out of instrumenting elementAddedEmitterOptions
, elementRemovedEmitterOptions
, and lengthPropertyOptions
.
(3) Again... Based on decisions in https://github.com/phetsims/phet-io/issues/1896#issuecomment-1544537238, the default should be to NOT instrument the Emitters. And I don't believe that any designer has requested these Emitters to be instrumented -- I had separate conversations with @arouinfar and @amanda-phet today.
Here's a patch that I believe addresses (1) and (2). @samreid please apply, review, and (if you think it's OK) commit.
Addressing (3) would involve changing the defaults for elementAddedEmitterInstrumented
, elementRemovedEmitterInstrumented
, and lengthPropertyInstrumented
, and would likely require API changes to some sims.
EDIT: You may want to rename elementAddedEmitterInstrumented
to phetioElementAddedEmitterInstrumented
etc., to be consistent with Node's phetioVisiblePropertyInstrumented
. On the other hand, I've never liked phetioVisiblePropertyInstrumented
and would prefer visiblePropertyInstrumented
.
Another problem with https://github.com/phetsims/axon/commit/93206adfad3b4df82459005ca2bfbf888b43f3f8:
(4) Destructuring should not be used in place of combineOptions
here, it is not type-safe. For example, this passes a bad option to new Emitter
and results in no tsc errors:
const junk = { foobar: true };
const elementAddedEmitter = new Emitter<[ T ]>( {
tandem: options.tandem.createTandem( 'elementAddedEmitter' ),
parameters: [ emitterParameterOptions ],
phetioReadOnly: true,
hasListenerOrderDependencies: options.hasListenerOrderDependencies,
...options.elementAddedEmitterOptions,
...junk
} );
Here's a patch that addresses that problem too.
That patch looks good to me. I removed the "foo" example and will commit the patch shortly. After that, we can investigate (3) from https://github.com/phetsims/axon/issues/437#issuecomment-1548797660
I opened a few side issues for related topics. See above.
When I change (3) above like so:
The changes in CCK seem undesirable--it uninstruments the circuitElementAdded and removed emitters, which seem important for clients that want to customize objects on creation. But I could compensate for this by opting in to that instrumentation. Not sure if we want to instrument circuitElements.lengthProperty
or not.
There are other changes in Natural Selection which I'm unfamiliar with.
@pixelzoom how do you want to proceed?
The changes in CCK seem undesirable--it uninstruments the circuitElementAdded and removed emitters, which seem important for clients that want to customize objects on creation.
What is "undesirable" about it?
Is it that you need to override the defaults and you don't like having to add the extra options? What's not typical about that? I spend an enormous amount of time adding verbose options to override PHET-iO defaults, why should CCK be different?
Is it that you think the default should be "true"? If that's the case, please discuss with designers. My discussions with @arouinfar and @amanda-phet suggest that the defaults should be false. My experience with sims also suggests that the defaults should be false. And (again) https://github.com/phetsims/phet-io/issues/1896#issuecomment-1544537238 specifically says that Emitters should NOT be instrumented by default, and instrumentation should be opt-in.
@pixelzoom how do you want to proceed?
Again from https://github.com/phetsims/axon/issues/437#issuecomment-1546705710:
What should the defaults be? ...
I defer to designers. But defaults should be designed.
So... Discuss the defaults with designers. And if true
is an acceptable default for elementAddedEmitterInstrumented
and elementRemovedEmitterInstrumented
document why that exception is appropriate for the decisions made in https://github.com/phetsims/phet-io/issues/1896#issuecomment-1544537238 .
I believe we are in agreement with the desirable defaults and it does not need to be discussed with designers. I'll commit momentarily.
I wrote this patch to make the element added/removed and length property uninstrumented by default:
I also updated CCK and NS to keep the APIs the same. However, before committing, we should schedule a short 10 minute meeting with @samreid @zepumph and @pixelzoom to make sure we are in agreement about how to proceed.
See also https://github.com/phetsims/phet-io/issues/1896#issuecomment-1557832042 where @pixelzoom said:
We decided to delete
elementAddedEmitterInstrumented
,elementRemovedEmitterInstrumented
, andlengthPropertyInstrumented
.I ran into other problems with
export type ObservableArrayOptions<T>
, where PhetioObjectOptions were duplicated. @zepumph volunteeered to take the lead on finishing this off, see patch below.. . .
Ok excellent, @pixelzoom will you please review. I updated the options pattern, and removed those options. Please review.
Looks great. Closing.
I encountered this problem when migrating natural-selection-overrides.js into code for https://github.com/phetsims/natural-selection/issues/331.
natural-selection-overrides.js contains:
... where
previousCounts
is anObservableArray
, defined in ProportionsModel.ts. Here's how I expected to be able to move the above override into code:This did not go well. The
phetioFeatured
option tocreateObservableArray
has a serious problem. It's not only applied to the ObservableArrayPhetioObject. It's also applied to 3 related Properties, which we do not want to feature in Natural Selection. Here's the relevant code in createObservableArray.ts:So... It's currently impossible to properly feature an ObservableArray via code.