Disabling table select

How do you disable selecting a row from table ? I am performing image annotation and have a timer component. I want to be able to disable all the rows till all the queries are completed?

basically, how do you make sure that all the queries are completed before the user moves to the next image?

Hi @nsriniva ,

Currently there is no way to disable selecting a row from a table. However, you can disable further actions (and perhaps displaying other components) by hiding components and/or disabling actions based on the {{ myQuery.isFetching }} property.

Let's say that you're annotating an image and on form submit you trigger myQuery. While myQuery.isFetching is true, we disable button clicks so that the user cannot modify data until myQuery completes.

Let me know if that helps, or if you have a more specific use case!

Grace

@nsriniva tagging you here! Welcome to Retool Community!

Thanks for you response, Grace.

Let's say that you're annotating an image and on form submit you trigger myQuery . While myQuery.isFetching is true , we disable button clicks so that the user cannot modify data until myQuery completes. - I followed the image tag tutorial on the website and the when the user hits submit there is always a possibility of moving to the next Image by selecting the next row in the table and this may modify the data.

Is there a way to make the all the components inactive till the query is done?




Hi @nsriniva,

Thanks for the fast followup here!

> there is always a possibility of moving to the next Image by selecting the next row in the table and this may modify the data.I have a few follow-up questions here to make sure I understand fully!

  • Does selection modify the data on load?
  • Could you submit a quick screenshot so I can understand the application more holistically?
  • One idea I have is to hide all modification components (e.g. forms, buttons) on myQuery.isFetching if merely disabling submit doesn't work.
    Let me know!

    Grace


What the tool does,

  1. A user is selected and this initiates a query to load the table.
  2. The table gets populated with the image path information and other required information.
  3. Next, the user selects a row from the table and the image appears in the bounding box component. Simultaneously, the timer starts.
  4. Once the user has finished annotating the image, he/she hits the save button. The save button initiates a bunch of queries, one being collecting the timer value in milliseconds.
  5. The user selects next row to move to the next Image .

The problem arises between steps 4 and 5. When the user hits the save button and initiates a series of queries, they can click the next row in the table and the timer get reset and started again before its previous value is saved. Hopefully that make sense.

My idea was to disable everything till the queries initiated by the save button are completed.

-Nisha

Got you - that makes sense. In that case, could you perhaps capture the value of the timer earlier on in the Save query?

Let's say that your Save query fires off the following events (I made up a few function names for illustration purposes).

const onSave = async () => {
await updateDatabaseWithData({ component.data });
await appendActionToMongoDB({ ...component.data, ...annotation.data });
await updateTimer();
}

My guess is that updateTimer looks something like this:

const updateTimer = async () => {
const time = timer.value;
await doSomethingWithTime();
}

Which is pulling the value from the Timer component at runtime, which - like you said - might be refreshed by the time it's run.

You could instead capture the timer value as the first step, then pass that into your version of the function updateTimer.

const onSave = async () => {
const currentTime = timer.time;
await updateDatabaseWithData({ component.data });
await appendActionToMongoDB({ ...component.data, ...annotation.data });
await updateTimer(currentTime);
}

That should resolve any data inconsistencies and actually be a more smooth user experience (data is correctly updated in the background without freezing the user experience).

If you aren't using a JS Query to manage the asynchronous calls, this might be a good application, because you want to control the sequencing of actions being performed.

Let me know if this approach works for you!

Grace