"Keep variable references inside the query in sync with your app" query option questions

Queries and Resources
1

So I just ran across the "Keep variable references inside the query in sync with your app" option in the Advanced section of a JS query. I saw it in this post: Remove specific index element from listView - #18 by doris.l

This is not in the docs. Does setting this value solve the problem mentioned in this post, When to use Temporary State vs. local variables, or just after the query executes?

Is there a use case not not having this enabled? Should it just be the default for all queries or does it cause other downstream or performance issue so should only on enabled if needed?

1 Like
2

Hi @bradlymathews! tempState.setValue() still returns a promise, but, with "Keep variable references inside the query in sync with your app" set to true you can await this promise and then reference the updated value in the same query with tempState.value. Note that this is also the case when using, for instance, checkbox.setValue().

I can imagine wanting to set this as a default, however, changing default behavior when current users are possibly expecting/building around the current behavior is tricky. As for performance issues - the bottleneck will likely won't be having the option checked but rather using await a lot in a query.

3

@Kabirdas,

Sounds promising :rofl:

So what would the syntax be, this?

let throwAwayVar = await tempState.setValue("Hello World!");
console.log(tempState.value) // Hello World!
4

Yep! You don't actually need throwAwayVar though you can just do

await tempState.setValue("Hello World!");
console.log(tempState.value); // Hello World!

Edit: thanks for the pun :joy:

1 Like
5

This doesn't seems like working when you import the app as module and run from parent app. Is it by design or a bug?

6

@harekamsingh that is certainly a bug! Thanks for surfacing the behavior, I've brought it to the attention of our dev team and we'll let you know here when it's fixed :slightly_smiling_face: In the meantime, do you have a workaround for the specific case you're using this in or can we help you think of one?

7

The workaround I found is to call getValue from another javascript file.

1 Like
8

Hey @bradlymathews!

Just want to follow up on your question about having "Keep variable references inside the query in sync with your app" turned on by default. It turns out the setting does come with a performance hit for the JS queries that use it.

Thanks for resurfacing the issue! It was something I was not aware of.

1 Like
9

This doesn't wait for setValue to complete. The console prints the initial state only. Can you double-check if this works now?

Note: The "Keep variable reference inside the query in sync with app" is available only for JS query. What if I set the state through the Success event of a REST API?

10

Hey @dhivya_sabapathy!

Just to be sure, are you seeing the incorrect value get logged from the script or are you also seeing that behavior in a JS query?

If you're looking to use that functionality in particular you might want to try using a JS query as your success handler instead. Is there a particular reason you went for one over the other?

11

Let me explain my use case to give you more context.

  1. I have a JS query which triggers an API query. The success handler of the API query sets the value of the temporary state. I am calling the API query using await query_name.trigger() and have a conditional logic in the JS query based on the value of the temp_state. Hope this gives you a better idea of the scenario.
12

Ah! That makes sense, thanks for that context!

I don't know that there's a way to wait for a success handler from the JS query that's triggering the API query. You'll likely need to set the value of the temp state in the JS query itself instead of setting it with a handler.

For instance, you might do something like

const apiData = await apiQuery.trigger();
await tempState.setValue(apiData);
/* ... rest of your logic here */

You can also add some error handling logic between your call to the API query and when you set the temp state if need be.

Does that look like it could work?

1 Like
13

I will second @Kabirdas' solutions.

I have discovered that are triggering a query with JS and then letting that query do anything on its own Success or Failure event is an anti-pattern. Handle it all within the JS query.

For instance it is typical to retrigger the Select Query after an Update query to refresh a table's source. If I am triggering an update query within JS (for instance if I need to pass additionalScope) I also then trigger the Select query right after.

2 Likes
14

Thanks a lot @Kabirdas for your support! Worked like a charm. :+1: :pray: Looks like the 'Run script' in success handler is less reliable since we don't know the sequence of operations happening when the query is triggered and the event handler execution.