Marc Köhlbrugge

Joined

450 Experience
3 Lessons Completed
0 Questions Solved

Activity

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.

Posted in Deleting Comments In Nested Threads Discussion

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.

Posted in Nested Comment Threads in Rails - Part 2 Discussion

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

Posted in Nested Comment Threads in Rails - Part 1 Discussion

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.

Posted in Screencast requests: Global ID and @mentions

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.

Posted in Screencast requests: Global ID and @mentions

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.

logo Created with Sketch.

Ruby on Rails tutorials, guides, and screencasts for web developers learning Ruby, Rails, Javascript, Turbolinks, Stimulus.js, Vue.js, and more. Icons by Icons8

© 2020 GoRails, LLC. All rights reserved.