Discussion: Unify pages and blocks

Feedback Feature Requests
,
8

This exactly is the problem with pages and what probably many new users confuse. They are different from blocks:

  • When tags:: mypagetag is assigned to a page - let’s also name it root block here -, I expect this tag to be inherited to all childblocks. An ordinary child block has parent/child inheritance, so it gets all parent tag/page links automatically. But this is not the case with pages, as seen in issue 1.

  • I expect the filter results of page tags to be consistent with the ones of ordinary block tags. Again not the case, see issue 2. Compare the findings of issue 2 with the results, when going to #myparenttag or #mychildtag and click on its filter - there will be more tags to narrow to.

Pages can also have tags and properties.
And it would be awesome to reference blocks by their title name as well! Imagine you would be able to write Grandparent/Parent/My child block to quickly reference arbitrary nested blocks - what today is possible only with page namespace.

This whole thread doesn’t deal at all with the fact that pages have a title you can use to reference them and that pages are nodes in the graph view.

According to Tienson Qin, non-page blocks do have a title - it’s the one line you see as link, when using block references.

Question: Do I miss an argument here, which justifies that pages are kept so differently, that we get confusing problems in the user interface and need to partition the application logic in both pages and blocks (aka page-tags etc.)?

Yes, pages can be persisted. But domain driven design tells us, it’s not a good idea to let core logic or user interface (queries,filtes, etc.) depend on the type of storage. It seems to me, pages are just a storage mechanism.

Concerning graph:
Page = root block, so we might think of graph widget currently as displaying all root blocks and their connections. In future, this could be even enriched with more block details.

Mark my words: Tana’s “everything is a block” approach will be a shoot in their own foot.

Don’t have a Tana account, so I cannot fully understand why even their application settings are a node. The sentence “everything is a node/block” might be ambigious on its own, so let’s keep it simple: it’s about pages vs blocks, and keep everything intuitive, consistent for users and easy to maintain/expand for devs.

I hope that once the query builder is implemented, its UI will made it clear how to query for tags, page-tags or both.

Query builder is a cool idea! But we should get the fundamentals right first.

2 Likes