Migrate Entity View to Blocks

Add a reaction - I have not yet understood this function in outliners. What a profit from her. The main thing is that then all these “reactions” do not “clog” the “Notifications” section.

Regarding the “high-grained” - I agree. PKM uses a smaller block scale, but there is much less information there. If you increase the focus too much, you will quickly “get lost” in a huge number of these blocks.

The only thing is that it will not always be possible to make an adequate transinclusion. Users will have to train themselves to write texts in a certain logical format: atomic and “portable”.


I’m a little hesitant to have too much of a reaction without seeing exactly how this works in practice. The thing I worry about by making the blocks larger elements is just that you might lose the ability to tie them together with supporting text and additional context without having to create new fields.

For example, let’s say that we have a working document that wants to always have the most up-to-date reference of our top 3 initiatives. So, we have an Initiatives type that maybe has a checkbox to say a particular initiative is a top initiative. We also might have an existing list view setup that applies that filter, with the view name of “Top Product Initiatives”.

So, to begin with the document might have an intro paragraph with some kind of statement. You then could add our existing view just below the intro paragraph. A common modification might be to override the view name just within the context of this document, allow the list view to collapse below the heading, hide the heading, or simplify the presentation (fewer columns shown). We might then add some additional text just below the embedded view that lets the reader know where they can submit new Initiative ideas.

So my questions from this use case would be:

  1. Are you developing this so a standalone document can include blocks?
  2. From the OP, I can’t really understand what you are/aren’t considering blocks. It seems like Rich Text fields and maybe Views would be considered blocks, but fields are not? (e.g., Problem in the screenshot is a rich text field, which i understand is essentially a Document. Can a stand-alone document be a block that has blocks in it?)
  3. Is the helper intro text and text after the view in my described use case separate rich text fields? In other words, would we have to add rich text fields each time we want to add a paragraph between two views that have been embedded as blocks?
  4. Are you considering if you’d support features/modifications to the view as I described? Collapsible heading, override heading, hide heading, hide columns, etc while not impacting the original view?

One of the things I really like in Coda is that you can create more of a living document by querying tables and transforming the data to be included in the block in a unique way. I worry a bit that by creating larger chunks of text as blocks, then something like what I show below wouldn’t naturally fit in. Notice the count of open bugs and list of incomplete features are active queries, similar to a view that are being included as-needed into the document.

1 Like

Yes, sure. A document will consist of blocks. Fallback mode is a single text block (you have it right now)

Block types:

  • Rich edit text
  • View (table, timeline, etc)
  • Chart
  • Special: Files, Comments?, etc

We are thinking whether usual field can be a block. It is easy to add, but in the first releases most likely it will not be done

Technically in this case you will add 3 blocks: Text - View - Text. There is no need to create rich edit fields, these two text fields will be just blocks. So the flow will be like:

  1. Click + New Block, Add Text block
  2. Write some text
  3. Click + New Block, Add View block.
  4. Customize View as you wish
  5. Click + New block, Add Text block

We did not consider it initially, but this is a very good idea, we will explore it in more details. Take a look @antoniokov

1 Like

This scenario in Fibery will be handled by two Views blocks. So far there is no element to show a formula result, but technically it can be done as a separate Block, or as an extension in Rich Edit field.

1 Like

As for the “RichEdit text” blocks, there is such a thought (since you are moving to the new block model anyway :innocent: ) — Add versioning (history) at the block level.

For some reason, Roam Research does not mention this function in its help and does not emphasize it. But in my opinion, it is from the must have series. For those who write long complex texts.

In “RoamResearch” this function is somewhat similar to git: «You decide on your own when and where to add a version».

There is no need for automation, completely manual mode.

1 Like

I know Michael addressed this, but in case there is remaining confusion, my understanding is that Blocks will be arbitrary units of content/functionality, and will not have to be consistent from entity to entity, thus they do not involve creating “fields”. They are a more “lightweight” solution than formalized Type modifications, i.e. new Fields. Perhaps that is a more direct/succinct answer to the root of your question/concern.

