cjilbert504

Hey Carl - That's a great idea! Thank you

Hey Muhammad,
Sorry that you feel the video is lengthy. At the moment, I do not plan to do a written version and I also don't know that it would be fair to folks that learn better from video to do such a quick video.

Thanks! Glad that you enjoyed it!

Glad to hear that you enjoyed the video! Yeah, I wanted to stay more focused on the overall theme of building utilities so I didn't dive into the regex much, also because it is specific somewhat to my machine. Maybe we could do a little series or a something on Regular Expressions in the future. :)

Thanks! And thanks also for letting us know that you would enjoy more around these topics!

Thank you for the kind words and the feedback! To follow up, initially, the "task_field" endpoint does not automatically return a turbo-stream. In the second implementation when we use the RequestJS package to set a { responseKind: "turbo-stream" } on the request that the Stimulus controller makes, that's what triggers the endpoint to respond with a turbo-stream. Then when we remove the Stimulus controller and solely use Turbo, we set a data: { turbo_stream: true } on the link_to helper, that will also cause the endpoint to respond with a turbo-stream. Although the endpoint is empty during these two implementations, by default if a request comes in that wants a turbo-stream the endpoint can either list out how to respond to a turbo-stream request in the action or by convention look for a matching named turbo-stream view i.e. "app/views/projects/task_field.turbo-stream.erb". This is much like the convention of how a given action, let's say an index action of a Post controller, would look for a view at "app/views/posts/index.html.erb" by default unless instructed otherwise.
Hope this helps clarify that for you!

Thanks for taking the time to provide this feedback. The remaining videos that I have coming out for this year are already recorded but going forward I will be sure to keep this in mind and try to provide an opening overview in the videos. I appreciate the feedback!

Thanks, James! Yeah, progressive enhancement is a good description of it. A bit of a refactoring too as we were able to drop the stimulus controller completely. Happy to hear that you enjoyed the video! Thanks for watching.

Thanks, Matt! I'm glad that you enjoyed this video.

Hey Terry!

Thank you so much for the kind words. I'm glad that you enjoyed the video. I think part 2 will be out next week so hopefully, you enjoy that one as well if you watch it. I definitely agree with you on the core concepts aspect. That was a big motivator for this video.

Hope all is well!

Thanks all for contributing to the conversation! I've added a link to a blog post in the episode notes about this topic and included some things around validating uniqueness.

I'll share what I did today to solve for this, which is really close to what Ryan did. The model, among other attributes, has a title and a rich text description like so:

has_rich_text :description

I wanted to be able to search across both attributes. I had the title one worked out already but to get the rich text description into the mix I then added the following line:

has_one :description, class_name: 'ActionText::RichText', as: :record

Which then allowed me to do this in the form:

f.text_field :title_or_description_body_cont

Hope this adds to the help that was already here and thanks to the other folks who contributed to this thread!!

Now wait a second why didn't you have to use the gem build and gem install commands before including the gem in the gemfile??

So the confusion that I have around all this is where is the link between before_action :set_project and def set_project? Like how does it know that the symbol :set_project is referring to the method set_project defined elsewhere?