When you click the x to close a model, the Close
event fires.
If you have a Close button on the modal that calls .close()
method, the event does not fire.
When you click the x to close a model, the Close
event fires.
If you have a Close button on the modal that calls .close()
method, the event does not fire.
I think the problem is that when trying to control a component that the button itself is within, it cannot give that option?
If the button was outside of the modal, it should work.
Not my modal is button6, but it isn't listed - and "close" may be reserved in Retool
Hmmm. looks like from your example you cannot create a click event for the button you just clicked. This would create an infinite loop so I can see why they denied this. Looking further, it looks like all self referential Control Component event handlers are denied.
In my case I am using a button to control a modal which works and I do it all the time. It is just that the close
event does not fire after the modal is successfully closed and there should be no negative repercussions from doing so.
This category of behavior is also generally true for other JS API methods like .setValue(), .clear(), etc. Event handlers are typically only triggered by direct user input.
Though Scott for your example, you should be able to control parent components from child components like that:
Sorry, I have to take issue with how that works!
An event should fire in all applicable cases or else your code is less deterministic, therefore you need to do extra work and it get less DRY.
In my relatively simple case, I need to have the same code in both the modal close handler and the button click handler to do the same thing.
It is true that sometimes you do not want to fire the change event if you are setting the value in code, and you have to do a little extra work to prevent it. But at least you have more predictable behavior.
I seem to recall some toolkits/frameworks I have used in the past have a flag you can pass in their equivalent setValue() method to prevent the change event from firing. That would be the best option in my opinion.
The primary reason that the JS API methods and input value updates don't trigger event handlers today is that it preserved the previous behavior before the launch of event handlers and facilitated a safer migration to the new feature set.
I agree it is better for dry code and is easier to understand, and expect there to be a point in the future where components all have separate 'User input" and "Value change" events that can be fired. For the option of adding a flag on JS API methods, it would likely need to be implemented as a default of not triggering otherwise. I've talked with a few users about this behavior and will resurface it internally when we are next able to do a pass over the general event handler system.
I'll move this thread over to a feature request to help track the general discussion on the topic
Ahh, I see. Retool is getting old enough now to start accumulating technical debt. Congrats!
As to the bubble flag being default false, my thoughts exactly.
I have not tested this yet, but the April 18th change log lists this as a fix/improvement:
This addresses my specific issue with modals. Not sure if other methods like setValue()
and clear()
are still not triggering the appropriate events.
The specific fix for modals was to add this forward compatible option as a setting inside of the event handler config:
This has not yet been added to value change events like on a textInput, but would likely look similar there. Will leave this feature request open as a general request
is this on a roadmap or something?