Closed phet-steele closed 6 years ago
Supplying a tandem for the button model resolves the problem, but why was the optional and not supplied tandem being added in the first place? First of all, it was marked as "supplied", and I'm not sure why. This would be good for @zepumph to investigate further, and let me know if we should join forces.
I see. In the above commit the direct problem was fixed, but there is a greater problem here.
First of all, it was marked as "supplied", and I'm not sure why
It wasn't marked as supplied
, but rather it's child was. This is because supplied
and required
aren't being passed to children in the createTandem()
call.
options = _.extend( { static: this.static, enabled: this.enabled }, options );
It should also be cherry picking supplied
, and potentially required
. I'm not sure.
Then a problem like the above tandem "forcesAndMotionBasics.optionalTandem564.startedCallbacksForFiredEmitter" would never show up, since it is a child of the optional and not supplied 564. I think that is the best way to go. What do you think @samreid?
I'm not really sure. If a parent is supplied does that mean the child is also supplied? If the parent is required, does that mean the child is required? This seems like it warrants discussion.
@samreid @zepumph do you see this as an "aesthetic" issue or one that needs to be fixed before a version of FAMB can be deployed?
@jessegreenberg you are good to go on this one! I implemented the general solution by passing the proper options to children in createTandem()
. I'm going to leave this open for @samreid to review, but I think this will certainly work for FAMB.
I think @zepumph implemented this in the correct way. I'm not 100% sure the behavior will be correct for all corner cases, but hopefully it will come up on Bayes or during RC testing if not.
Here: http://www.colorado.edu/physics/phet/dev/html/forces-and-motion-basics/2.3.0-phetiorc.3/wrappers/instance-proxies/instance-proxies.html?sim=forces-and-motion-basics&relativeSimPath
There are many many TEmitter proxies that have the name
optionalTandem###
within them. This is no bueno, and I'm not sure why it is happening. It would be better to have the names of the objects the Emitter is for, otherwise it's impossible to know for sure. For example a good Emitter where I know exactly what it applies to:forcesAndMotionBasics.navigationBar.homeButton.startedCallbacksForFiredEmitter: TEmitter
A bad Emitter that looks quite arbitrary:
forcesAndMotionBasics.optionalTandem564.startedCallbacksForFiredEmitter: TEmitter
No idea if I should assign @zepumph or not, but I did it! Can't stop me now! Seen on macOS 10.12.6 Chrome. For phetsims/QA#42.