I like to suggest the creation of a new field of type ‘Code’
Reason:
Using a rich text document field always requires to include manually (or automatic) insertion of a code block (backticks) to store code. This is overcomplication when working with automations and workflows that handle code and not rich text.
A dedicated ‘Code’ field offers:
- Clear, direct programmatic access to raw code, unlike the need to parse formatted text in rich text.
- Structured storage of code language, enabling language-aware features absent in generic rich text.
- Consistent, enforced formatting and display, unlike the variable nature of code in rich text.
- A more familiar and efficient environment for developers, compared to basic rich text editing.
- Cleaner data for automations and AI, avoiding the noise of rich text formatting.
- Potentially built-in code-specific features like validation, which rich text lacks.
- More precise searching and filtering of code content, unlike searching plain text within rich text.
- A semantically correct data type for code, allowing the system to understand and treat it appropriately, unlike rich text.
In essence, a ‘Code’ field treats code as a distinct, structured data type, optimizing it for programmatic use and developer experience in ways that a general-purpose rich text field cannot, even when only code is stored within it.
1 Like
Okay, here are a few projects I’m actually working on.
AI Workflows and AI Agents: I use AI agents in fibery to scan collaborator comments and reviews and automatically create tasks for content updates.
Why Code Field: storing code (e.g. scripts) for the AI agents to analyze and do tasks. It would keeps code clean and runnable, so it would better support AI script generation.
Why not Rich Text : rich text formatting (backticks) makes code extraction messy. also, some workflow work with different languages, so language info would be very helpful.
Automating Internal Workflows: I store Javascript snippets in entities to help developers standardize data-sharing protocols across teams.
Why Code Field: for keeping scripts in entities. same reason.
Why not Rich Text: Varying rich text formatting complicates code extraction, and no language support lacks the readability of code snippets.
So in short:
A Code field allows for structured, programmatically accessible code with language metadata, with reliable execution, validation, and automation, which rich text with backtick code blocks cannot achieve because of lots of parsing errors and lack of metadata.
I have a number of other cases where I ran into issues with the rich text field and code in that not properly extracted in automations, but I guess other users may chime in with their experiences..
As I understand, you want to store code that you can execute in Fibery automation/button? Is it correct?
That would be great but I understand executing a script using code from an entity is (currently) not possible because of security issues.
What I mean is that in workflows, either code or text >>when exact data<< is needed, a code block would be used for that.
The problem with rich text fields, is that it does not store exact data but it includes all kind of other stuff like backticks, embedded formatting, hidden json data etc. All that a an automation or script needs to clean up to work with the data.