Think of them like blocks in Notion, simply individually manipulatable and addressable pieces of content/functionality, created ad-hoc. It seems like the primary change/improvement vs. existing Rich Text and Doc contents in Fibery will be the individual addressability and manipulation of these Blocks as whole units, rather than simple “free text”. Making them “objects” allows for greater functionality on each one (linking, commenting, reacting, transcluding), while maintaining flexibility and avoiding the complexity and “heaviness” of Fields.

I would also really love to see “in-line calculated values” like Coda and a couple other tools can do. It feels like a very natural and useful extension of the blocks concept you’re working on, and would be necessary for real parity with and ultimately improvement over the Coda examples I referenced in this other discussion:

I suppose it would/could just be another / menu function…

Take a closer look at the mockup, there is a history button on each block already. Assuming the mockup is accurate, it seems they are already planning this. :slight_smile:


The main question here is, in what form will it be? :grinning:

“Standard version history” or “The ability to save a block variant in manual mode. And a convenient comparison of these variants”.

These functions have different tasks:

Standard version history — View changes and roll back unnecessary ones.

Manual mode — Compare 2 versions of fully prepared texts. And choose the best one.

Typical version history :rofl: :

1 Like

Yeah, that might have been where I was confused a bit. He said “Problem is a block, Solution is another block.,” which made me think that problem and solution were consistent rich text fields that would exist on each entity of that type.

So yeah, as long as you can add rich text blocks ad-hoc as needed, then that solves my concern.

1 Like

It is a side-effect of our implementation :slight_smile: Every large text block is a rich edit text with its own history.

1 Like

This will be easy to add I hope, we’ll definitely consider it.


Ahh, I see, you specifically want named versions. Well, this feature doesn’t exist in Fibery yet, but has been requested. And based on what Michael says below, I suspect that if/when named versions are implemented at all, they will immediately work for Block versions too (if so, great!).

Can you clarify what you mean by “large” text block?

Excellent, that’s exciting news! More and more Fibery looks appropriate for a personal knowledge management system too. :smile:

This is where my confusion came in. I’m aware that each rich text field and document is a separate prosemirror document, which allows the fibery team to support collaborative editing, etc without building it out on their own. So, i thought that each rich text block would require a rich text field. However, it sounds like that won’t be required.

So, to answer your question, it sounds like all text and embedded items you add to a rich text block when you click “+ block” would be a single unit of content. You could write a single word or a novel in that block and fibery will treat it as a single chunk of content. Each line of text you write in that rich text area won’t be its own block that you could drag around like roamresearch, notion, coda, etc work. So, if they provide the ability to transclude a block of rich text, then it would be for the whole block of rich text, not a single line.

You can see how that would work based on how my use case was outlined below. No matter how much text you write, the below sequence would be leveraging 3 blocks.

Another example would be the first screenshot @mdubakov shared. The problem is one block and solution is another block for a total of 2 blocks. You can go in and add as much text or remove text and it will remain 2 blocks.

1 Like

Yes, you are exactly right. My explanation was not clear since I didn’t share enough context. Sorry for that!

1 Like

Yes, that was my understanding as well. It just seemed like an unnecessary distinction because… you can’t add any Blocks (capital B :smile:) of text within a Rich Text without it being, er… a Block, or part of another existing block. In other words there is no “large text block”; there is the creation of a Block, or there is the adding of content to an existing Block. The distinction has literally nothing to do with the size/length of the text and is in fact quite clear: you add a block with an explicit action. It can either be long or short, but it’s always a block if you make it one. :grin:

Super-early stolen progress gif…

2021-10-14 18.25.08


@mdubakov I am really happy to see this progress :star_struck:

However, I was wondering if you have considered a more granular block layout similar to what many other tools have adopted (innos.io comes to mind as one the most recent ones) where headings, text paragraphs, individual bullets, views, code blocks, etc. are all individual blocks rather than a single larger block. I know this creates a bit more visual clutter but I believe this provides the most flexibility when it comes to transclusion and block references. You often don’t know what part of the whole you may be trying to reference in the future and having individual items in a nested bulleted list available for reference.

