To begin a code review, the responsible developer should:
[x] Copy this checklist to a new GitHub issue titled "Code Review" and labeled dev:code-review.
[x] Delete the Table of Contents section, since the links will be incorrect.
[x] Complete (or delete) the Specific Instructions section.
[x] Delete (or strikethrough) checklist items and sections that are not relevant.
[x] Replace {{GITHUB_ISSUE_LINK}} with links to GitHub issues.
[ ] Assign the GitHub issue to the developer who is doing the code review.
PhET Code-Review Checklist (a.k.a "CRC")
The responsible dev is responsible for removing the irrelevant parts
A checked-off item doesn't mean "no problem here", it means "it was reviewed"
Problems can be noted in side issues that reference this issue, or through // REVIEW comments in the code
Specific Instructions
[ ] Interactive Description is not supported for this simulation, and I removed that section from the code review checklist. Note package.json says interactiveDescrption: true in order to support keyboard navigation (which this simulation does support).
[ ] Synchronous kickoff meeting
[ ] Start with Projectile.ts, Field.ts, and PDLModel.ts (in that order)
[ ] Please review recent changes to StopwatchNode.ts and how it is used in Projectile Data Lab. (See options includePlayPauseResetButtons and otherControls.)
The following standard GitHub issues should exist. If these issues are missing, or have not been completed, pause code
review until the issues have been created and addressed by the responsible dev.
[x] Does the html file size seem reasonable, compared to other similar sims? UPDATE: 3MB for build/phet/en
[x] Does the sim start up? (unbuilt and built versions)
[x] Does the sim experience any assertion failures? (run with query parameter ea)
[x] Does the sim pass a scenery fuzz test? (run with query parameters fuzz&ea)
[x] Does the sim behave correctly when listener order is shuffled? (run with query
parameters ea&listenerOrder=random and ea&listenerOrder=random&fuzz)
[x] Does the sim output any deprecation warnings? Run with ?deprecationWarnings. Do not use deprecated methods in
new code.
Memory Leaks
Please note that dynamic allocation/linking and disposal are not used in this sim. Models are created once. Views display DynamicProperties across models. The term "dispose" is forbidden via a lint rule.
[ ] Does a heap comparison using Chrome Developer Tools indicate a memory leak? (This process is
described here.) Test on a
version built using grunt --minify.mangle=false. Compare to testing results done by the responsible developer.
Results can be found in https://github.com/phetsims/projectile-data-lab/issues/24
[x] For each common-code component (sun, scenery-phet, vegas, …) that opaquely registers observers or listeners, is
there a call to that component’s dispose function, or is it obvious why it isn't necessary, or is there
documentation about why dispose isn't called? An example of why no call to dispose is needed is if the component
is used in a ScreenView that would never be removed from the scene graph. Note that it's also acceptable (and
encouraged!) to describe what needs to be disposed in implementation-notes.md.
[x] Are there leaks due to registering observers or listeners? The following guidelines should be followed unless
documentation (in-line or in implementation-notes.md) describes why following them is not necessary.
AXON: Property.link or lazyLink is accompanied by unlink.
AXON: Multilink.multilink is accompanied by unmultilink.
AXON: Creation of Multilink is accompanied by dispose.
AXON: Creation of DerivedProperty is accompanied by dispose.
AXON: Emitter.addListener is accompanied by removeListener.
AXON: ObservableArrayDef.element*Emitter.addListener is accompanied
by ObservableArrayDef.element*Emitter.removeListener
SCENERY: Node.addInputListener is accompanied by removeInputListener
TANDEM: Creation of an instrumented PhetioObject is accompanied by dispose.
[x] All classes that require a dispose function should have one. This should expose a public dispose function that
calls this.dispose{{CLASS_NAME}}(), where dispose{{CLASS_NAME}} is a private function declared in the
constructor. {{CLASS_NAME}} should exactly match the class name.
[x] All classes that do not properly override dispose should either (a) use isDisposable: false, or (b) implement
a dispose method that calls Disposable.assertNotDisposable. Use (a) for classes that inherit a dispose method
from Disposable. Use (b) for classes that inherit a dispose method from something other than Disposable. The goal
here is to prevent clients from calling dispose for something that does not properly clean itself up, creating a
memory leak. This is especially important for common code, but is good defensive programming for sim-specific code.
Performance
[x] Play with sim, identify any obvious performance issues. Examples: animation that slows down with large numbers of
objects; animation that pauses or "hitches" during garbage collection.
[x] If the sim uses WebGL, does it have a fallback? Does the fallback perform reasonably well? (run with query
parameter webgl=false). UPDATE: WebGL is not used, but we use canvas for the projectiles and histograms.
Usability
[x] Are UI components sufficiently responsive? (especially continuous UI components, such as sliders)
[x] Do pointer areas overlap? (run with query parameter showPointerAreas) Overlap may be OK in some cases, depending on the z-ordering (if the front-most object is supposed to occlude pointer areas) and whether objects can be moved. See https://github.com/phetsims/projectile-data-lab/issues/187
Internationalization
[x] Does the sim behave correctly with dynamic layout, to support dynamic locale? Run with stringTest=dynamic and
use the left/right arrow keys.
[x] Are there any strings that are not internationalized, and does the sim layout gracefully handle internationalized
strings that are shorter than the English strings? (run with query parameter stringTest=X. You should see nothing
but 'X' strings.)
[x] Does the sim layout gracefully handle internationalized strings that are longer than the English strings? (run
with query parameters stringTest=double and stringTest=long)
[x] Does the sim stay on the sim page (doesn't redirect to an external page) when running with the query parameter
stringTest=xss? This test passes if sim does not redirect, OK if sim crashes or fails to fully start. Only test on
one desktop platform. For PhET-iO sims, additionally test ?stringTest=xss in Studio to make sure i18n strings didn't
leak to phetioDocumentation, see https://github.com/phetsims/phet-io/issues/1377
[x] Avoid using concatenation to create strings that will be visible in the user interface. Use StringUtils.fillIn
and a string pattern to ensure that strings are properly localized. This is relevant in cases where order should be
translatable.
[x] Use named placeholders (e.g. "{{value}} {{units}}") instead of numbered placeholders (e.g. "{0} {1}").
[x] #191
to string key conventions. String
keys are difficult to change after a sim has been published, and they appear in the PhET-iO API (and Studio) as the
phetioIDs for StringProperties.
[x] If the sim was already released, make sure none of the original string keys have changed. If they have changed,
make sure any changes have a good reason and have been discussed with @jbphet (it is likely that an issue
like https://github.com/phetsims/gravity-force-lab/issues/166 should be created).
Repository Structure
[x] The repository name should correspond to the sim title. For example, if the sim title is "Wave Interference", then
the repository name should be "wave-interference".
[x] Are all required files and directories present? For a sim repository named “my-repo”, the general structure should
look like this (where assets/, images/, mipmaps/ or sounds/ may be omitted if the sim doesn’t have those types of
resource files).
*Any images used in model.md or implementation-notes.md should be added here. Images specific to aiding with
documentation do not need their own license.
[x] Verify that the same image file is not present in both images/ and mipmaps/. If you need a mipmap, use it for all
occurrences of the image.
[x] Is the js/ directory properly structured? All JavaScript source should be in the js/ directory. There should be a
subdirectory for each screen (this also applies for single-screen sims, where the subdirectory matches the repo name).
For a multi-screen sim, code shared by 2 or more screens should be in a js/common/ subdirectory. Model and view code
should be in model/ and view/ subdirectories for each screen and common/. For example, for a sim with screens
“Introduction” and “Lab”, the general directory structure should look like this:
[x] Do filenames use an appropriate prefix? Some filenames may be prefixed with the repository name,
e.g. MolarityConstants.js in molarity. If the repository name is long, the developer may choose to abbreviate the
repository name, e.g. EEConstants.js in expression-exchange. If the abbreviation is already used by another
repository, then the full name must be used. For example, if the "EE" abbreviation is already used by
expression-exchange, then it should not be used in equality-explorer. Whichever convention is used, it should be used
consistently within a repository - don't mix abbreviations and full names. The abbreviation should be all uppercase
letters; e.g. MOTHAConstants, not MotHAConstants for "Model of the Hydrogen Atom".
[x] #194
1:1 correspondence between asset and resource files; for example, several related images may be in the same .ai file.
Check license.json for possible documentation of why some resources might not have a corresponding asset file.
[x] For simulations, was the README.md generated by grunt published-README or grunt unpublished-README? Common
code repos can have custom README files.
[x] Is the LICENSE file correct? (Generally GPL v3 for sims and MIT for common code,
see this thread for additional information).
[x] Does .gitignore match the one in simula-rasa?
[x] In GitHub, verify that all non-release branches have an associated issue that describes their purpose.
[x] Are there any GitHub branches that are no longer needed and should be deleted?
[x] Sim-specific query parameters (if any) should be identified and documented in one .js file in js/common/ or js/ (
if there is no common/). The .js file should be named {{PREFIX}}QueryParameters.js, for example
ArithmeticQueryParameters.js for the arithmetic repository, or FBQueryParameters.js for Function Builder (where
the FB prefix is used).
[x] Query parameters that are public-facing should be identified using public: true in the schema.
[x] All sims should use a color file named MyRepoColors.ts or, if using abbreviations, MRColors.ts, and
use ProfileColorProperty where appropriate, even if they have a single (default) profile (to support color editing
and PhET-iO Studio). The ColorProfile pattern was converted to *Colors.ts files in
https://github.com/phetsims/scenery-phet/issues/515. Please see
GasPropertiesColors.ts
for a good example.
[x] #190
Properties in {{PREFIX}}Preferences.ts, for example KeplersLawsPreferences.ts. The initial value of each such preferences Property should be set via a query parameter from {{PREFIX}}QueryParameters.js.
[x] Does package.json refer to any dependencies that are not used by the sim?
[x] Does package.json include any config that was only needed for development? For example:
Lint rules turned off or made more graceful
Certain testing or simFeatures turned off with flags
Coding Conventions
[x] Are coding conventions outlined in
PhET's Coding Conventions document
followed and adhered to? This document deals with PhET coding conventions. You do not need to exhaustively check every
item in this section, nor do you necessarily need to check these items one at a time. The goal is to determine whether
the code generally meets PhET standards.
TypeScript Conventions
[x] Are TypeScript conventions outlined in
PhET's TypeScript Conventions
document followed and adhered to?
Math Libraries
[x] DOT/Utils.toFixed or DOT/Utils.toFixedNumber should be used instead of toFixed. JavaScript's toFixed is
notoriously buggy. Behavior differs depending on browser, because the spec doesn't specify whether to round or floor.
IE11
[x] IE is no longer supported. With that in mind remove IE-specific workarounds
[x] Use string.includes and string.startsWith where possible.
Organization, Readability, and Maintainability
[x] Does the organization and structure of the code make sense? Do the model and view contain types that you would
expect (or guess!) by looking at the sim? Do the names of things correspond to the names that you see in the user
interface?
[x] Are appropriate design patterns used?
See phet-software-design-patterns.md.
If new or inappropriate patterns are identified, create an issue.
[x] Is inheritance used where appropriate? Does the type hierarchy make sense?
[x] Is there any unnecessary coupling? (e.g., by passing large objects to constructors, or exposing unnecessary
properties/functions). If you only need a few fields from a large object, pass them in as separate parameters. The
threshold for the number of parameters is up to you - use your judgement. Alternatively in TypeScript, you can
decouple by narrowing the API using Pick, but this is a bit of a hack. Here's an example:
public constructor( tickMarksVisibleProperty: Property<boolean>,
model: Pick<IntroModel, 'changeWaterLevel'>, // <-- Note the call site can pass the whole model, but we declare we will only use this part of it
waterCup: WaterCup, modelViewTransform: ModelViewTransform2,
providedOptions?: WaterCup3DNodeOptions ) {
[x] Is there too much unnecessary decoupling? (e.g. by passing all of the properties of an object independently
instead of passing the object itself)? UPDATE: See for instance HistogramNode.ts
[x] Are the source files reasonable in size? Scrutinize large files with too many responsibilities - can
responsibilities be broken into smaller delegates? To see file sizes for TypeScript sims, run this shell command:
[x] Are any significant chunks of code duplicated? In addition to manual identification, tools include: WebStorm
Code > Analyze Code > Locate Duplicates and https://github.com/danielstjules/jsinspect. UPDATE: There are a few "cost 26" things at the worst. This amounts to about 2-3 lines of code, and does not seem worrisome.
[x] Is there anything that should be generalized and migrated to common code?
[x] Are there any TODO or FIXME or REVIEW comments in the code? They should be addressed or promoted to GitHub
issues.
This means that your repo should have the "todo-should-have-repo" lint rule enabled.
[x] Are there any magic numbers that should be factored
out as constants and documented?
[x] Are there any constants that are duplicated in multiple files that should be factored out into
a {{REPO}}Constants.js file?
[x] Does the implementation rely on any specific constant values that are likely to change in the future? Identify
constants that might be changed in the future. (Use your judgement about which constants are likely candidates.) Does
changing the values of these constants break the sim? For example,
see https://github.com/phetsims/plinko-probability/issues/84.
[x] Is PhetColorScheme used where
appropriate? Verify that the sim is not inventing/creating its own colors for things that have been standardized
in PhetColorScheme. Identify any colors that might be worth adding to PhetColorScheme.
[x] Are all dependent Properties modeled as DerivedProperty instead of Property?
[x] All dynamics should be called from Sim.step(dt), do not use window.setTimeout or window.setInterval. This will
help support Legends of Learning and PhET-iO.
Accessibility
This section may be omitted if the sim has not been instrumented with accessibility features. Accessibility includes
various features, not all are always include. Ignore sections that do not apply.
General
[x] Are accessibility features integrated well into the code? They should be added in a maintainable way, even if that
requires upfront refactoring.
Alternative Input
[x] Does the sim pass an accessibility fuzz test? (run with query parameters fuzzBoard&ea)
[x] Does the sim use ScreenView.pdomPlayAreaNode.pdomOrder and Screenview.pdomControlAreaNode.pdomOrder to control
the traversal order and categorize Nodes in the PDOM? See alternative-input-quickstart-guide.md for more information. This is being completed in https://github.com/phetsims/projectile-data-lab/issues/107
This section may be omitted if the sim has not been instrumented for PhET-iO, but is likely good to glance at no matter.
[x] Does instrumentation follow the conventions described
in PhET-iO Instrumentation Guide?
This could be an extensive bullet. At the very least, be sure to know what amount of instrumentation this sim
supports. Describing this further goes beyond the scope of this document.
[x] PhET-iO instantiates different objects and wires up listeners that are not present in the PhET-branded simulation.
It needs to be tested separately for memory leaks. To help isolate the nature of the memory leak, this test should be
run separately from the PhET brand memory leak test. Test with a colorized Data Stream, and Studio (easily accessed
from phetmarks). Compare to testing results done by the responsible developer and previous releases.
[x] Make sure unused PhetioObject instances are disposed, which unregisters their tandems.
[x] Make sure JOIST dt values are used instead of Date.now() or other Date functions. Perhaps try
phet.joist.elapsedTime. Though this has already been mentioned, it is necessary for reproducible playback via input
events and deserves a comment in this PhET-iO section.
[x] Are random numbers using DOT/dotRandom as an imported module (not a global), and all doing so after modules are
declared (non-statically)? For example, the following methods (and perhaps others) should not be
used: Math.random, _.shuffle, _.sample, _.random. This also deserves re-iteration due to its effect on
record/playback for PhET-iO.
[x] Like JSON, keys for undefined values are omitted when serializing objects across frames. Consider this when
determining whether toStateObject should use null or undefined values.
[x] PhET prefers to use the term "position" to refer to the physical (x,y) position of objects. This applies to both
brands, but is more important for the PhET-iO API. See https://github.com/phetsims/phet-info/issues/126
[x] Are your IOType state methods violating the API of the core type by accessing private fields?
[x] When defining a boolean Property to indicate whether something is enabled with a tandem name of enabledProperty,
use AXON/EnabledProperty. This should be done in both the model and the view. If you're using a DerivedProperty,
skip this item.
[x] Do not use translated strings in phetioDocumentaton - it changes the PhET-iO API!
To begin a code review, the responsible developer should:
dev:code-review
.strikethrough) checklist items and sections that are not relevant.PhET Code-Review Checklist (a.k.a "CRC")
// REVIEW
comments in the codeSpecific Instructions
interactiveDescrption: true
in order to support keyboard navigation (which this simulation does support).includePlayPauseResetButtons
andotherControls
.)GitHub Issues
The following standard GitHub issues should exist. If these issues are missing, or have not been completed, pause code review until the issues have been created and addressed by the responsible dev.
brands=phet
, see https://github.com/phetsims/projectile-data-lab/issues/24brands=phet-io
(if the sim is instrumented for PhET-iO), see https://github.com/phetsims/projectile-data-lab/issues/24Build and Run Checks
If any of these items fail, pause code review.
ea
)fuzz&ea
)ea&listenerOrder=random
andea&listenerOrder=random&fuzz
)?deprecationWarnings
. Do not use deprecated methods in new code.Memory Leaks
Please note that dynamic allocation/linking and disposal are not used in this sim. Models are created once. Views display DynamicProperties across models. The term "dispose" is forbidden via a lint rule.
grunt --minify.mangle=false
. Compare to testing results done by the responsible developer. Results can be found in https://github.com/phetsims/projectile-data-lab/issues/24dispose
function, or is it obvious why it isn't necessary, or is there documentation about whydispose
isn't called? An example of why no call todispose
is needed is if the component is used in aScreenView
that would never be removed from the scene graph. Note that it's also acceptable (and encouraged!) to describe what needs to be disposed in implementation-notes.md.Property.link
orlazyLink
is accompanied byunlink
.Multilink.multilink
is accompanied byunmultilink
.Multilink
is accompanied bydispose
.DerivedProperty
is accompanied bydispose
.Emitter.addListener
is accompanied byremoveListener
.ObservableArrayDef.element*Emitter.addListener
is accompanied byObservableArrayDef.element*Emitter.removeListener
Node.addInputListener
is accompanied byremoveInputListener
PhetioObject
is accompanied bydispose
.dispose
function should have one. This should expose a publicdispose
function that callsthis.dispose{{CLASS_NAME}}()
, wheredispose{{CLASS_NAME}}
is a private function declared in the constructor.{{CLASS_NAME}}
should exactly match the class name.dispose
should either (a) useisDisposable: false
, or (b) implement adispose
method that callsDisposable.assertNotDisposable
. Use (a) for classes that inherit adispose
method from Disposable. Use (b) for classes that inherit adispose
method from something other than Disposable. The goal here is to prevent clients from callingdispose
for something that does not properly clean itself up, creating a memory leak. This is especially important for common code, but is good defensive programming for sim-specific code.Performance
webgl=false
). UPDATE: WebGL is not used, but we use canvas for the projectiles and histograms.Usability
showPointerAreas
). See https://github.com/phetsims/projectile-data-lab/issues/187showPointerAreas
) Overlap may be OK in some cases, depending on the z-ordering (if the front-most object is supposed to occlude pointer areas) and whether objects can be moved. See https://github.com/phetsims/projectile-data-lab/issues/187Internationalization
stringTest=dynamic
and use the left/right arrow keys.stringTest=X
. You should see nothing but 'X' strings.)stringTest=double
andstringTest=long
)stringTest=xss
? This test passes if sim does not redirect, OK if sim crashes or fails to fully start. Only test on one desktop platform. For PhET-iO sims, additionally test?stringTest=xss
in Studio to make sure i18n strings didn't leak to phetioDocumentation, see https://github.com/phetsims/phet-io/issues/1377StringUtils.fillIn
and a string pattern to ensure that strings are properly localized. This is relevant in cases where order should be translatable."{{value}} {{units}}"
) instead of numbered placeholders (e.g."{0} {1}"
).Repository Structure
[x] The repository name should correspond to the sim title. For example, if the sim title is "Wave Interference", then the repository name should be "wave-interference".
[x] Are all required files and directories present? For a sim repository named “my-repo”, the general structure should look like this (where assets/, images/, mipmaps/ or sounds/ may be omitted if the sim doesn’t have those types of resource files).
*Any images used in model.md or implementation-notes.md should be added here. Images specific to aiding with documentation do not need their own license.
[x] Verify that the same image file is not present in both images/ and mipmaps/. If you need a mipmap, use it for all occurrences of the image.
[x] Is the js/ directory properly structured? All JavaScript source should be in the js/ directory. There should be a subdirectory for each screen (this also applies for single-screen sims, where the subdirectory matches the repo name). For a multi-screen sim, code shared by 2 or more screens should be in a js/common/ subdirectory. Model and view code should be in model/ and view/ subdirectories for each screen and common/. For example, for a sim with screens “Introduction” and “Lab”, the general directory structure should look like this:
[x] Do filenames use an appropriate prefix? Some filenames may be prefixed with the repository name, e.g.
MolarityConstants.js
in molarity. If the repository name is long, the developer may choose to abbreviate the repository name, e.g.EEConstants.js
in expression-exchange. If the abbreviation is already used by another repository, then the full name must be used. For example, if the "EE" abbreviation is already used by expression-exchange, then it should not be used in equality-explorer. Whichever convention is used, it should be used consistently within a repository - don't mix abbreviations and full names. The abbreviation should be all uppercase letters; e.g. MOTHAConstants, not MotHAConstants for "Model of the Hydrogen Atom".[x] #194 1:1 correspondence between asset and resource files; for example, several related images may be in the same .ai file. Check license.json for possible documentation of why some resources might not have a corresponding asset file.
[x] For simulations, was the README.md generated by
grunt published-README
orgrunt unpublished-README
? Common code repos can have custom README files.[x] Is the LICENSE file correct? (Generally GPL v3 for sims and MIT for common code, see this thread for additional information).
[x] Does .gitignore match the one in simula-rasa?
[x] In GitHub, verify that all non-release branches have an associated issue that describes their purpose.
[x] Are there any GitHub branches that are no longer needed and should be deleted?
[x] Sim-specific query parameters (if any) should be identified and documented in one .js file in js/common/ or js/ ( if there is no common/). The .js file should be named
{{PREFIX}}QueryParameters.js
, for example ArithmeticQueryParameters.js for the arithmetic repository, or FBQueryParameters.js for Function Builder (where theFB
prefix is used).[x] Query parameters that are public-facing should be identified using
public: true
in the schema.[x] All sims should use a color file named
MyRepoColors.ts
or, if using abbreviations,MRColors.ts
, and useProfileColorProperty
where appropriate, even if they have a single (default) profile (to support color editing and PhET-iO Studio). TheColorProfile
pattern was converted to*Colors.ts
files in https://github.com/phetsims/scenery-phet/issues/515. Please see GasPropertiesColors.ts for a good example.[x] #190 Properties in
{{PREFIX}}Preferences.ts
, for example KeplersLawsPreferences.ts. The initial value of each such preferences Property should be set via a query parameter from{{PREFIX}}QueryParameters.js
.[x] Does
package.json
refer to any dependencies that are not used by the sim?[x] Does
package.json
include any config that was only needed for development? For example:Coding Conventions
TypeScript Conventions
Math Libraries
DOT/Utils.toFixed
orDOT/Utils.toFixedNumber
should be used instead oftoFixed
. JavaScript'stoFixed
is notoriously buggy. Behavior differs depending on browser, because the spec doesn't specify whether to round or floor.IE11
string.includes
andstring.startsWith
where possible.Organization, Readability, and Maintainability
Pick
, but this is a bit of a hack. Here's an example:TODO
orFIXME
orREVIEW
comments in the code? They should be addressed or promoted to GitHub issues."todo-should-have-repo"
lint rule enabled.{{REPO}}Constants.js
file?PhetColorScheme
. Identify any colors that might be worth adding toPhetColorScheme
.DerivedProperty
instead ofProperty
?Accessibility
This section may be omitted if the sim has not been instrumented with accessibility features. Accessibility includes various features, not all are always include. Ignore sections that do not apply.
General
Alternative Input
fuzzBoard&ea
)ScreenView.pdomPlayAreaNode.pdomOrder
andScreenview.pdomControlAreaNode.pdomOrder
to control the traversal order and categorize Nodes in the PDOM? See alternative-input-quickstart-guide.md for more information. This is being completed in https://github.com/phetsims/projectile-data-lab/issues/107PhET-iO
This section may be omitted if the sim has not been instrumented for PhET-iO, but is likely good to glance at no matter.
PhetioObject
instances are disposed, which unregisters their tandems.dt
values are used instead ofDate.now()
or other Date functions. Perhaps tryphet.joist.elapsedTime
. Though this has already been mentioned, it is necessary for reproducible playback via input events and deserves a comment in this PhET-iO section.DOT/dotRandom
as an imported module (not a global), and all doing so after modules are declared (non-statically)? For example, the following methods (and perhaps others) should not be used:Math.random
,_.shuffle
,_.sample
,_.random
. This also deserves re-iteration due to its effect on record/playback for PhET-iO.undefined
values are omitted when serializing objects across frames. Consider this when determining whethertoStateObject
should usenull
orundefined
values.enabledProperty
, useAXON/EnabledProperty
. This should be done in both the model and the view. If you're using a DerivedProperty, skip this item.phetioDocumentaton
- it changes the PhET-iO API!