# Migrate Entity View to Blocks **URL:** \ **Category:** Ideas & Features\ **Tags:** blocks\ **Created:** [September 13, 2021, 8:01am UTC](https://community.fibery.io/t/migrate-entity-view-to-blocks/2005 "2021-09-13T08:01:12Z")\ **Posts on this page:** 1\ **Showing post:** 9
**Author:** ![Oshyan](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/oshyan/32/11431_2.png) [@Oshyan](https://community.fibery.io/u/Oshyan)\ **Post date:** [October 10, 2021, 10:19pm UTC](https://community.fibery.io/t/migrate-entity-view-to-blocks/2005/9 "2021-10-10T22:19:17Z")
> [@rothnic](#): > > - 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? 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. > [@mdubakov](#): > > 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. 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: > [@Coda's Two-way writeups and the functionality to enable them](https://community.fibery.io/t/codas-two-way-writeups-and-the-functionality-to-enable-them/2021): > > I’ve just been reading some interesting Coda articles on some of their work management processes and tools/flows/systems. They use Coda, naturally. One thing they’re big on is interactivity, which Coda documents make fairly easy to do through various embeddable widgets, tables, etc., most of which you can interact with. It strikes me that similar kinds of things will be useful for [the planned future of Fibery as a feedback portal](https://community.fibery.io/t/feedback-management-problems-now-you-can-vote-for-missing-use-cases-here/1735). But I’m interested in looking at the “two-way writeup” as a parti… I suppose it would/could just be another / menu function… > [@a2say](#): > > As for the “RichEdit text” blocks, there is such a thought (since you are moving to the new block model anyway 😇 ) — Add versioning (history) at the block level. 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. 🙂 --- _[View the full topic](https://community.fibery.io/t/migrate-entity-view-to-blocks/2005)._