Chris Oliver

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.

They serve similar but different purposes, but I did talk a little bit about that here: https://gorails.com/episode...

The way I embed youtube videos on GoRails is that I have an Episode model with a column for youtube_id and when you click on an episode I embed it like the following (no need to use their API which is great):

<iframe src='https://www.youtube.com/embed/<%= @episode.youtube_id %>?rel=0&autoplay=<%= params[:autoplay] || 0 %>' frameborder='0' allowfullscreen></iframe>

Check out this week's episode where I talk a little bit about this for authentication. For the individual role authorization, you'll encode the roles of the user into the JWT payload and send that over to the client when they auth. Then you can simply base64 decode the payload of the JWT in Javascript. (See https://developer.mozilla.o... This will give you the roles on the client that you can pass to your JS to hide/show certain links. This way you can know the roles client side to determine what to display and server side you can use cancan/pundit to do the real authorization for the actions the user would take.

Anything client side is just going to be for displaying the UI and therefore should never be trusted so the server will still need to implement authorization as you normally would.