Ordering of state setting and deserialization

[jonathanolson]

I successfully have serialization of WOAS's string information (using the new Float64ArrayIO, and a custom WOASModelIO that serializes and deserializes that information).

However, when setting the state of a sim, this numeric data is set BEFORE other things (like our modeProperty) are set. When the modeProperty changes, it fully resets the state of the string (so that the state deserialization is ineffective, and the string is zero'ed out).

Is there any way we can have model.modeProperty set/deserialized BEFORE the model object itself?

I'm available to discuss more at any time, since the above isn't particularly clear.

[jonathanolson]

We have a solution (or workaround?) for this, by setting phetioState:false on our modeProperty, and then including it in the toStateObject/setValue in the model type (WOASModelIO). This allows us to explicitly control the order and deserialization in the setValue() method.

@samreid does this (and the above commit) sound acceptable, or is there a better way of handling this situation?

[jonathanolson]

We lose the state saving of the valid values, and so we now cannot control modeProperty in studio. That's less than ideal.

[samreid]

In Charges and Fields, we had to not clear the model if the state was being set by phet-io:

    /**
     * Function that clears the Equipotential Lines Observable Array
     * @public
     */
    clearElectricPotentialLines() {
      const isSettingState = _.hasIn( window, 'phet.phetIo.phetioEngine' ) && phet.phetIo.phetioEngine.phetioStateEngine.isSettingState;

      // Clear lines without disrupting phet-io state
      if ( !isSettingState ) {
        this.electricPotentialLineGroup.clear();
      }
    }

It sounds like that pattern may work here as well?

[jonathanolson]

Works well, thanks!