4 ms·
Love the idea. Clearly, a ton of effort put into this, congrats on shipping. But if you're going to abstract away Google Sheets, you might as well make a thicke
by igammarays 9y ago
Love the idea. Clearly, a ton of effort put into this, congrats on shipping. But if you're going to abstract away Google Sheets, you might as well make a thicker abstraction. I want to use Google Sheets like a key-value store or some Mongo-like API, without thinking about worksheet names, column names, or underlying worksheet-specific implementation details. Your custom designed API is too much of a leaky abstraction, seems that it's not too far from me learning and using the Google Sheets API directly. Consider how other libraries like diskDB abstracted away the filesystem behind a Mongo-like API.
- adam_seeliger 9y agoThen submit a pull request. Don't sob about it here.
- quickthrower 9y ago... or sign up for firebase.
- michaeloblak 9y agoThat's a very good insight! We treat spreadsheet more like a database with a schema. What you propose is a schema-less approach. I like this idea, and I think we will try to implement it, as we see that in such solutions schema is needless and is adding more complexity for the end user, which, in most cases, don't care if there is any schema or not - she is just a spreadsheets user. From the other hand, it's hard to map JSON to a spreadsheet, because - what to do with the nested keys. Any ideas?
- parthpatel1001 9y agoYou could flatten the json object - instead of joining the keys with a `.` scheme, treat those as columns in your sheet.
- deleted 9y ago[deleted]
- ibizaman 9y agoDon't hesitate to stick to enhancing the low-level non opinionated api. Having one is great because that enables all users to do what they want. Then you can have other apis on top of it for opinionated usage like a kv store or other stuff. For representing a nested key the first implementation that springs in mind is to use the indent (number of empty colums on the left) as indicator of parent-child relationship.