Loading Trix (and therefore Action Text) asynchronously

Hey there, folks 😄,

Thanks for clicking on this article, I hope you'll enjoy it 🙂.

In this article, we're going to talk about this little WYSIWYG text editor called Trix .

(It's really nice too)

Are you ready? Let's go 😄.

Ruby on Rails?

Yeah, so, you probably haven't missed it, but Trix is very close to the Ruby On Rails universe.

It's possible, I say possible, that I got into it recently, and I'm having a lot of fun. Later, there will be a complete article about RoR.

But for now, during the development of my application, I came across some nice things to share, hence the article you're reading.

Little hint: the new RoR application will be for hairdressers... 😁

How do we use Action Text?

Rails is incredible, let me explain...

To add a rich text editor to a resource (an entity for the Symfony folks among you), it takes three minutes.

We add Action Text to the project

First step, simply add action text with a simple command.

(You're following so far, it's not too hard, right? 😂)

We simply tell Rails we want rich text

Now, you're not ready for this, it's going to be difficult...

No, I'm kidding 😁, it's one line to add to your model.

Whoa, we almost tied our brains in knots there, didn't we? Yeah, me too, such simplicity does something to me...

We update our form

Warning! This is technical, I don't know if you're ready, oh well... still not actually 😂

Yeah, I don't know what to tell you, these guys don't like making things complicated, that's all 😁.

The form is ready

Well then, coffee? 😁

The cost of simplicity

Well yes... obviously.

In life, nothing is free and if on our side it's super nice (honestly it killed me laughing when I saw how simple it is...), on the other side there's a hidden cost.

A large JavaScript library to load at page load

That's the problem, Trix is very complete and very good but, obviously it's heavy to load

In my application, by default it's 512kb to load additionally at the initial application load (when a person arrives for the first time).

On a poor 4G connection, that's not acceptable...

Shall we reduce this cost?

The idea is simple, we don't need Trix all the time, we just need it when a form with "Rich text" is displayed on screen

So why load it at initial load? We might as well wait for when it's needed

Updating the importmap

On Rails (and Symfony too with Asset Mapper), we no longer use "JavaScript builder", it simplifies the application and that's not a bad thing.

In the case of Rails, we'll update our importmap.rb file.

By default, a Rails application preloads everything in the importmap, the idea here is simply to set "preload" to false to tell Rails we don't want to preload Trix and Action Text.

And in my example, you can see that I don't preload my Stimulus controllers either.

If we look at the page's generated source code, we can see all our lines in the import map tag, but below, we see that they're not all preloaded, only the essentials.

And by the way, in the preloaded modules, we see something: turbo-helper, I wonder what that could be.

Loading Trix at the right time, shall we help Turbo?

Ahhh! The return of Turbo-helper, the last time I used it was on Vélo en France.

The idea of this little file is to assist Turbo, for example to close "modals" or alerts before Turbo's caching.

When we come back to a page, Turbo re-displays what it has in cache before fetching the HTML from the server, well, that's not quite true anymore, because now, on all "get" requests, it will do a prefetch, which means if your application uses "get" to modify data (not good! Okay, I admit I do it on the site you're currently on, but let's not talk about it!). In that case, Turbo's prefetch will completely break your data modifications.

Here, we'll simply use Turbo-helper to accompany the content change when Turbo pushes new content to the DOM.

If we detect Trix in this content, then we load it!

And there you go!

Little bonus: Preventing cumulative layout shift

That's right! While Trix is loading, our "textarea" is smaller, so at some point, the page will jump, which doesn't look nice aesthetically...

To fix this little problem, just set a minimum height to the div that surrounds our textarea, with Tailwind, it's "min-h-[150px]"

And voilà! No more jumping!

Conclusion

This was the first article (before many others I think), about Ruby on Rails!

We stay in the same universe as Symfony in many aspects, by the way, Symfony is not unrelated to my interest in Rails.

Symfony-UX's front-end... is actually Rails'! Just like home!

I wish you a great day and see you next time 😁.