James King

Had exactly the same thought! It feels redundant to have a Supertag with a plain field labelled 'My search" and the field value being a single search node also titled "My Search" that you then need to expand to actually see the search results.

It also means you need to user the GRANDPARENT search operator in those search nodes if you want to perform the search based on the identity of the Supertag that owns the field search.

This took me a while to figure out. My initial instinct was to look for a "Search" type of Field to add to my supertag content template.

I am really feeling the need for something like this feature.

Airtable does this so well. They have very powerful formulas for working with fields, but also special fields they call "Rollups" and "Lookups" that allow you to work with the data contained in linked records (analogous to linked Nodes in Tana).

Really hope that a feature like this is in the pipeline!

Airtable's API is one of the best implementations I have seen. You get an API that aligns with your own data's schema. https://airtable.com/developers/web/api/introduction

I could imagine a similar approach working really well with Tana. These are the sorts of requests I could imagine finding really useful:

• GET /supertags/<supertag_id>/list_nodes would give you a list of all nodes tagged with that supertag
• GET /node/<node_id> would give the content for a particular node
• GET /node/<node_id>/descendants would give you a list of all nodes nested under a particular node. This would be particularly useful when applied to a search node.