Create CorrespondingViewIO? Or Maybe GroupMemeberIO?

[zepumph]

from phetsims/charges-and-fields#170, we had for a time ModelElementNodeIO (https://github.com/phetsims/charges-and-fields/blob/b7f5214eb6091e7da3af26fe0748939e1229ec52/js/charges-and-fields/view/ModelElementNodeIO.js), This held a reference to the model element, though it wasn't used by anything, and there was no reason to have it in state for supporting state.

In that file, there was a modelPhetioID. If we feel like this is valuable, then perhaps we can change the ReferenceIOs in CAF to use this new type. If we don't think that this level of granularity for the view-specific IO type is needed, then maybe just a GroupMemberIO. Something more specific than ReferenceIO, which really doesn't belong here, it just happened to work. Note that ObjectIO doesn't work because these types can't be structured cloned with PostMessage.

@samreid what do you think we should do. Create CorrespondingViewIO? Create GroupMemberIO? Keep ReferenceIO? Wild Card?

[samreid]

I don't see the advantage of developing something like ReferenceIO but with a modelPhetioID, but I don't really understand the role of ReferenceIO in charges and fields. For instance, ElectricFieldSensorNode has phetioType: ReferenceIO. Should we instead have put phetioState: false and used phetioType: NodeIO which is the default for that type?

Also, I'm unclear how the introduction PhetioGroup may help or clarify things for this case.

@zepumph can you please re-evaluate this issue now that we're further along?

[zepumph]

Yes I agree. I don't think that this common IO type makes sense to create. I don't think that it adequately fits into how we are using the upside-down "U" strategy for implement dynamic state. I'm going to close.