Allow event handlers to refer to the component self

[Roland_Alden]

Here is a use-case that is not possible presently.

1. A textinput component has a clear button.
2. There is no event for "the clear button was clicked"
3. Having clicked clear we would like to set the focus inside the component because our next move is to do a paste.
4. We could carefully select all text and then do paste but that isn't 100% easy. That's why we like the clear button.
5. Even if there were an event handler for clear we cannot do a set focus on ourselves because the self component is never on the list of components an event handler can address.

Suggestion. Allow event handlers that target self.

Allow their order to be arranged in the IDE and run them synchronously in that order.

Keep the async semantics of events that target something other than self. BUT, if they are positioned ahead of events targeting self, trigger them first. If they are positioned after events targeting self wait until the list of synchronous self targeting events is finished before triggering them.

[victoria]

Hey @Roland_Alden!

I thiiiink we can find a solution here.

Try this event handler and see if it works for you:

I'm running a Change event handler that only runs when the textInput1.value becomes empty, and it runs the .focus() method.
Screen Recording 2023-03-07 at 3.51.48 PM.mov

[Roland_Alden]

Thank you! That works. Here is what I did. Any reason using self is not the better idea?

[Roland_Alden]

It would be really nice to be able to copy an Event Handler and paste it into the Event Handler list of a different component. In that case having the code be as portable from one context to another would be helpful so tricks like using "self" instead of hard coding names is always a good idea.

[victoria]

Glad that works and self works great! No reason to not use self here

And definitely. Created a feature request for copyable/reusable event handlers!

[victoria]

Hey again Roland! The eng team working on this ticket wants to dig into your use case a bit more What are you trying to accomplish here, specifically in relation to the reusable event handlers? What app are you building and how do the reusable event handlers help? What kind of code do you find yourself reusing? Anything you can share would be very helpful!

[Roland_Alden]

So there seem to be (keep in mind I am hardly a Retool expert at this point) two patterns for event handlers:

1. They are very specific business logic carefully crafted in the application context and attached to some Retool object where they trigger or catch a trigger and implement a unique transaction.
2. They are just boilerplate code doing something totally generic. The example of setting the focus after clearing an input field is one such example.

In case #1 the chances of the code being replicated elsewhere is very low. In the case of #2 the chances of the code being replicated is nearly 100%.

There is another pattern which is a combination of both ideas. This is where you want to offer some control or feature in more places than one throughout a complex UI. The user sees the “same” component in the same place across many UI “screens”. I realize the best solution for this case is probably to arrange the UI design such that what the user sees is in reality the same component. But I am not that advanced in Retool so I find myself copying a button, for example, and wanting the user to get the same result no matter which copy they interact with. In such a case the event handlers are an integral part of the copy, as are the data sources, the tooltips, the show/hide logic, etc. All that is copied when the button is copied and sometimes it needs to be slightly tweaked. For example copy A may connect to a different data source than copy B but to the user A and B “do the same thing”.

In this example the event handlers need to be copied too and it is best if their code 1) doesn’t have to be touched, 2) does the same thing in the context of the copy that it did in the original. I’ll give you an example:

Sometimes I will calculate something (complicated) and stick it in the Alt text field. Then elsewhere I can reference it using self.altText. If I copy such a component I may have to adjust the definition of the Alt text field but I don’t have to find and fix all the self.altText references.

Now this is an inappropriate misuse of altText which is there for accessibility purposes so a better solution would be for Retool to all such “local state” to be defined in an ad hoc way.

Probably “user defined components” is a (better) way for me to do such things but I haven’t got that far in my learning and to some degree it’s NOT a better way because I am not really looking for a component that is different than the ones Retool already provides. I am just looking for a better way to customize multiple instances of Retool standard components.

[victoria]

Thank you so much for such a thorough response, Roland! Just passed it along to the eng team working on this.

[SaidQuintero]

Hey @victoria !

Just checking in if there is any update on this feature request.

Assigning a click event target to the same component would be practical to create a better filtering experience in tables. I am currently displaying the data from this particular column in Tags, It would be helpful to make the cell clickable so the table can apply a filter with that tag.

[joeBumbaca]

Hey @SaidQuintero! We don't have any events that allow you to select the original component to control. But this is possible with the same functionality as described above.

Set a 'Click cell' event handler on the table, and have a script run:

Use the setFilterstack method on the table to update the filters with the value of the selected cell.

Before click:

After cell selection (with script code):

This a pretty simple example that sets one filter at a time, but you can expand the script to adjust as necessary for your se case.