ActionText is a new feature developed in Rails 6 that aims to solve managing rich text content on apps on an easy way following conventions. At first sight, this may seem like a trivial and insignificant feature, but you will see that inside of it you have some exciting things that may do your coding easier.
The purpose of this post is to introduce this new feature, explaining the specific case it was build for and the provide a personal opinion about the potential of it.
“Action Text brings rich text content and editing to Rails. It includes the Trix editor that handles everything from formatting to links to quotes to lists to embedded images and galleries. The rich text content generated by the Trix editor is saved in its own RichText model that’s associated with any existing Active Record model in the application. Any embedded images (or other attachments) are automatically stored using Active Storage and associated with the included RichText model.” 
But… what actually is this all about?
The most straightforward implementation (and what it was first build for) is to manage content on web apps as you are used in word :
This may seem trivial at first sight, but trust me you will have a lot of headaches with the many cases you should consider and the time it will consume. With ActionText you will just spend 10 minutes.
How do I implement it?
You need image_processing to deal with blobs automatically, this is another amazing thing provided here!. After running bundle this will generate 3 new tables: action_text_rich_texts, active_storage_attachments, active_storage_blobs.
After running migrations this will just generate a string column on your model, but don’t worry, it will use the previous tables too.
And that’s it, you have an app capable of storing chat messages, posts, images and any other rich text implementation you want with just a few lines.
And… what happens if I’m just a backend developer?
You will tend to think that there is just value in
has_rich_text :content, because if you actually try to expose the content param your Front-end developer will have to generate something like :
The solution provided up to now to solve this is to make your API accept attachments markup in canonicalized form (e.g.
<action-text-attachment sgid="…"></action-text-attachment>) instead of the full Trix-compatible markup (like above). To achieve this you would need Basecamp Doc
This is a handy feature if you are building a full-stack Rails app, and for API development you would need to ask your Front-end developer to provide some specific information, anyway, it seems extremely useful as you are dealing with all content types automatically then.
Last but not less important, this is a feature under development yet so there will be some changes and improvements in the near future.