Odd behavior with reactive inputs/outputs and reading/writing values from file

[jwhendy]

I re-created an odd issue I just ran into. Here's my reproducible example:

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import dash
import dash_core_components as dcc
import dash_html_components as html


def generate_inputs():

    print('getting value!')
    f = open('./value.txt', 'r')
    current_value = str(f.read())
    f.close()

    print('current_value: ' + str(current_value))

    input_box = [html.Label(html.Strong('value to write; currently: ')),
                dcc.Input(type='number', value=current_value, id='input_value')]

    return input_box


app = dash.Dash()

app.layout = html.Div([
    html.H2('debug: getting and setting'),

    html.Div(
         generate_inputs()
    ),

    html.Div(id='file_value_written')

]) # app.layout


@app.callback(
    dash.dependencies.Output(component_id='file_value_written', component_property='children'),
    [dash.dependencies.Input(component_id='input_value', component_property='value')])
def update_file_value(value_to_write):

    print('set value!')
    print('value_to_write: ' + str(value_to_write))
    f = open('./value.txt', 'w')
    f.write(str(value_to_write))
    f.close()
    
    return value_to_write


if __name__ == '__main__':
    app.run_server(debug=True)

I walked through my process step by step as well:

| step | description                     | printed                              |   cat | gui   |        |
|      |                                 |                                      |       | box   | output |
|------+---------------------------------+--------------------------------------+-------+-------+--------|
|    0 | touch value.txt                 | -                                    |     - | -     | -      |
|    1 | echo "1" > value.txt            | -                                    |     1 | -     | -      |
|    2 | python debug-get-set.py         | getting value! current_value: 1 (2x) |     1 | -     | -      |
|    3 | open localhost:8050             | set value! value_to_write: 1         |     1 | 1     | 1      |
|    4 | click in box; delete 1          | set value! written value: empty      | empty | blank | blank  |
|    5 | type 2 in box                   | set value! written value: 2          |     2 | 2     | 2      |
|    6 | click to remove cursor from box | no message                           |     2 | 2     | 2      |
|    6 | Ctrl+R; reload page             | set value! value_to_write: 1         |     1 | 1     | 1      |

This seems odd to me, but I'm very new to dash, so please let me know where my thinking is awry. Throughout the changes, we can check four key values:

• the value read from the file, stored as current_value
• the dcc.Input default value, passed as value=current_value, to be shown as the prompt in the text input box
• the value passed to the callback and written to the file, value_to_write, which we call if our dcc.Input value changes (not sure how dash checks for a change)
• the return from the callback, put on the page with html.Div(id='file_value_written')

Upon load, they all agree on the value being 1. It's printed, the file contains it, and it's displayed in the box and below the box. We change the box contents to 2, and the effect pushes through to the html.Div on the screen and the file (checked with cat). It's also still in the box, obviously.

When we reload we're told we're setting the file contents, but that should only change if we're in callback. That only happens if the current text box changes, and we didn't touch it. It almost behaves like the value currently in the box might be cached (or in some sense not really changed), and even when we delete/replace it with 2, the cached/stored value is 1. On refresh, things work in reverse: 2 is treated as the last value seen and the cached value, 1, shows up as a user change and is written. Is that a crazy interpretation?

What I expected: reloading would re-run things top to bottom, it should read 2 from the file, use 2 as the default value in the box, and wait for a callback trigger if the user changes what's in the box 2.

This was a wild chase to just work through in my head and I am coming up clueless. Thanks for taking a look!

[ned2]

I think if we unpack what's going on in that code, it winds up being not that mysterious. There are two things going on I think:

Firstly, when you first start the app, it prints that it's setting the file contents, meaning that the callback fired. So the callback firing on an initial page load is expected behaviour, so it's unsurprising that a callback is triggered for a refresh, in fact I would expect this to happen.

Secondly, the layout component that you have attached to app.layout is evaluated precisely once when you first run the app. In the process of this, it needs to evaluate the function generate_inputs, but it will of course only ever evaluate that function once, meaning that the default layout for your app, before any callbacks are applied, will always be this initial layout containing the very first contents of that file. It looks like it's caching the first value because that is in effect what you've asked it to do.

Hopefully that explains all the odd-seeming behaviour you noted.

(also, it might that that the Plotly community forums would be a good place to ask these sorts of questions where more people are probably hanging around to answer)

[jwhendy]

Hi @ned2 . Thanks for taking a look! Good to know that you don't think anything odd is going on. I've only done a little reactive stuff with R/shiny and still feel mystified...

I figured setting fired on the first page load because there was nothing there. Like None being different than the suggested value=1? At that point the server is running and I would not have thought it would necessarily run upon a refresh if nothing changed. I viewed the reactive nature as saying "if what's in the box changes, run this callback." Now, that might be evaluated differently than I expected, but at a layman's read I wouldn't have thought it was de facto, outright expected?

