I’m in the same boat. I have all of the inputs and text generated on the front-end, but I’m just not sure how to save the list of Things while relating them to the data source of their parent repeating group. I’d love to hear if you found a solution.
I’ve seen some others use .env or JSON builder plugins to build payloads and send to backend workflows/the API connector, but I feel like there’s an easier way.
Yeah, @ihsanzainal84, here’s the thing:
One HUGE limitation of Bubble is that we have no real access to objects (by which I mean JavaScript objects) created in the page. The only objects we have access to are Things. And a Thing can only be made to exist via interaction with the database.
So, even though a plugin could create an object – for example, something that sort of looks like a Thing (in that it might have all the fields of a Thing that you’ve defined in your app) – we have no way to publish that back up to Bubble as an object. A hacky workaround would be to build a plugin with a terrible interface that allows you to define the types and outputs of certain scalar or list fields that correspond to the fields of a Thing, but the interface there is terrible (and cannot support an arbitrary number of such fields).
(Additionally, plugins cannot directly create new Things, nor make changes to existing Things. This can only be done by the Bubble programmer using the Create New and Make Changes to a Thing Actions.)
Now: Of course you can define an object as JSON (that’s just a string) and you can save such a string in local/session/indexdb storage using Floppy by specifying the key type as text. And then, when read back you could process it using the techniques that you (and @providers ) already seem to understand.
So, I don’t see much advantage to trying to do things that way. Let’s say you ideally wanted to store an object in storage that has a string field, a number field and an array of dates. (This is just an arbitrary example.) Let’s say this object represents a calendar or something.
Well, rather than making this hard, just store these items independently as different keys of the appropriate types: a Floppy for the string field, a Floppy for the number field, and a Floppy for the list of date type. If you want to make it “feel” like working with objects you could give the key names names like calendar.name, calendar.number, and calendar.dates.
If you’re using IndexedDB as your storage, you can make this even more object-like, because IndexedDB allows you to name a database and then name a unique data store.
So what you might do is have those 3 Floppy’s set up like:
If you don’t need to do any of the fancy list manipulation / math / iteration stuff in Floppy, you can instead use the Floppy Storage (in later versions, renamed Floppy Reader – there’s just no good name for that thing) element to access all of those keys from a single Floppy Storage element.
Once I do some video show and tell about IndexedDB this will become more clear if I haven’t made it clear already.
Yep it’s clear as day, thanks for the clarification @keith ! Unfortunate that Bubble has to apply limits to plugins but no one wants a rogue plugin messing with their DB.
That’s pretty much how I have things planned out in my quest to optimise every inch of my app using Floppy currently. I know there are already plugins that can read/write JSON but it’ll be great if Floppy also had a built-in JSON encoder/decoder but I think that’s asking a little bit too much after everything that Floppy already offers 
Keeping in mind that one my want to use Floppy Reader for this sort of use case, I may add some features there to help manage that better.
For example, what if one wanted to define a Floppy Reader in that same way as the “calendar” example, but one wanted to consider that as a single object and then create additional “objects” of the same type?
In that case, we might want some additional actions and outputs to enable that (to the extent that we can).
I’m still kind of thinking about new capabilities there and there will of course be future enhancements to the Floppy plugin elements.
While I still have you here I have a quick question (a little sidetrack) I’ve been doing some tests on memory usage in a dropdown retrieving one field from a list of things.
Here is the order of heap sizes from Largest to Smallest (I’m still new to any kind of debugging tool let alone Chrome’s inspect tool so I might not understand rightly how snapshots of memory heaps work):
I’ve read your post on how Bubble lets plugins load Things but I’m still wondering how does using List Shifter make my Bubble app load less data among the 3? Is it because the state loads all data (as per my Privacy rules right?) and List Shifter doesn’t?
EDIT: Ignore me I think it was just having Bubble’s Debugger on messing with my test results
Also… (just writing this down to remember it later)… I could create a system that basically parallels how Bubble’s database works, but operates in IndexedDB. This was not a design goal for Floppy, but it’s possible … though this will require some design and thought so I wouldn’t count on it as a very near-term enhancement.
Note that the current Floppy support for IndexedDB is very new and was only easy/quick to add because of the localForage library, which provides an interface to IndexedDB that imitates the localStorage interface. (But it is not meant to implement a generic interface to IndexedDB.)
@Keith we have started working on a free community developed interface to IndexedDB because I think it could help a lot of people out in the community. I would love to see Floppy be the sort of high-level Bubble version which is simple and straightforward to use and implement while the community version becomes a more barebones low level IndexedDB implementation aimed at developers. It goes without saying, that this is just an idea
Finally a good place to store cached onboarding steps 
You’re a bubble-GOD @keith !
Great job!
This is EXACTLY the sort of use case that I intended to address with the core features of Floppy, @Guru!
Floppy is ideal for applications such as:
Tracking completion of onboarding steps/caching answers to onboarding questions before account creation.
Storing app or page-specific preferences such as “dark mode” or other style-related prefs.
Restoring the state of some page after an OAuth login.
“Unlocking” content after some form completion. (For a non-login type site/app, after the user “converts” by submitting a form, don’t show the form again. This is something I actually do in a non-Bubble marketing site that I help maintain. If a visitor registers for some whitepaper in the session, if they visit other “gated” pages, the gate does not appear and the visitor can immediately download the content.)
Tracking the “previous page” for important conversion pages. (e.g., if you have a single “sign up” page or “demo” page or whatever, record the page they came from before navigating to that important page. Writing such a value to localStorage will enable you to know what page led them to conversion… you could even recover that value with Google Tag Manager (using localStorage.getItem() ) and pass it to Google Analytics or whatnot. This is another thing I do in non-Bubble sites.)
Tracking dates such as “first visit”, “last visit”, etc. Or, indeed, tracking any simple states for non-login apps.
Enabling “save for later”, “wish list” or “last (n) products (or whatever) viewed”. Similarly, enabling “drafts” or “undo” type features.
Obviously, the use cases are endless, but you get the idea.
Just curious about one thing, do you have any tips (if it’s possible) on how to use floppy as an environment variable plugin? (reusables, etc)
Also! I was wondering if I’m doing it right… If I want to store multiple keys (lets say a user id, user first name, user last name, etc…) Do you suggest doing a workflow step for each of these keys of a single “user data” text list and reference them via their index number?
In your “user” keys, I would do these all as individual keys. (3 keys, even if they are all strings.)
If using localStorage, key names: user_id, user_firstname, user_lastname.
If using IndexedDB/localForage: Database name whatever, datastore name “user”. Individual key names id, firstname, lastname.
As for environment variables follow the same pattern (localStorage key names env_whatever, env_whatever2) (IndexedDB database whatever, datastore name environment, individual keys whatever1, whatever2).
But there’s no “wrong” way to do it. But I wouldn’t make lists out of different keys. Use list type keys for true Bubble lists (e…g., key “wishlist”, a list of Products).
With the dexie.js wrapper @bubble.trouble??
I’m sure they’ll use Dexie. But I’m also relatively sure more robust features like this will hit Floppy before a useful plugin emerges anywhere else.
(Not that Dexie solves much for you, TBH. Bubble’s lack of objects makes anything like this sort of a shitty experience. It’s almost not worth anyone building - free or commercial — because very few users will grok how to use it.)
That being said, I see some neat things one could do and as a value add to Floppy it would be cool.
I’ve bought Floppy!! 
But you know what I’m trying to achieve
One person at least seems to have achieved what I’m trying to, so now I’m convinced it IS possible I’m pretty keen to make it happen. Haven’t had a chance to see how far the current version of Floppy gets me but if you’re happy to keep developing Floppy in that direction I’m super happy to chat and perhaps even sponsor some of it
Oh I know! But custom app implementations of external libraries are quite different from making generically useful Bubble plugins. I’ll explain what might be gained by a Dexie-based plugin in a PM, @equibodyapp.
Thanks so much @keith
Can anyone help with getting the stepping working? I need a bit of guidance on what the workflow should look like to step through a list and perform a workflow for each step. Thanks
There will be a video on this soon.
In the mean time: set up a workflow to begin stepping. You set up an additional workflow that triggers on Next Step. This is the workflow that will execute on each step. Reference the values you need. Do all the stuff. When done, execute Floppy’s Next Step Action.
