Chris Oliver

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.

Let us know how the implementation goes!

Ah perfect! :D

And yeah I think that'd make consuming the API a lot easier. I think the only trick then will be making sure you get all your field names right when you submit make over. There is some documentation about how that works but I can't remember where I saw it. Mostly it's just sending over an array for your observations_attributes[] and that should do the trick.

You could optionally also support the id and _destroy fields for the nested observations in case you ever wanted to be able to edit/remove observations from updating a post. That seems probably less likely to be necessary though from an API standpoint though.

I think you should be able to simply do the following instead:

@projects = current_user.projects.find(params[:id])

The trick here is that Rails knows how to do the join and where automatically because the relationship is defined as "has_many through". The has_many means it knows it must join, and through means that it needs to join twice.

Your query should work, but you're basically redefining exactly what Rails is doing internally so you can get rid of the join and where and it should produce the same output. :)

Hey Sean!

What you might consider doing here is accepting nested attibutes on the create Post action in your API. That way they can submit a post and include some preliminary records for observations all together. Those are often super convenient things so that your API users don't have to make two API requests first to posts and then to observations afterwards.

The other thing is I would suggest using nested routes for this as well. Think of these two routes:

resources :posts do
  resources :observations
end

resources :observations

In the top section that's nested, you can get observations attached to a specific post really easily by asking for the /api/v1/posts/1/observations url. As someone using your API, I know at a glance that it would give me only observations for that specific post.

You might also want to offer the ability to operate across ALL observations, not necessarily ones for a specific post. In that case, the second resources route that isn't nested can be very useful. This might be for doing more bulk requests, updates, etc that could apply to all posts. It provides advantages for different use cases and it's totally fine to include both of those routes/controllers for the some model (and often encouraged) so you can provide an elegant set of URLs that encapsulate the intent in the design of the url itself.

Hey Josh, looks like I forgot to put the video in the series. You can find the episode here: https://gorails.com/episode...

Primarily because if you're already using a frontend framework you'll want to keep all the Javascript contained within the component. If you use the JS responses from UJS requests, you're not splitting your JS across two things (the component code and the rails response) and it's no longer self contained. The component should be the one changing state to keep it organized.

You can still do that if you want to, I just wouldn't recommend it because you might as well just use UJS only and no frontend framework then.

Logout is as simple as deleting the token from localStorage and the Vue state. Ideally, you'll want expirations on your tokens ideally so that they can be invalidated after a time. This is the same thing that Rails session cookies do for logout as well so it's nice and similar.