Block inputs and outputs

This is obviously related to the [IN DEV] Migrate Entity View to Blocks but thought it might be worth it to keep it separate.

One of the things that I hope would be baked into the foundation of the blocks is ability to define inputs and outputs into a block. I assume the block types in the first iteration would be very basic and probably static (text, bullets, views with hardcoded filters, etc.) . However, in the long run, I would hope that we will have more dynamic blocks available (perhaps some contributed by the community) that would be able to accept certain parameters as input and as needed expose outputs that other blocks could use.

My reference here is mathcad which allowed you to insert components such as excel worksheets inside your calculation books (old mathcad 15 workflow and mathcad prime workflow). This proved very useful in many instances as excel was much better at doing some tabular calculations and presenting some forms of data. But the key to making it work was your ability to make things dynamic and were able to use results of excel’s work in the rest of the document. Other code/calculation platforms like also seem to use a somewhat similar paradigm.

I know the above is a very niche/technical use that is well outside of fibery’s scope. But I think this is still useful for inline formula/calculation blocks, code blocks (Innos’ playground blocks come to mind) or simple tables with dynamic content. I know figuring out how to expose this to users in an intuitive way is a challenge and nothing that the team would focus on in the near term, but I hope at least the foundation is built in so that it can be made available in the future.

Interesting idea! I know that Michael said doing in-line calculations/variables should not be too hard, and they would consider it. I am curious if you can provide a more typical-Fibery example use case for the functionality you’re describing.

What came first to my mind, though it may not be an example of what you had in mind (and may not be that useful, or the best way to handle it), is a “CSV Import” block, which basically shows a spreadsheet-like view of a specified CSV in-line on the page, and then allows you to directly reference those values elsewhere. This is advantageous over the much heavier current approach of importing CSV data into some Type (or creating a Type for it), and could help address some of the various requests around here for more ad-hoc data handling. It’s a half-formed idea, but I’m curious if this maps at all to what you were contemplating. And certainly I’m interested in other examples if you have any.

1 Like

This sounds like it might be a good way to create an entity (a view??) that always shows the “last four Meeting notes for client X”.

E.g., a RichText containing four Blocks, and each block “imports” its content from a recent Meeting Notes entity’s Description field (i.e. RichText). When a new Meeting Notes entity is created, our “import” blocks would shift what they display, because they are defined to always reference the most-recently-created four entities. (Sounds like a potential headache when I say it that way - e.g. does it update even if you’re in the middle of interacting with it??)

Ideally you even could have the possibility of editing the “imported” content in-place, which would update the real source as well.


This is actually one of the things that I was thinking about :grin: I think there are quite a few situation where you want to just explore a set of data and do some basic manipulation without building a full app/workflow. You usually end up doing that somewhere else and copy-pasting results or screenshots but lose your context.

I was also thinking of a lightweight spreadsheet/table that can be used to do some basic calculations. (leveraging existing formula engine). An example would be putting together an estimate for a project in a meeting note or document for a proposal. I would normally do that in excel and copy-paste into rich text area, but unless I keep the file, I can’t update it anymore. I think building full types and formula fields would be overkill in many cases. The ability to output information would then allow you to reference the proposal total elsewhere in the document and even fold the calculation table so you are not revealing the details. This approach combined with inline inputs (like would really make for really dynamic internal documents on fibery.

Another example would be a block to generate dynamic drawings or diagrams (e.g. using excalidraw ). There would be certain inputs that the block would need to generate the drawing while no explicit outputs are necessary as the image is the final output.

I think one of the advantages of input/output approach is that you have better control over data context (don’t have to worry about overwriting a value or variable elsewhere) and can change inputs without having to update all of the formulas and logic within the block. This also allows sharing and reusing of blocks elsewhere.


As far as I understand the problem, it will be solved in nearest future with View block. You will just include a View block with a specific filter (we might also add TOP X setting into Views) that shows Meeting Notes.


Yes, although Fibery has its own Whiteboards concept, and we do know those will be embeddable, and can already connect (“input/output”…) to the rest of Fibery… But yeah, this and your other example(s) sound promising to me.

Excellent! Hopefully this includes what he described: the full contents of the referenced entities, or at least a field of them (e.g. rich text) This gets close to another request I’ve had, which is a sequential, scrollable view of entities, akin to an old Filemaker Pro feature…

1 Like