I also would not have expected that generate_inputs() is only called once. I would have figured that on a refresh, it re-reads the file. How can I make it do that? Where is this "cached" value living? For exapmle, the setting callback was passed a 2 in my test the last time it ran. Where is getting a 1 from when called upon a refresh?

Is there a tweak I can use to have this work as expected? I just want to create a UI where a template is read in, the values are stored, and if the user changes something we write out a modified config based on the changes (and if there's changes).

I can check out the forums if you think that's a better place. Thanks again!

[chriddyp]

I also would not have expected that generate_inputs() is only called once. I would have figured that on a refresh, it re-reads the file. How can I make it do that?

See the second part on https://plot.ly/dash/live-updates: "Updates on Page Load"

I viewed the reactive nature as saying "if what's in the box changes, run this callback."

We fire all of the callbacks on page load to keep the app's state "consistent". Consider this example:

app.layout = html.Div([
    dcc.Input(value=1, id='input'),
    html.Div(children='Nothing is selected', id='output')
])

@app.callback(Output('output', 'children'), [Input('input, 'value')])
def update_output(value):
    return 'You have selected {}'.format(value)

In this example, when the app starts the callback is fired and the output div will update to say "You have selected 1".

Consider what would happen if the callbacks didn't fire on page load. The output div would say "Nothing is selected" but the input would have the value 1. If you were to just glance at the application, this UI would seem wrong. And if you changed 1 to 2 and then back to 1, the app would say "You have selected 1". Which would seem odd, because before the app said "Nothing is selected" when "1" was selected.

In Dash, you should always see the same outputs given a set of input values. It is not a function of the history of the user interaction (i.e. whether the app was just loaded or whether one input changed before the other input).
If we didn't fire the callbacks at the start, then there would be a possibility for you to see a different output for the same set of inputs.

[jwhendy]

Wow. After constructing this for probably going on an hour, I think I found the issue. It appears that:

app.layout = function()

is not the same as

app.layout = function

!!!

I'm leaving the below for reference. At least it might help others understand what I was seeing. I was very sure that I definitely was seeing outputs change as a function of user history. In essence, reloads were using the existing of a file when the server was started, so in that sense the same current file value would create two different results depending on whether the user opened the page for the first time or was opening a page that was a continuation of an existing server instance.

---

The issue isn't callback on load, it's where the value to the callback are coming from. I've re-written your example based on that "Updates on Page Load" suggestion. What do you think of this:

import dash
import dash_core_components as dcc
import dash_html_components as html


def serve_layout():
    with open('value.txt', 'r') as f:
        file_value = f.read()

    return html.Div([dcc.Input(value=file_value, id='input'),
                     html.Div(children='file_value: ' + str(file_value)),
                     html.Div(id='output')])

app = dash.Dash()
app.layout = serve_layout()


@app.callback(dash.dependencies.Output('output', 'children'),
              [dash.dependencies.Input('input', 'value')])
def update_output(value):
    return 'callback value: {}'.format(value)


if __name__ == '__main__':
    app.run_server(debug=True)

Create the file:

echo 1 > value.txt

• Start the app; file value and callback agree on 1.

echo 2 > value.txt

• Refresh the page. Everything says it's 1.

Nothing about this behavior is odd? My interpretation is that you're emphasizing that the callback should run on load and refresh. I'm fine with that, but think I'm showing that some cached value is used in the callback. It prints a message based on the value attribute of the Input, but that comes from the file and should re-run on refresh based on that page.

[ned2]

Nope, this is not odd. In the code you posted, you're reading the value of the file within the serve_layout function, which is only ever evaluated once -- the first time the app is loaded. So every time you hit refresh, you're getting the same layout object that was previously evaluated and assigned to app.layout, irrespective of the contents of that file.

You raise an interesting point though, when you assign app.layout to the actual function serve_layout, as opposed to evaluating it and assigning app.layout to the component object it returns, this behaviour changes to display the current results of the file. It would seem that when you do this, Dash does indeed evaluate app.layout on every page load.

So which should you use? I think it just depends on what you're trying to do. Personally, I think it's better practice to default to putting all the dynamic generation of things within your callbacks (so in your case you would read the value of your file only within callbacks). This way you're less likely to run into surprises like this. Also, using a static app.layout (as opposed function that's evaluated on every page load) also means that any run-time errors in the evaluation of your layout will happen immediately on initialisation of your app rather than later on while someone is using it. But there may be times we you really do need dynamic evaluation of app.layout (maybe you have to call a database or something) so then you'd use a function.

[jwhendy]

Thanks for the tips @ned2 . I didn't initially expect the callbacks to run all the time, but now that @chriddyp clarified how those work (run on every load/refresh), having anything dynamic happen in them is a great point I hadn't considered. Thanks to both of you for enduring a noob :)