Hi @keith! Maybe I overlooked something but how do I remove items in storage that do not exist in my Bubble DB anymore.
They currently show as “null”.
Hi @keith! Maybe I overlooked something but how do I remove items in storage that do not exist in my Bubble DB anymore.
They currently show as “null”.
Hi @keith! I think I may have found a bug.
I have a Floppy in a reusable element and a floppy in the page itself. Both read from the same keys stored in IndexedDB.
Not sure why but the floppy in the page does not auto-update when there is a change in the storage list. Whereas the floppy in the reusable element does.
FYI the workflows in the reusable element are the ones making the updates to the storage list. The floppy in the page only reads from the storage list.
Hi @keith
It seems that floppy has everything I need for my app that uses many lists. Thanks a lot for this!
I’m curious how far the experimental the drag and drop feature is because I tried it in a test app with new responsive engine and couldn’t get it to work.
Yeah, so this is a feature I haven’t discussed just yet, but Floppy’s RAM List and the List Values (Storage) can hold empty (or empty-equivalent) values, and for pretty much any datatype, including Things. (For more info on this, see the documentation for the “Add “Empty” Value(s)” field in the Floppy action, Add RAM List Value(s).)
I’m kind of curious as to how you created this list in storage in the first place? What caused the items to become empty? (See note 1 below about how this might happen naturally, rather than by the programmer.)
But, the short answer to your question (if the source of that list was a Search or similar) is just to either (1) use the Store Keys action to update the list in storage with the new Search results or (2) set Floppy’s RAM List to the new value and set the “Store New Value” option to yes.
Note that I hadn’t yet thought of the case where you’ve got a list with “empty” values in it and you want to then remove them. (The Remove RAM List Item(s) action doesn’t give you a way to say, remove empty values. This would have to be a yes/no field or perhaps better, a separate action, e.g., Remove Empty RAM List Item(s).)
Note 1 - Here’s a situation that would cause a list of Things where some of them might have empty values: Suppose we have Thing 1 (perhaps its a Product) which has a field on it of Type Thing 2 (perhaps its an Alternative Product). But not all Products have an Alternative Product defined. (Suppose maybe only 50% of Products actually have an Alternative Product.)
Now let us say that we have a random list of type Thing 1. Let’s call it some_list of_products
and its length is 100 (it’s a list of 100 Products). The expression some_list_of_thing1's :each items Alternative Product
will yield us a list that is also 100 items long, but some of the items in that list will be empty and some will have an Alternative Product!
So this is a real situation that we encounter with Bubble. And we might want to save such a list to storage, preserving the “empty” values (which, in JavaScript land are the special value null
.
But there’s a problem… Bubble is inconsistent in the plugin API about which types of lists can actually have null
values in them when they are published to a plugin output. (If we publish a list of Things as the Things’ unique IDs, we can in fact use null
in the list. However, lists that are strings (like texts, file, and image types) need to be the null string (''
) not null
. Lists of date type cannot have empty values at all (and so I replace them with the JavaScript Minimum Date). Yes/no lists cannot have null
(even though that makes perfect sense) and so null
must be replaced with false
. NUMBERS are the most problematic - they (like dates) do not allow null values at all and so null
must be replaced with 0
.
Anyway: To store such a list of Things which has empty values in storage, I preserve those empty values by representing them as “empty things” in the format {value: null, isUID: true}
(this means, there isn’t really a Thing here, but there’s an empty spot at this position in the list).
Hey @promax7 - I haven’t actually tested that feature in the new responsive engine (though I don’t see any obvious reason why it wouldn’t work).
Hey @ihsanzainal84: Unfortunately, this isn’t a bug. However, there is a “proper” way to use Floppy in a reusable element and I talk through that (and build it in real time) in this video that I made for you (it was easier to talk about than write about):
Along the way, I did find a little bug with asynchronous behavior in the update routine, so that’s fixed in the next version of Floppy.
UPDATE: Just pushed version 1.6.10 which fixes an asynchronous behavior problem I found in Floppy when recording the video mentioned in the previous post.
So, go get that.
Another little update on Floppy: If you watched my video answering another user’s question about using Floppy in a reusable/multiple Floppy’s watching the same keys, at one point in the video I mused about whether the STORE action was behaving in an asynchronous way.
It turns out that, in the current version of Floppy, if you’re using the IndexedDB (localForage) storage option, Floppy’s Store actions are NOT synchronous and are happening in an asynchronous way. It seems that when I first added that feature, I had neglected to properly await the storage event.
Anyway, since I want these actions to behave synchronously, regardless of what storage type is being used, I’ll be pushing an update later this week.
I’m just noting this because the info fields in all of Floppy’s actions state that they are synchronous and this isn’t entirely true at the moment. It’s true if you’re using session or localStorage, but it’s not yet true if you’re using IndexedDB.
Some of the IndexedDB actions (like key retrieval and removal) are synchronous, but the “store” and “write” actions are currently asynchronous. This is only happening in the Floppy element itself. In the Floppy Reader element, the Store, Retrieve, and Remove actions behave synchronously.
In the next update, everything should be behaving synchronously.
Awww yeah!
I do love your enthusiasm, @Future and apologies for this minor (but annoying) bug. The lesson here is it’s better to ship than to wait for perfection. (The Floppy element is small in delivery, but it’s more than 1000 lines of uncompressed code, and has a lot of features, so there are surely still edge cases like this. )
Haha! Totally with you on this… I have to fight this everyday (waiting vs releasing) lol. Haven’t checked the localforage library, but i’m pretty sure your plugin will evolve a lot in time. Nice one again.
Aside:
It’s totally a tossup whether to use localStorage or IndexedDB (localForage) in Floppy.
On the one hand: localStorage lets Floppys watching the same key know if that key has changed in another window. But localStorage is also completely synchronous and, if we were writing a very large key, our whole event loop is going to be hogged while localStorage does its thing. This could (theoretically) cause a noticeable performance hiccup, though we’d be hard pressed to notice it in most instances.
On the other hand: IndexedDB/localForage gives us multiple databases (if we want) and multiple datastores inside a single database. (So, like almost unlimited different bins of localStorage, organized with whatever naming schema you desire.) And its reads and writes happen asynchronously, so it doesn’t hog the event loop, even though (the upcoming fixed version of) Floppy makes it seem like those transactions are synchronous. ALSO, it’s a tiny bit more efficient because data doesn’t have to be stringified before saving and parsed upon retrieval. But you lose the “cross-window” auto-update feature.
It’s a .
(Personally, I default to IndexedDB now, but that’s down to personal preference.)
I was actually messing around with the plugin and wanted to try removing/adding specific items in storage instead of rewriting the whole storage whenever there is a change in my Bubble DB and hence how I ended up with the nulls.
The theory, and reason for me fiddling, is that if I use the :first item in a search (most recently modified item) against first item in storage (also sorted by modified date) I can reduce the data Bubble needs to load when checking if storage needs to be updated. This is cause I have a few Things that I want my reusable element (in this case a header) to keep synced.
Thanks for the video response @keith !
I know very little about what DOM events are and aren’t available and this was a good learning moment! I eventually figured after a couple sticks of cigarrettes that I’d have to do manually trigger a retrieve outside of the reusable but didn’t think of keeping the list of stored items in a state.
Btw you got my name correct! Not alot of people get my name right the first time so kudos to you!
Woot woot! … ALSO, @ihsanzainal84, if you were removing an item from the RAM List and then storing the new list… you may have stumbled onto a bug. Removing the item from the RAM List should actually remove it and then the store action (or option) should store the new list without recording an “empty” at that location. (That is, the item should be gone, but I can see how Floppy might write a null item there instead of removing the item…) I’ll investigate further.
Yep I was using the RAM list to update my storage.
That was probably an unexpected side effect of the (unexpected) asynchronous behavior. Thanks for the infos.
@keith I am using this plugin and found it very useful.
However, in few case I am getting this error, can you please guide me debug the same?
The plugin Floppy: localStorage, Lists & more! / element Floppy threw the following error: TypeError: undefined is not iterable (cannot read property Symbol(Symbol.iterator)) at Function.from () at r.array_from (https://erp.packsetu.com/package/run_debug_js/43d96166d72129ba6fea0c8acb164e15496e7cf8403e1773dbd50c034c2da488/xfalse/x17/run_debug.js:6:2664223) (please report this to the plugin author)
00:37:00
Element Floppy_InventoryList
Hey @packsetu, since it’s not in the error message, what action are you calling when this error occurs? Can you show me your workflow? Also, what sort of data type is in Floppy_InventoryList? (a screencap of the setup of that floppy might be helpful as well)
@packsetu - oh, also, make sure you’re on the latest version of Floppy and that the version is not a “DEBUG VERSION - DO NOT USE”.