Chris Oliver

Exactly, you can just replace that with however you find the current user normally. 👍

That turned out nice and simple! :) I hadn't actually customized it to be username/pw but that looks pretty much exactly like what I imagined you'd have to do. Nice and simple, thanks for sharing your solution. 👍

Hey Naveen,

In this case, it looks like you created a select without a matching form tag. The CSRF token actually gets generated by the form_tag and form_for helpers so if you just wrap your select with form_tag, you'll be fine. You can then move your URL, method, and remote options to the form_tag and have that all organized nicely and that should fix your issue.

The problem you saw was that, while you can try to put the remote: true options on a select tag directly, it isn't going to generate the CSRF token to send along with.

This is exactly what the counter_cache option does inside ActiveRecord, it's just hidden away. You get the performance benefit from querying, with the slight tradeoff of inserting/destroying records taking 1ms or so more. That's totally fine because most applications are much more read heavy than write heavy.

As for the conditional counter caching, you're right, nothing in Rails to do that. You could probably turn that into a concern that could be reusable that accepts a proc you call to replace the `if user` portion so it could be reused and customizable in any fashion. Might even make for a nice little gem!

Another tweak you could do with that is actually do the COALESCE like you mentioned, but like Rails does, ignore the count and actually just add 1 or subtract 1 from the current value. This way you don't have to also query for the total count which would speed up your implementation slightly. It does assume the value is accurate, which is totally fine since like we saw in the episode that you can just set that when you add the new column. This way you're making a micro update to just increment or decrement the counter column rather than doing that plus selecting the count. Adding or subtracting 1 each time should only ever take a millisecond or less while the count might take several.

This was a great question!

Haha! It just might be. :) Someone was also asking about counter caches in Slack so it seems like perfect timing!

Just coffeescript because they removed curly braces. They use tabbing to denote which block it is a part of instead (like Python).

Hmm, not sure. It looks correct assuming each of those lines is tabbed over properly

$(document).on "turbolinks:load", ->
  $("#new_message").on "keypress", (e) ->
    console.log e.keyCode

You can add your own ID or class to any element you have in your form and change that query to match. I just use that because it's auto-generated and easy to use, so you can use the autogenerated one for your form, or specify your own and that should do the trick. 👍

Sounds like a good pull request for someone to submit to the repo if they have time! *hint hint*

Masud, I think you'll have to benchmark your app and monitor memory usage and things to find out what it's actually using and if it's going to surpass your limits. There's no real way to tell ahead of time, but you can also try deploying the change and making it easy to roll back in case you do surpass your limits.

If it does look like it's going to be way too much, you can always try using http://anycable.io/ which can handle 20,000 idle ActionCable connections within 1GB of memory.

There's only 1 websocket open and you can use as many channels as you want to separate messages out across that websocket. Check out the browser's websocket messages as they come across and you'll see how it groups them into the different channels. ActionCable just handles the filtering for you so you don't have to.

I would recommend either will_paginate or Kaminari. Both work really well and only have minor API differences between the two. They both have over 13M downloads too, so they're similarly popular and I wouldn't really say one is better than the other. If you use something like Administrate or something that already depends upon one, then I'd say to just use that for your app as well.

I'll be making a video how to add the pages into the JSON api spec so you can see how that's done.

Awesome to hear! Appreciate the updates notes and I should definitely do a screencast on this as well. :D

Thanks Chris! I'm going to try updating the tutorial this weekend using your notes. It's been a while since I've updated this. 🤘

There's a bunch of great options like this. Cool thing about Pretender is that it can work with anything, but the nice part of devise_masquerade is it handles all the controllers and routes for you.

Hah! Yeah, it's a fantastic improvement to keep things consistent. One protip I'd recommend is actually studying how Rails generates scaffolds and you can cherry pick ideas from what that generates to use in your own code.

Because this controller is used to manage who is actually subscribed to a chatroom, we always include the chatroom ID in the URL. Then we just look up the chatroom and permanently add or remove the join table records to denote who is in the room or not. So yes, basically what you were saying. It's auto-scoping the actions its taking by the chatroom ID in the URL.

https://github.com/gorails-...

Ah yeah, that's what I figured. I'll consider it, one of the reason I haven't is that I didn't want any JS to be required. You could easily just make a route for each of those and them add your own buttons to each of the views and turbolinks would make navigating between those pretty snappy.

It does probably make sense to add day and year views to the calendar and leave it up to you to link them up on the page.

It's the resource for the current page that you're viewing inside Administrate. Just their naming convention since the admin is generic for any models you may have.

Um possibly. I just made a tiny tweak today that improved performance by like 4x or something. Thought that might be useful to talk about, but I think I've covered memoization before.

What do you mean by "view for possible listing"? And if you want to do two models, you could combine the query results into what you pass in for the events array and as long as they have the "start_time" interface, it doesn't care what type of objects they are.