Chris Oliver

Hmm, I'm not sure Yelp would be a great one to showcase React because really the site doesn't have that much interactivity so you wouldn't really need any frontend frameworks for it.

Something like Facebook on the otherhand has a lot of interactive widgets where it would make sense. Each post has its own dropdown menus, every chat box is independent, all kinds of various little pieces of state for each section of the site. Facebook may be too overused as an example, but I'm trying to think of something in line with that.

I guess now that I'm writing this, of course Facebook is the obvious choice because they invented it. Hah.

Absolutely. I think the main thing I need to figure out is what's a good, somewhat small real world app I can do as an example. It's always hard to come up with something that isn't contrived feeling.

Hit me with your ideas!

Computers eh? :)

First, I'd check to make sure your cable.yml defines using redis in development so that it can be shared between processes. Second, if you run redis-cli you can say subscribe notifications:4 to have the redis cli show you the messages coming across there as well.

If you send a message on the channel, then it should show up in the redis cli. If it doesn't, you've narrowed it down to probably a configuration problem there and can debug why the message doesn't make it to redis. If it does, then you'll want to debug the client side to figure out why things aren't getting relayed to the websocket as you're expecting.

It would probably be helpful to watch those because they setup the foundation for this which is kind of like a chatroom restricted to just two people. Lots of different ways you can go about it, but this is just one approach that works nicely to reuse the features of group chat.

Hey Ariff,

Haven't recorded that yet, it kinda slipped my mind. Let me get on that this week!

Lots more Vue coming, I really really enjoy using it on the frontend. It feels refreshing to work with for once.

I'm generally pretty torn on the two. Rspec is great because there are so many examples out there, but I really really dislike the DSL it adds because it obfuscates a lot. Minitest is great because it's just plain Ruby where you can refactor all your work like you regularly would.

I guess generally that leads me to suggest Rspec if you're new and Minitest if you're good at Ruby.

@Nick, I feel the same way about TDD. It doesn't add much for me which is why I generally just add tests as I need rather than doing full blown TDD.

For now, I'm just using Uservoice for this, but it isn't the best and is just in the Feedback link in the footer (https://gorails.uservoice.com/forums/259979-general). I'm definitely planning on improving this and making it part of the site in the near future.

I love the idea of showing what episodes I'll be recording for the future couple of weeks. That would be really handy I'm sure.

Jacob is exactly right. :D

And just a quick note: generally you use these url params to do filtering (like pagination) or sorting or you'd use them to turn on and off simple features like autoplaying of videos like you see on here.

Then sometimes it's nicer to have a full path dedicated to a section to designate it's importance so I'll tend to do that for things like forum categories. Rather than just saying /forum?category=rails I've got /forum/category/databases to kind of denote that it's a dedicated page.

It's late so I don't know if I'm explaining that bit well, so here's a stack overflow post that describes the same thing: http://webmasters.stackexchange.com/a/15394

Awesome! Also hadn't heard of this library before, it looks slick!

The JWT gem we use verifies the signature every time you call decode on it, so every token is verified, as well as the expirations and other features it supports. It's fine to have multiple tokens per user (one for each device for example) but because things can change you want to use expirations so they can get a more recent version of the token. There's no need to store anything server-side in the db because this is designed to be stateless.

Does that make more sense?

AMS doesn't care about your URLs, it just takes models and turns them into JSON. You can use any routes you want. Ideally for JSON:API spec, you'll want some restful routes for the objects, but it's also fine to have routes like you mentioned for ease of use. I think of routes for concepts often, it doesn't have to be specifically for a model. For example, your routes make sense because they offer up clear endpoints for different concepts for each one.

Haha crap, bad edit!

Interestingly, there isn't a stop_stream method in ActionCable, so you'd have to stop all streams at least right now. Someone has opened a PR with this but it's still pending: https://github.com/rails/ra...

For now, I guess you can either stop_all_streams and reconnect to the ones you want, or you can monkey patch in the code from that pull request. I would probably do that because it's likely to get accepted.

And to implement the disconnect, you'd just send the message from the JS to call a method in the server side channel to call the stop stream. This would look almost exactly like sending a message, you'd just pass in the name of the channel you want to remove.

Yeah, data-confirm is just a generic attribute you can use on any clickable item, not just delete links. That should work fine.

Turns out it doesn't have access to the session, so you can't use that. http://edgeguides.rubyonrails.org/action_cable_overview.html#notes

You can probably do the signed cookies like the article there mentions as an alternative. That's how things work with Devise.

cookies.signed[:user_id] instead but also has to change in your controllers as well.

Update: Here's an example on StackOverflow: http://stackoverflow.com/questions/37671504/getting-authlogic-to-work-with-actioncable

So you set your user id in the session. Just use that to look up the user for the websocket:

      def find_verified_user
        if current_user = User.find(session[:user_id])
          current_user
        else
          reject_unauthorized_connection
        end
      end

Thanks Emmanuel! I appreciate it a lot and you're right, we're always learning especially with how fast this industry changes! :D

Hmmm, double check that you restarted nginx and that went correctly. If so, it should pick that up.