Dash & XLwings. Attempting to pre-load Excel before Dash callback to save load time. about dash-bootstrap-components

[tcbegley]

Hi @karnrage

This seems like more of a Dash question than specifically a problem with dash-bootstrap-components. I would recommend asking your question on the Plotly Community Forum instead, as the issue tracker here is really just for reporting bugs and making feature requests.

At first glance though, something that might be worth looking into is the section updates on page load in the Dash docs. It would allow you to update the workbook each time the app was loaded. If your app allows the user to make changes to the underlying file though then you'll probably have to rethink.

LAYOUT = ...  # define your layout
WB = None

def reload_workbook_and_return_layout():
    with xw.App(visible=True) as app:
        global WB
        WB = app.books.open(...)
    return LAYOUT

app = Dash()
app.layout = reload_workbook_and_return_layout

[karnrage]

Hello,
Then I would like to make this a feature request. A component that would allow passing the file as an id/property pair.

When you say updating the workbook, do you mean as only to write/delete to the workbook? Aren't the workbook and file the same thing? The way we have it the workbook does calculations/evaluations within both VBA and cell formulas.
The 'with' statement handles the closing of the file within itself. Normally this is good, but for our case we want the file to remain open until the final callback is invoked. That's why I wanted a chained callback so I could revert using 'with.' The first would handle the connection, the second would handle the updating/evaluation and closing.
I attempted the global way, but then I lose the multiple instance feature. Our code is a little different so I will attempt what you have. If it works then great, but this is a workaround.

[tcbegley]

Then I would like to make this a feature request. A component that would allow passing the file as an id/property pair.

I'm afraid that's not something we're going to support as it's out of scope for this library. The purpose of dash-bootstrap-components is really only to make available Bootstrap features and components more easily available in Dash. What you're requesting is a fairly specialised use-case focused on backend organisation and persistence of data.

Aren't the workbook and file the same thing?

Not necessarily. I don't know much about xlwings, but it's possible you could load the contents of the file in memory, change what you have stored in memory, and simply not persist that back to the file. Multiple users could be referring to a different copy of the data in memory, making changes, without affecting anyone else reading the file.

we want the file to remain open until the final callback is invoked

This is tricky with Dash because callbacks are ideally supposed to be stateless. This is important when running a Dash app with multiple workers, because a single user could have their callbacks processed by different workers which won't have access to the same memory, hence not the same global variables.

There's basically two things you can do:

1. Only ever deploy the app with one worker. It will work but might limit your ability to scale the app if you anticipate lots of users.
2. Have some kind of shared memory store that holds the open files and can be accessed by each worker using some identifier. The best choice here will be highly dependent on your deployment environment and exactly what you're looking to save.

I attempted the global way, but then I lose the multiple instance feature.

Instead of a single global variable, you could have a dict storing {identifier: workbook}. Then when the first callback is initiated, you save the identifier client-side in dcc.Storage which you pass as State to all subsequent callbacks. That way each callback could access the open workbook via WORKBOOKS[identifier]. You'll need to be careful to clean up after yourself though, as you don't want to keep appending to the dict every single time the callback is run. Ideally your final callback would clean up that entry of the global dict.

I will emphasis again that my knowledge of this kind of thing is limited, and you'll be better off asking for help on the forum.