All threads / Sharing Data With Javascript Discussion
Ask A Question


You’re not receiving notifications from this thread.

Sharing Data With Javascript Discussion

Thank you for this video, very interesting way of autoloading new notifications.

However, polling sounds a bit "old school". I read a lot about Active Live and websockets with the upcoming release of rails 5. Wouldn't it be interesting for this case to share new notifications automagically to all users concerned by them as soon as they are created ? Or maybe it's too heavy ?

Polling works just fine in a lot of cases unless there's an absolute _need_ to have realtime. It's rare for notifications to need to be truly instant. The other beauty of polling is that you can just write regular old Rails and JS code which you're already familiar with scaling. Probably 99% of the time, polling will do the trick just fine.

However, that's something we'll be talking about in the future. WebSockets are a whole lot more complicated to setup, manage, and maintain, so it will be a topic for a separate series (one that's coming soon!).

Hi Chris, thanks for this great video. One thing: I think the call to "render" needs to be surrounded by a call to "escape_javascript"( For instance:

<li class="nav-item btn-group" data-behavior="notifications" data-notifications="&lt;%= escape_javascript(render template: "notifications/index", formats: [:json]) %&gt;">

Or, shorter, using the alias "j":

<li class="nav-item btn-group" data-behavior="notifications" data-notifications="&lt;%=j render template: "notifications/index", formats: [:json] %&gt;">

Otherwise, a quote character in the generated JSON can break your HTML.

That's actually what I first did, but discovered that the way I showed in the video output and parsed the JSON just fine. I didn't run into any issues with it, but if it does become a problem for anyone, escape_javascript and some additional JSON parsing in the JS should do the trick.

Why have you decided to use CoffeeScript here? To me it seems really hard to justify when features are incompatible with ECMA 6. This makes me a little nervous about relying on these lessons.

do you don't know that coffescript compiles to javascript and coffeescript is limited by what javascript can do? if you don't like coffeescript just take the generated javascript and work with :) and if you don't know coffeescript yet you have to know that it will be more easier for you to transform your code from coffeescript to ECMA 6 than the "actual" javascript to ECMA 6 ! only when you know coffeescript well you will know how powerful and beautiful the language is. another thing is that so many people use that "language", and the community is large, so you will always find ways to switch if someday you want to... the only problem I can see here is if you don't have time to understand that "very easy to learn" language (and frankly I was always nervous about coffeescript before I learn it, so I can understand you)

I know CoffeeScript and abandoned it for the reasons I outlined above. Sure, you can compile your CS to JS. But then why not just write JavaScript?

If I were you, I wouldn't be looking forward to dealing with conflicts with keywords like ``, `class`, and even `super`. But to each their own.

No particular reason. I have been using CoffeeScript before ECMA 6 and am familiar with it so it's easy to use. Once nice thing is it's easily translatable to JS as well for anyone not familiar with it.

And yes, ECMA 6 (and 7) solve pretty much everything there. I'll have to do an episode showing how to use ECMA 6 with Rails as well.

Chris, is using setInterval good for our Rails app performance?

It will add extra requests, but they are pretty simple, plus you can enable caching around the JSON response to make it fast.

How to enable caching around the JSON response Chris?

Check out the documentation here:

And my previous episode on fragment caching:

Great as always. Something i noticed is when
setInterval is fired and if the drop down menu is open, it will make disappear its content. How could we prevent that ?

Thank you for the video, Chris! I implemented the notification feature by watching the previous tutorial and it works great! But it's tedious to test in the browser because I have to be logged in as two different users. I tried writing Jasmine test and capybara test but I'm a bit stuck. It'd be awesome if you could cover testing for this feature, too. Thanks for the tutorials!!

You just solved about three problems I knew I'd be running into in the next few weeks, and thereby completely justified my subscription for quite a while. Thanks, and keep it up! 😌

Wow, that's awesome, I'm really glad it was helpful! :)

Jordano Moscoso ·

This using ActionCable could be interesting, ill try. What about you Chris?.

You can use this approach still the exact same way with ActionCable if you want to preload some data in the view before the Websocket connection gets initialized.

For the most part, with websocket stuff, I imagine in most cases you will want to just display a loading spinner instead while the connection gets setup. They'll happily work together though with no problem. The only difference is that you change the mechanism to update the data from AJAX to Websockets.

Carlos Ribeiro ·

If I'm using active model serializer, the way to do this on the view is to use `@notifications.to_json` on the render?

Join the discussion

Want to stay up-to-date with Ruby on Rails?

Join 70,078+ developers who get early access to new tutorials, screencasts, articles, and more.

    We care about the protection of your data. Read our Privacy Policy.

    logo Created with Sketch.

    Screencast tutorials to help you learn Ruby on Rails, Javascript, Hotwire, Turbo, Stimulus.js, PostgreSQL, MySQL, Ubuntu, and more. Icons by Icons8

    © 2023 GoRails, LLC. All rights reserved.