📣 Announcing the Storage component

#21

Implement it the same way storing in hidden divs worked: using a callback retrieve localStorage contents as State, manipulate the data, and save. The default “click count” demo in the documentation illustrates how to read and update values stored in local/session/memory. Should be easy to extend to a updating a list of values or dict of list of values.

You can also use State('store-element', 'modified_timestamp') as a lookup for querying new data. Believe the modified timestamp is given as epoch time in milliseconds.

1 Like
#22

This is a HUGE improvement over the hidden div method. Much appreciated. However, I wanted to verify one point: the Store method will incur the same network transport costs as a hidden div, right? In other words, I will still likely want to cache (memoize) very large files?

1 Like
split this topic #23

A post was split to a new topic: Infinite loop with dcc.Store?

#24

Just getting into Dash… so far I’m finding it lets me develop better data visualisation GUIs in a fraction of the time it used to take me (with matlab or IDL) despite the fact that I’m just starting up the learning curve. So, thanks!

Are there any dreams or possibilities to get this going without the overhead of passing the data through a string datatype at some point in the future? Or maybe there is a keyword/flag that I’m missing and it already does this somehow?

It’s much cleaner to have all that hidden div stuff outside of my program, but the fact that it still happens under the hood makes a big difference. In my case (started using larger data sets) I started using a store to keep a downsized copy of a downsampled/averaged portion of data I’m actually visualising. This made it possible for the code to actually execute… but a variety of callbacks all use it, and converting it to/from strings to lists (and then, inside the callbacks, a numpy array) really slows things down. A few benchmark operations take > 2 minutes using a dash store, and < 15 seconds using a global variable.

#25

A few benchmark operations take > 2 minutes using a dash store, and < 15 seconds using a global variable.

The store data is sent back and forth between the client and the server for each callback. This create network latency. You can try out multi-output and combine the callbacks so there’s only one requests with the store data instead.

1 Like
#26

Oh, wow - that’s a game changing feature! I have yet to make a count, but I’m guessing I could merge about 10 callbacks into a single one that’s going to be faster and probably also easier to read and understand. Things just keep getting better…

2 Likes
#27

Is this for every callback in the app or just the ones that use store data as input/state?

#28

Is this for every callback in the app or just the ones that use store data as input/state?

Just those that use them in Input/State.

#29

Can you initialize multiple stores from one global store?

Let’s say I have a multi-page app and want to store an expensive query in a global store on the index page. Then, I want each page to have its own store that only uses a part of the data obtained from the global store.

Is this theoretically feasible with the current implementation of dcc.Store?