-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Develop Next-Gen Query Machine #51
Comments
Here are the main concerns to balance with query strings (let me know if I missed any!)
Our implementation should be based on URLSearchParams which did not exist when we wrote QueryStringMachine. For PhET-iO, query strings should be tied to an instrumented axon Property and we should process query strings after initialization. Like this: Index: js/model/Circuit.ts
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/js/model/Circuit.ts b/js/model/Circuit.ts
--- a/js/model/Circuit.ts (revision 29bd2ffb38659638191ccabaac725ff9758ac6f9)
+++ b/js/model/Circuit.ts (date 1668110848420)
@@ -184,10 +184,16 @@
// When the current type changes, mark everything as dirty and relayout charges
this.currentTypeProperty.lazyLink( () => this.relayoutAllCharges() );
- this.showCurrentProperty = new BooleanProperty( CCKCQueryParameters.showCurrent, {
+ this.showCurrentProperty = new BooleanProperty( false, {
tandem: tandem.parentTandem!.createTandem( 'showCurrentProperty' )
} );
+ onQueryString<boolean>( 'showCurrent', current => {
+ this.showCurrentProperty.value = current;
+ } );
+
+ onQueryString<boolean>( 'showCurrent', this.showCurrentProperty );
+
this.timeProperty = new NumberProperty( 0 );
this.chargeAnimator = new ChargeAnimator( this );
Will we allow query parameters that are not phet-io-compatible, that you can use the value of sequentially during initialization? Temporarily self-assigning while I consider features and ideas for this. |
After some limited discussion with @samreid, it seems like giant part of his patch above hinges on thinking that PhET-iO standard wrapper customization is ideal the way it is (setting state after the sim starts up). If we are trying to overhaul our query parameter system, let's make sure we NEED to support that before we base the whole query parameter system on that. What if instead we had a way to apply phet-io state inline on startup, and query parameters were part of that code path too. |
Define needs for query machine
Related too...
#43
The text was updated successfully, but these errors were encountered: