Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Buttons for recalculation only work once. #137

Closed
karlmvwaugh opened this issue Mar 28, 2024 · 3 comments
Closed

Buttons for recalculation only work once. #137

karlmvwaugh opened this issue Mar 28, 2024 · 3 comments

Comments

@karlmvwaugh
Copy link

So I am trying to use a button to trigger a recalculation (in my actual example there are a lot of variables to be set prior to a recalculation of an expensive bit of code) - I have this working in a Pluto notebook (also using Refs to de-bind the variables), but this doesnt work when pushed to the SliderServer.

I have created this simplified example and the button only causes a recalculation the very first time.

# ╔═╡ a014ff5c-bba4-4e0d-bf67-bdfb2654d5c1
using PlutoUI

# ╔═╡ 1a026e8a-ed1e-11ee-3520-518d87dd0688
@bind go2 Button("Recalculate!")

# ╔═╡ 7f2a2ad7-0bc3-4880-b947-c69eb554b83a
begin 
	go2
	rand()
end

Is there something I'm doing wrong? (this simplified situation works as I would expect on Pluto but differently via the SliderServer) or is there some work around I have to do?

@fonsp
Copy link
Member

fonsp commented Apr 23, 2024

Hey! You can use a CounterButton instead of the default Button.

The reason is that PlutoSliderServer caches results. Every time you click a Button, the bound value is the same, so PlutoSliderServer assumes that it can send the same result again.

CounterButton sends a different value every time, so you avoid this problem.

Hope this helps! Sorry for the late response. Please let us know if you have any other feedback! Was it easy or hard to set up your server? Did other notebooks work as expected?

@fonsp fonsp closed this as completed Apr 23, 2024
@karlmvwaugh
Copy link
Author

@fonsp thanks for your response. I can see that this would solve this issue (I didn't know of the existence of CounterButton, it wasn't in any of the docs on interactivity that I'd seen).

As much as I can understand caching it seems a shame to have the behaviour of the SliderServer be radically different from the behaviour of Pluto itself. The environment we were looking to set up was one where a developer would make a Pluto notbook locally and then push it to the SliderServer as a version that could be shared with the wider team, and having features that behave differently between the 2 just causes problems where it works locally but not in production, and nobody ever wants those kind issues.

We had another issue around using 2 or more MultiCheckBoxes, where trying to select options on one would undo the setting of the options on another.

The set up of the PlutoSliderServer was easy enough but these inconsistencies between running a notebook in Pluto vs PlutoSliderServer means we've no longer continued with this approach.

@fonsp
Copy link
Member

fonsp commented Apr 24, 2024

Thanks for the feedback!

I understand the difficulty, also because these issues are difficult to debug, and there is a long iteration cycle between seeing the problem in production, and then doing guesswork on your own notebook to fix it, and waiting for production to see if it worked. I made #138 to warn about the main situation where PSS does not match Pluto.

You could also disable caching by setting SliderServer.cache_control = "no-store, no-cache".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants