Make the interactive widget properly store state between re-renders

Not sure if it was brought up already on other occasions but currently, the interactive table widget does not remember its state when it gets re-rendered (scroll position vertical/horizontal), selected page, etc…

When it is used for record selection purposes this can quickly become a daunting limitation for the operators if they constantly have to manually find their way back to the “old state” prior to a re-render.

Concrete example: An operator needs to cycle through a couple of records to check state and this state check requires a more elaborate trigger change to run which is “outsourced” onto a dedicated step for visual feedback and modularity. In this case the operator selects a record, is then sent to the processing step, the processing step cycles through the trigger chain and transitions back to the original screen. When there, the original state of the widget is lost, while the placeholder record may still be populated… but it is now berried in “some page”…

Thank you.

Instead of burying the triggers on a separate step, couldn’t you place it on a custom widget instead and activate when operator selects a row? I mean to avoid the step change?

I am suggesting this even though we avoid using custom widgets to stick to the standard set of functionalities and avoid custom code on the platform.

It was just an example. But there can be other cases where it would be very beneficial to have the state in memory rather than a re-render. At least as long as there has not been a dedicated app completion. And yes, I would not like to have to introduce a custom widget for something like this.

1 Like