Thatâs actually very helpful to hear! Giveâs me some insight on how I can make the explanation a lot more friendly / less intimidating. As for autobinding, that simply just saves the json data to whatever âthingâ you bind to it. In my experience, itâs usually easier not using the autobind feature, but I left it in since some people have a good reason to use it.
A good place to find a real example is on my example page in bubble here. You can just copy and paste the column json from my example to yours, and you should be able to tweak it relatively easily. If you run into issues, let me know exactly what youâre trying to set up and I should be able to help out!
Hey! I recommend you check out my example where I set it all up here. Youâll also definitely want to check out the documentation. You just need to copy and paste the âcolumn jsonâ settings, and you can edit it to make it your own!
Hmm, so from what I undestand, I can only autobind the whole json to one field?
Like, if I display a table with columns A, B and C, with rows 1, 2 and 3, it can autobinds to only one cell in a bubble db, for exemple, it would autobind to a column âuserâs spreadsheetâ in the Users db, so that each user would get his spreadsheet auto-saved in his row.
And if I want to save the columns and rows A B C / 1 2 3 to specific cells in other columns, I need to map them myself using bubble/javascript, it canât autobind directly to columns A B C rows 1 2 3 in my bubble db
And when you say âIn my experience, itâs usually easier not using the autobind featureâ, itâs that itâs easier to do just a View (just Read data) than to Read And Write (whole CRUD)? (Which is logic without more explanations) Or is it that there is another way of saving data that is easier than autobind?
Happy to help, and thanks to you! To get back to the âhow I can make the explanation a lot more friendly / less intimidatingâ, I think what I would need is a matrice of context â solution. At first, the plugin seams to do everything kind of easily, then you realize the work behind excel/gsheet and you understand that you wonât get the same, then you realize it will be more complicated or limited than expected, then you realize that there are actually different possibilities for different use cases, that have different levels of possibilities and difficulties. What would be great would be to jump right to the last step. Like if you had a matrice saying:
use case
Read
Read and Save
Read and autobind
one bubble table with only simple values (just text/numbers/option sets)
setup in 5min with method A
setup in 1h with method B
setup in 3h with method C
one bubble table with joined values (ex: clientâs name, clientâs productâs title)
setup in 1h with method D
setup in 1h with method B
impossible
several bubble joined tables (ex: clientâs name, clientâs productâs title, clientâs productâs category)
setup in 5h with method D
setup in 2 days with method E
impossible
a json stored in a cell in bubble (clientâs spreadsheet_json)
setup in 5h with method F
setup in 2 days with method E
impossible
json from the bubble api
setup in 5h with method D
impossible
impossible
json from an external api
setup in 5h with method F
impossible
impossible
âŠ
This would be really awesome, and help me understand what I can do, how, and when (MVP this week with features A, V2 next month with these features for use case B, and use case C wonât be achievable for this reason and thatâs life).
Wow, well appreciate the detail here! Iâll have to sift through this post more later, but Iâd definitely be interested in adding a chart like you mentioned to the documentation.
Youâre correct that auto-binding simply saves the json data to a text field in the bubble DB. It canât do anything fancier than that, and unfortunately itâs not possible to do too much more due to the restrictions of bubble plugins. It should be able to read + write to one field.
The other option for saving the json data field, which Iâd probably recommend, is to add an action called âwhen table X is updatedâ and then save âTable Xâs json dataâ to the field that way. To âreadâ the json data, have the âcolumn jsonâ field in the plugin panel set to the field where youâre saving it.
If you wanted to do anything fancy with the data like splitting it up, calculating stuff with it, etc., youâre going to need to do that with javascript - which would be innately complicated.
My most valuable use for this however is to send it off to external APIâs, since most of them require JSON as the input.
Can I recap what I understood and you tell me if Iâm correct / what I missedâŠ?
From what I understood, I see 2 main use cases that are relatively easy to build and high:
Displaying a read-only big clean table from an API, full-featured (display the table as needed, + user can search, order, and even add formulas), with one row per record from the API (especially the bubble api to get things from the bubblerâs db, or other third party APIs), with easily 100s/1000s of rows, and when the user clicks a row, we can display a detail view of the record, where the user can edit the thing.
Creating a full featured editable table with autobind, which is amazing, but each tableâs entire json must be stored in 1 unique cell in a bubble table, which limits to ±small tables, and it generally means creating a bubble table named âJsonTablesâ, which stores the jsons (1 table = 1 row).
Then, there ±can be possible to make a big editable table where each jsontable row comes from a different bubble row, but it means lots of hacks, which means dev time + loading time + risks of ui/ux bugs.
Is it the main use cases you have or is there other things that work well?
This sounds mostly correct, however the tables shouldnât be limited to small tables only. I donât see why having huge tables would be a problem. Also shouldnât be too many hacks needed unless youâre trying to do something complicated.
I created this plugin because I needed it for a specific purpose, and that was to help with onboarding (by entering details for a list of stores) / sending things to APIâs via JSON. Thatâs what it does best, however Iâve also used it in several other apps Iâve made, like for use in forms, where users need to input several things per item, etc.
The plugin looks really promising, but Iâm encountering an issue. Whenever I try to display the table at a reduced screen width, it gets cut off in the middle and canât be fully viewed. I noticed that in the demo you created, the plugin gains a scrolling option as the screen narrows.
Hereâs a screenshot:
@DevoPanda Thanks for this plugin, we purchased it today. Is it possible you could add the âcontextMenuâ false attribute as an option to the plugin? Iâd really like to disable the right click effect.
The plugin is focused on producing / writing JSON, and wonât read any. As far as making more complex / multi-level JSON, unfortunately thatâs not possible out of the box here.
Hi, glad to hear that! Apologies for the delay, but Iâve just published an update for this! You can now hide the right clicking context menu. Let me know if you find any issues