Marc Köhlbrugge

Hi Chris, looks like the RSS link no longer works. Any chance you could add a new one? I often find myself (pleasantly) surprised to see new episodes on the site. Would be nice if we could discover these through our RSS readers as well.

Hi Chris,

I was searching for the Tailwind + Rails 6 video today, but searching for "Tailwind" did not return it:
https://gorails.com/search?q=tailwind

I eventually did find the episode here:
https://gorails.com/episodes/tailwindcss-1-0-with-rails-6

I think it didn't get included in the search results because the title uses "TailwindCSS" without a space. I imagine your search function looks for whole words only.

Found this! https://github.com/rails/rails/issues/35218#issuecomment-617001327

Let's hope Rails 6.1 will add this.

Hi Chris, I saw your PR related to to_trix_content_attachment_partial_path so I figured you might know this:

Is it possible to specify a partial path for an attachable, without overriding to_partial_path?

I have @mentions implemented in my application just like you show in this video. I use render @user all over the place but that users/_user.html.erb partial is very different from what I'd like the @mentions to look. So I want to specify a different partial path for rendering users within an Action Text.

I could replace my existing render @user specifying a different partial, but that just seems a like hack. I imagine there must be a to_action_text_partial_path-like method somewhere, but I haven't found any yet.

Have a look at this video: https://gorails.com/episodes/notifications-action-text-user-mentions

It shows how to extract the all the mentioned users within an action text to notify them via email. You could do something similar for your tasks. Except in your case it will be tasks instead of users, and instead of sending emails, you create a list of tasks.

For anyone implementing infinite scrolling behavior, I recommend checking out the method used by https://infinite-scroll.com

Instead of using JSON it uses regular HTML pages like you're already used to. No need to modify the controller or create a separate view template. Instead, they fetch the full http://localhost:3000/?page=2 (or whatever), but only use the content inside <div data-target="infinite-scroll.entries"> and append that to the existing div.

I thought it was a clever approach that feels very familiar as it reminds me of Turbolinks. There's very little setup and easy to maintain. With proper caching any performance hit is likely negligible.

I can see the strategy being used with only a slight modification of the code presented in the video.

Thanks. Would love to see an episode on that, as I think most people aren't used to doing Docker Deploys on Heroku.

There are probably ways to do it, but I'd be prefer my CI setup to be self contained. For example I'm using Codeship right now which runs the tests, deploys to Heroku, runs migrations, and checks whether the site is still up.

I'm sure the same is possible with GitHub Actions, but I'm not just not sure how to push to the Heroku git repository from within GitHub.

I guess part of Continuous Integration is pushing the chanegs to production once the tests succeed.

Any suggestions on how to push to Heroku from within GitHub actions?

It's of course possible to configure this in Heroku, but I'm curious how to this from GitHub as it would allow you to then also run commands like database migrations after deployment.

Congrats on the 300th episode! 🎉

Jumpstart Pro looks great!

Has anyone tried saving a reference to to the Photo record within the post.body, rather than the URL itself?

I think that's how Action Text does it when using Active Storage. They include the Global ID ( gid://app/Photo/123 ) instead of the URL of the image itself. Then, when the post.body gets rendered you're free to display it anyway you want.

Unless I'm overlooking something, it seems like you have some duplicate code in the video:

def comments
  Comment.where(commentable: commentable, parent_id: id)
end

def child_comments
  Comment.where(parent: self)
end

While they use slightly different where's the end result will be the same. The commentable: commentable condition is unnecessary, as there should never exist a comment that has a different commentable than its parent.

There's a security vulnerability in the code which allows any authenticated user to delete anyone else's comment. While there's a check in view (if comment.user == current_user) for showing the deletion link, there's no such check when actually destroying the comment.

Relevant code from comments_controller.rb:

def destroy
    @comment = @commentable.comments.find(params[:id])
    @comment.destroy
    redirect_to @commentable
  end

There are a number of different ways to fix the security vulnerability. Here's one example:

def destroy
    @comment = @commentable.comments.where(user: current_user).find(params[:id])
    @comment.destroy
    redirect_to @commentable
  end

If you're planning to also add editing/updating of comments, you might want to turn this into a reusable helper method like so:

def destroy
    user_comment.destroy
    redirect_to @commentable
end

private

def user_comment
  @user_comment =|| @commentable.comments.where(user: current_user).find(params[:id])
end

Rather than passing in commentable and parent_id locals to the comments/form partial I tend to build the new Comment object, and pass that through instead. Like this:

<%= render partial: "comments/form", locals: { comment: Comment.new(commentable: @post, parent_id: comment.id) } %>

This way the commentable and parent_id values are always shown in their context (a Comment object), rather than randomly floating around in your views.

I'm curious what you think of this approach, as it doesn't just apply to this particular video but Rails views in general, specifically forms.

I don't know much about how Rails templating works under the hood to say whether this has any impact on performance, etc.

I watched the episode, but the Global ID stuff all happens behind the scenes. I figured it would be interesting to take a closer look at how it works so we can implement something similar in situations where ActionText is overkill.

After watching the recent screencast on Action Text and @mentions, I became curious as to how Rails stores references to these associations in texts. Turns out it uses something called Global ID:

https://github.com/rails/globalid

This might be an interesting topic for a future screencast.

Let's say you're building a Twitter-like app and want to support @mentions in the tweets. However, unlike Twitter you actually want the mentions to remain working after a mentioned user changes their username. We don't need the full rich text feature set, but similarly to Action Text we would store the actual user ID (or more specifically the Global ID) and render out the correct username whenever the tweet is shown.

We could create an additional Mention record as well, so we have an easy way to query in which tweets a particular user was mentioned

What do you think? I think the current @mentions screencasts are nice, but rather restricted in real-world applicability. I've been looking for a good approach and Global ID seems like the way to go.