Chris Oliver

@Frank Underwood, check out our GoRails Learning Path for a structured way of learning Rails. We designed it with repetition in mind so concepts sink in as you build several different projects.

Nope. I haven't used that gem in probably 10+ years.

See my last comment on how to disable that class with the deprecated config.

Seems like it is config.form_class even though it's deprecated.

It appears to be using both the new and deprecated options:
https://github.com/heartcombo/simple_form/blob/c2c7faf3e532072e1ef511a97d677ae0e7c38957/lib/simple_form/action_view_extensions/form_helper.rb#L20-L23

https://github.com/heartcombo/simple_form/blob/c2c7faf3e532072e1ef511a97d677ae0e7c38957/lib/simple_form.rb#L116-L124

Try setting it to an empty string instead.

Looks like this may be the config option for it: https://github.com/search?q=repo%3Aheartcombo%2Fsimple_form%20default_form_class&type=code

Not yet, but I imagine it'll be around Rails World 2025.

Who else is excited for the new rich text editor that Jorge's been working on?

What use cases have you used Enumerable for?

Send us a support message.

Have you used lazy load hooks to extend a gem with some interesting features?

Alexandre, that's not needed for this. For example, your Rails app can load SQLite, then Rails itself will load the database config and ensure that SQLite gem is required as a double check.

Using require: false would just move the loading of SQLite from boot and instead load SQLite when Rails requires it. It's not going to give you a benefit in your application because it will be required either way.

This is more for libraries that have optional dependencies. This way Rails doesn't have to add SQLite as a dependency for everyone, it can optionally require the gem later on.

Love solving problems like this with pure CSS and no JavaScript. 👌

Not your computer. It is probably with propshaft

Hmm, it might be a bug in something but it's hard to say. That change should not affect any performance.

Try restarting your server.

@1klap, no it is a separate, dedicated course since it's so in-depth.

Hey Allan,

Can you cache the calculation results to the database? That would make retrieving and filtering faster since you wouldn't have to re-calculate every time (which I assume is the slow part?).

In case you're interested, you can sign up for our Learn Hotwire course here. We're covering Hotwire with Rails and Native with iOS and Android, diving deep into the details more than any other course out there.

"from Async" means your background jobs are being processed by the default "async" adapter.

You'll want to change the ActiveJob queue adapter to Solid Queue or Sidekiq and you'll see the following:

[ActiveJob] [Turbo::Streams::BroadcastStreamJob] [e6bee483-4ebb-439e-a6df-69959947506a] Performed Turbo::Streams::BroadcastStreamJob (Job ID: e6bee483-4ebb-439e-a6df-69959947506a) from SolidQueue(default) in 37.44ms

That's awesome. Curious to hear what change(s) made the biggest difference. That's a huge improvement.