The ability to fold indented items is also something that I really miss in comparison to other tools (particularly roam’s which seems the most mature) and can be really helpful when you are using a rich text area as a presentation/collaboration tool while sharing screens:

1 Like

I am certain they have considered it. But I too would love to know more specifically why they have chosen not to go that route. I can see some advantages to the larger-blocks approach they’re taking, but I definitely agree that in the specific case of transclusion (and block references in general), more granular is better.

I would say, however, that the “folding” issue is a separate consideration. For example Fibery already supports folding of anything beneath a header, and on multiple levels, e.g. H1 can collapse anything beneath it, including H2, while H2 collapses H3 and other content below it, but not H1. That being said my ideal is for every block to have collapsible contents and children (where children of a block exist, whether in a bullet list or not). “Children” of arbitrary blocks is only possible in systems that allow arbitrary indentation of blocks though, e.g. Notion, Innos, Anytype, which Fibery does not (yet) support.

1 Like

Totally agree. I am more used to bullet lists because of roam but would definitely like to be able to indent and fold any type of block (e.g. pictures, embeds, views, tables … ). I actually find it very distracting (likely my OCD) that I can’t currently indent text and images in fibery, unless it is in a bulleted list!

Innos seems to also use headings hierarchy in addition to indenting to organize blocks for folding which I think would be a good thing to keep going forward.

I hope the team is able to consider these use pattern because I think with this approach, fibery would be positioned in an interesting way against the other tools in this space. It would have a very robust structured data system (one of the best already) but would also allow creation of very flexible freeform unstructured blocks of data that can be used across the system. I feel notion and coda are trying to do this but (in my opinion) don’t do any of it really well. I would rather wait for a more complete block implementation than have to live with an implementation that has limitations baked in.

I think fibery’s investment on the unstructured data side would make a very powerful tool for companies & organizations in terms of knowledge retention. If the team is able to use the same system to track structured data (that you need for business processes) as well as keep their unstructured notes/thoughts/ideas with rich linkages and integration, then you are going to be losing a lot less when someone eventually moves on. We try to use forms, wikis, reports to consolidate information, but I know from experience that some really great things never make it into these official documents but live in people’s notebooks, emails and journals. However, even when you are able to retain email archives, receive someone’s old notebooks or even digital journals, you are unlikely to be able to find what you need. But with a tightly integrated system, you are better positioned to discover this information.


In general I agree with all this, and I hope someone from the team will elaborate soon and I’ll stop speculating. :grinning_face_with_smiling_eyes: But in the meantime I can imagine that perhaps the level of functionality they have planned for these “meta blocks” is demanding (from a resource/performance perspective at the least), and that this approach (larger blocks) seemed like the best leverage point. I.e. the best place to devote their dev time for maximum impact for the most users. Fine-grained block functions are great, but are they necessary to, as the Fibery team puts it, “generate insight”? I dunno. I suppose that’s exactly what they’re exploring. :slightly_smiling_face:

It also seems reasonable to consider that adding smaller block capabilities over time may be easier than trying to create a Notion-level block editor up front, or at least adding such functions may be an option later. So we may well get there eventually.

As an idea for what that road might look like, I can imagine that eventually these “uber block” functions (react, per-block history, etc.) might perhaps become something you can add to any block, so as to avoid all blocks being “heavy” with functionality and unnecessary data. Maybe in addition (or instead), a Group Blocks function would be added, and Groups would have these “meta” capabilities.

Anyway, it’s interesting to think about how things might work, but some clarity from Michael or others on the team is probably more valuable. :grin:


It was a deliberate decision to not move into low-level blocks. We have a feeling that it will not bring enough benefits, but will take much more time to implement. We are strive for semantics block more, but you can create quite small blocks as well, nothing prevents it (however, there are no levels (yet)).

2021-10-25 10.57.29

I don’t know how well this approach will work in fact, we’ll release something and see how it goes. We’re trying to solve many problems here, most of them caused by our customers feedback, like mix Views and Text, create Dashboards, better commenting and references.

To solve granularity problem, we will make block split easy, so if you discover than some part of a text is a separate thought, you select it and create a new block with a shortcut or a single click.