I removed the “block” in “reload-block-1a” because all three blocks are the dynamic beta blocks, but I tried it as written above and that didn’t work either. Do you have any ideas of what else I can look for/troubleshoot?
Thank you @matthieu_chateau for your feedback. It was indeed the capital letters in the block name that was causing it. The script now does what it is supposed to - executing an action button on one block causes the other to reload.
However, I get an error message out of corner pop-up:
The second list block that is supposed to reload has conditional visibility on it with the condition checking the value of the field that the first block’s action is updating. That’s the whole point of reloading the second block, so that it can pick up on the value updated by the first block’s action and, consequently, reveal or hide data.
So, there should not be an error reported. How would you recommend I should deal with it?
I have a similar requirement in a different page of my app - the page carrying the user profile update form. I need the page to reload after an update to the form because I have another block above the form with conditional visibility warning the user that all the fields need to be filled out for the app to work correctly. By default, the block’s conditional visibility does not kick in based on the update of the profile form - hence the need to reload the page.
I’ve tried the block above with the following modification, but it doesn’t work. I suspect it’s because it’s a different type of block. The block is called “user-accounts1”.
Softr team, I’ve been thinking there so much interest in the community to have blocks and pages updated based on updates to other blocks. Would it be time for Softr to consider a more of a “native” approach and build in the ability to do these sorts of things by checking some checkboxes in the Studio’s UI, rather than resorting to these short JS injections that vary just so slightly depending on the use case and type of block? Just a thought