transfer between blocks and cells. (aka "cellblock1138" functionality)

[phhq]

📋 Describe the new feature/idea/enhancement you are requesting

The idea is to be able to pull the content from a cell from a Google Sheet to which you have access into a specific block in your Roam graph and to be able to send the contents of a block from Roam to a Google Sheet's cell also. This the functionality could be called: cellblock (which clearly calls out to be nicknamed cellblock1138). I see two separate functions, one for Roam block to Sheet Cell [[R2S]] and one for Sheet cell to Roam block [[S2R]].

🔑 Why do you want this?

When both [[R2S Block]]s and [[S2R Block]]s work, any data than can be brought into, computed on, exported from, synced with, etc etc .. a google sheet by any other application or service now would have a direct link to roam. Very very powerful.

⚠️ Is your feature request related to a problem? Please describe.

See this public graph page and associated public sheet for outline/specs (just my concept, you'll get the idea): https://roamresearch.com/#/app/wantedgraphs/page/3NDxN7w5G https://docs.google.com/spreadsheets/d/1ZIijr5UjCOeQzpnnahgbiNMGzyiAd0yiKiqjUSidEbc/

🔨 Describe any alternatives you've considered

N/A

💻 Environment

Platform: Windows/MacOs/ioS/etc

Browser: Chrome/etc

📷 Additional Info (Screenshots, GIFs, etc.)

[Calhistorian]

Nice!

[GitMurf]

By EA:

Hi All: Here is an idea for some smartblocks. I wrote out some draft notes at the public roam graph link below. Me thinks this would be quite powerful and effectively leverage the extensibility of sheets (and its reach) for Roamans (at least for high-value cells/blocks worth the trouble) .....

https://github.com/roamhacker/SmartBlocks/issues/133

Also described at: https://roamresearch.com/#/app/wantedgraphs/page/3NDxN7w5G _{View in Slack}

[GitMurf]

By EA:

1. integrating, curating, analyzing basic financial reports. whether its public stock quarterly data, quotes, economic data, or a startups financials, having certain blocks be “feeds” enables the addition of contextual commentary and insights within my graph. right now all these data sources are disparate. even basic KPI’s from a startup like users, purchases etc - having a block “feed” that data into Roam would make creating, monitoring and publishing content easy as pie.
2. so many other apps are connectable to google sheets - the big ones directly, but when you consider “connector” services like IFTTT, Zapier, Integromat, etc literally 1000’s of apps in dozens of domains can easily read/write cells to google sheets based on logical triggers. news with keywords, financial parameters like stocks or crypto or whatever that exceed a certain parameter, covid cases in your city, new orders, home automation alerts, etc. Sure, each of these could be connected directly to Roam via its API, but with sheets you get 1000’s of connects for free. take a look at this: https://ifttt.com/google_sheets
3. I’m not recommending this per se, but there are people who use Sheets as content management systems that feed to Wordpress, generate websites, generate mobile Apps, build custom forms, PDFs, emails, whatever. Sheets is a de=facto starter database for lots of ppl / companies. Check out glide apps, sheet2site, block spring, etc.
4. every sheet is also a CSV file basically by definition. having a sheets connection to key blocks in your graph makes it super easy to get the data into and out of anything that can load or export a csv, contacts syncing, any sort of transaction registers, long lists of files (each file and its metadata is a row) that are stored in other file systems, can all be accessible in some way via Roam.
5. computation, math. google sheets can be a black box for calculating stuff and sending it back to roam. statistics from quantities developed in roam, or derived FROM your graph. text analysis, network/node/graph analysis, etc,
6. multiplayer/permissioning. sheets can be shared or pulled from at the cell level. my feed to my roam graph of a cell in my private sheet can have as its input a public sheet cell accessible to anyone, and vice versa. cells can be locked/unlocked, etc.
7. don’t need to know how to code. lots of Roamans are domain experts but not devs. sheets (or excel, which I actually prefer, but its just harder to connect to from outside apps) is the closest and easiest way to do that and apply their own logic or AoT.
8. translate. yes, you can call google trabslate from sheets. you can call most other google suite functions as well.

Roam is “excel” for text. Well, Excel (sheets) is, well ... Excel for Excel. lol :) cellblock1138 and roam42 - just makes sense. Let’s connect them! Thanks for thinking about it.

[GitMurf]

By EA:

I forgot to mention some other stuff. First, rapid API creation within sheets, https://rapidapi.com/blog/api-google-sheets/|https://rapidapi.com/blog/api-google-sheets/, sending email from sheets (esp emails that are formulated from pieces of text according to logic, and obtaining search results and returning them. Also with roam as the “command line” and high-value graph knowledge base, sheets as sort of a middle connector layer to many services and bigger sets of data you don’t want in roam itself, its a pretty simple setup that can do a lot. And finally, advance visualizations. Almost all of those visualization libraries will work with data in sheets - and therefore can be called or updated within Roam itself, by smarbloks at the “command line” or with a button/selector. _{View in Slack}

[GitMurf]

By RoamHacker:

<@US3QGJ86Q> awesome braindump/brainstorm. So basically Sheets is a bridge with a lot of systems, if not the host of data itself. so the connection makes it a middle ground for interacting with many services. Yeah is brilliant. Pulling data into Roam not a problem, pushing data to sheets from roam not a problem. Problem is maintaining that link in some way (sync). v2 Roam API will make such things easier to do: server to server sync, even a real client API for writing. SmartBlocks is doing the same thing as TextExpander, basically raw UI manipulation. _{View in Slack}

[GitMurf]

By EA:

Thinking about the issue of sync, IMHO the sweet spot here is not continuous sync, or even automated sync (although that is fine for some use cases). Roam is about helping ppl think and be intentional, bot cluttering things up. The started smartblock eg could prompt me with a full list of available cellblock1138 sockets when I intentionally run that block, or as part of a morning script, or at some other set time interval (every other day, on tuesdays, 3x per week/month, etc) . My personal use case would be something like a smart block I run daily (call it “Jarvis”) with a laundry list of syncable cellblocks, and I can choose which ones to pull/push that day. Also one for weekly, that I can easily create a top-down view of lots of kpis for various projects and then write to reflect on the implications thereon, and create action plan and insight.

I may not want all possible updated every time - ( eg maybe I don’t want to see new TPS reports, or additions to backlog of honey-do’s, or how many extra pounds I gained last week, lol). Maybe I want to limit the newly pulled items to things I’m working on then. Something like that would be a good place to start.

Anyway, I hope someone here will be willing to help on this. I’m not a JavaScript guy and better at helping spec things out than actually coding them in js. Your sb scripting lang is pretty straightforward tho, I can do that :) _{View in Slack}

[GitMurf]

By RoamHacker:

<@US3QGJ86Q> you really hit the nail on the head. I also believe in the concept of being intentional with the data that were working with, and that is actually a big concept behind Roam42 methodology of returning block refs. some ask why would you not just use queries instead of commands. And this has its place! But Block refs offer flexibility in working with your data without hurting the original data. I think this offers great value. You can delete, move and no harm done to original. So pulling or pushing data is not hard. Sync is is possible, but prone to error until we have an API _{View in Slack}