News in the Rails world. DHH just announced that the Rails team is working towards bringing Trix, the rich text editor from Basecamp, into Rails applications by default as Action Text.
In a video, he showed quickly how to get started with Action Text by building a blog with a rich text area. This shows off some other things coming to Rails 6, like the default use of webpacker. Action Text hooks closely into Active Storage which was only new in Rails 5.2. Take a look at the video and see what you think:
Is this something you're excited to see in Rails? Have you had a need for rich text and struggled to use something that works well? Will this get you to install the edge version of Rails to try it out?
What do you think?
Top comments (23)
My initial gut reaction: Is this really a responsibility a web framework should have? It's a super opinionated frontend concern.
On the other hand, you could remove it after the fact, and the kind of Rails apps you'd be spinning up quickly would likely be internal apps and the such. The canonical "simple crud app". I feel like in this context it's logical to adopt Rails' opinionated nature and run with it.
In the demo when he drags and drops an image into the editor, active storage gets going on the back end uploading and storing the image and creating previews. Looking at it that way it seems that the front end and back ends are heavily tied together.
Rails is very opinionated, it's what so many people like about it. It's also configurable, I'm sure there'll be a
rails newwhen it's realeased.
What do you think of Trix too, Ben? I believe you've been working on a new editor for DEV, did you/would you consider something like Trix/Action Text?
While I do love Rails this feels a bit like when Microsoft ships IE/Edge with every OS and makes it hard to switch. There are many people working on great rich text editor and I'm not sold on the value on shipping this by default in Rails 6.
Maybe I'm missing something but the part of Rails I loved where the abstractions where you could pick your DB, pick your storage, pick your cache, etc. This seems quite different in that regard.
I played around with Trix when it first came out and like it. The new editor will also be markdown, but if we offer a WYSIWYG in the future, we'll definitely look at it as an option.
Potentially would use it sooner for admin tools.
The video doesn't do a great job of explaining everything that's going on. It's a bit more than just bundling Trix into Rails core. It seems like it's doing a lot of processing of the content fed into it.
I've done quite a lot of custom CMS work with Rails and it's interesting to see their approach. It's not too far off from stuff I've done before, which I'll take as validation :)
There is some Trix specific code for attachments, but I don't see why you couldn't swap in some of your own handlers if you wanted. Just a few months ago I wrote some JS plugins to hook CKEditor5 file uploads to ActiveStorage, along with a hacky Nokogiri parser to associate the attachments. I would have loved to be able to just hook into something like this.
A vast majority of web apps deal with rich content in some fashion. In that light, I think having a framework for storing/parsing/etc with it is quite justifiable, especially at the stage Rails is at. That it comes with a default UI that handles many use cases is really just icing.
I have similar feelings. Isn't this out of the scope to include in a framework? Like Phil and you mention though, it will probably be configurable enough to be configured out of an app easily.
I tend to agree. I was setting up a new Rails 5 app recently in a very specific way and felt like it took a while just to turn off all the stuff I didn't want in there. While I dug CoffeeScript a few years ago, I'm more inclined to do ES7 nowdays, and I don't want to use minitest, and I don't want to dev on Sqllite, and don't even get me started on Webpack... Maybe because I don't necc. build projects in "The Rails Way", which could be my own flaw.
Wasn't that the whole point of Rails "templates"? Wouldn't it make more sense to just point people toward a "kitchen-sink" template and have it do all the things - versus having a bunch of things you don't need in there by default? Or, add a slim version to rails new. I was happy to see --api, maybe there should now be a --slim without all the extras?
I'd also question whether this is a "good thing" for a new rails user. In the beginning, it was very simple, things made sense, and it was fairly compact (compared to, say, a default .NET web project). Now even as a long time rails user, it seems WAY more complex than it needs to be.
It's kind of a ridiculous thing for rails to include. It seems very very specific.
I've used both ActiveStorage and trix. From what I've seen, both are great separately. I haven't used them together yet. This seems like a natural default to me.
When you start a new Rails app, many of these tools are configurable. You can choose to get setup with webpacker (and Stimulus, React, Vue, etc.) or not. ActiveStorage is the same. You can choose to turn it off. My guess is trix will be the same way. I like this way of doing things. Provide a nice set of defaults for people wanting to build web apps and easy ways to disable or change those defaults.
trix is a great editor. It's one of the best I've used. I like the default and you can (hopefully) choose not to use it if you have something else in mind.
The bare minimum a front-end needs to satisfy user demands are forms, buttons, and inputs. This is just a specialized and decorated input, and I see little problem with providing it using the same logic that I have little problem with providing front-end decorators to aid form validation.
Hi Michael, would be very interested to hear if you've managed to get action text working with Shrine, especially to display images in-line in rich text. If so, would be interested to hear your thoughts / how you did it.
I have to think the people focused on
ActiveStoragefeatures aren't being bottlenecked by work like this. I that the feature is questionable but I can't imagine it was a huge burden on the rest of Rails' productivity.
It's a great addition to Rails. I'm really pleased they've added this. I'm surprised there's so much hostility. Just turn it off if you don't want to use it. Simple.
Hey Phil, thanks for bringing this up on dev.to! I came across your post before I even saw the announcement from DHH. One of our devs linked to your post/discussion from our company blog on a writeup about Action Text for Rails 6.
For any newbies like me who never ran Rails from the source I created a step by step guide to reproduce the DHH example of the video
I've stopped using Rails just before version 5 (nothing personal, just switched to different projects),so I might not know about the latest development (I followed release notes from 5 and 5.1), but adding a text editor by default feels more like a feature of a CMS, not a framework.
ok cool. appreciate the message.
I"ll have to rip out the good bits of action text in terms of its parsing capabilities and handle the storage myself. seems like a tall order!