Chris Oliver

Right, and that would be because now that you changed scopes, the this variable references the JS object now instead of the element in the callback. Scopes in JS are quite tricky huh?

Solution now would be to use the event.target from the argument the callback receives. That'll be the link that was clicked, and you can then replace this with that in order to accomplish the same thing.

It probably makes the most sense to have those on the page by in hidden divs. That way you don't have to store all those messages in memory in a hash of some sort and you can inject them on the page as HTML. They won't be visible, but you can continually still get updates for them. Everything will continue updating in realtime, you're just visually hiding everything but the active channel.

My guess would be that Slack's app works the same way when you're logged into multiple channels.

Oh, actually what it might be then, is that your scopes are a bit different in the second case.

While in the first one, you're inside the object and you have showProposals in the same scope, the second one is executing inside a click callback, so it may not actually have access to showProposals. You might try changing the on click handler to also use the thick arrow there => if it's also defined inside the object.

Could be the problem, also very possible it's not either. :)

Fantastic idea. I imagine using something like Pundit with ActionCable will be really useful for this.

Great idea. Might also make sense to include something there on deleted records that use like an DeletedUser class or something to display some sort of text instead. Reddit does something like this when you see the posts that show [deleted] as someone's username.

Hmmm, not quite sure I'm following so let's see if this describes your problem: are you having trouble getting your on click function to fire because you're dynamically inserting those and the jQuery function isn't firing them?

Oh that'd be a good one! I will be diving into ActionCable a bunch soon, so I'll include this in the list!

Like infinite scroll or just AJAX links to replace the current page of results?

For delete, I would send the Upload ID to the uploads controller and then just delete that directly. It's simplest that way because you aren't accessing anything through the polymorphic relationship. If you did, you'd have to make a ProductsUploadsController, an ItemsUploadsController, and so on. It's far more work than is necessary that way. So the easiest solution is just to have an uploads controller that you link to and add the destroy action there.

The cascade won't call the active record callbacks, which means that it's faster, but if your conversations have other models that you also want to delete, they won't. That's the main drawback there. Usually its best to do dependent: :destroy even though its a little slower because deletes don't happen that often. If they do in your case, then it might be worth building a custom Service object that can gather up all the necessary records and delete on cascade. That'll give you the benefits of both effectively because you'd be writing the callback logic instead in your service object.

Looks pretty good. I think if you have the has_one and belongs_to associations setup on User and profile, I would modify your create like this:

    if resource.save
        resource.create_profile
    end

That'll be a little cleaner and easier to maintain.

For the destroy, it might make more sense to use a dependent: :destroy callback on the User models: has_one :profile, dependent: :destroy. This way anytime you destroy a user, you can also destroy their profile. It will happen automatically.

Yeah, when you use BlogPost.new, that's creating a new object without errors, so those obviously won't exist on a new one.

One solution is to go in your app/views/blog_posts/new.html.erb you'll want to make sure you use @blog_post so that it has the errors when it renders. This way it will try to save, when it fails, it will render blog_posts/new and you'll have the errors on the @blog_post object that you can render.

The other alternative would be to submit the form with JS and use that to display the errors.

Ah! So if you've got it on the application layout, that means you need to set the @blog_post variable on every page. You've got two approaches for this.

1. You can create a before_action :set_blog_post on ApplicationController so it runs on every action.
2. Or I realized you could modify your form like this (I'd recommend this approach in this case):

          <%= form_for(BlogPost.new) do |f| %>
            <% if f.object.errors.any? %>
              <div id="error_explanation">
                <h2><%= pluralize(@f.object.errors.count, "error") %> prohibited this post from being saved:</h2>

                <ul>
                <% f.object.errors.full_messages.each do |message| %>
                  <li><%= message %></li>
                                        <div class="col-sm-2  pull-left" id="socialize">
                                <p>I'm a social persons find me :<br>fb tw insta</p>

                                        </div>

                <% end %>
                </ul>
              </div>
            <% end %>

            <div class="field">
              <%= f.label :title %><br>
              <%= f.text_field :title %>
            </div>
            <div class="field">
              <%= f.label :description %><br>
              <%= f.text_area :description %>
            </div>
            <div class="field">
              <%= f.label :status %><br>
              <%= f.check_box :status %>
            </div>
            <div class="field">
              <%= f.label :category %><br>
              <%= f.text_field :category %>
            </div>
            <div class="field">
              <%= f.label :post_date %><br>
              <%= f.date_select :post_date %>
            </div>
            <div class="actions">
              <%= f.submit %>
            </div>
          <% end %>

What I did here was change @blog_post to f.object which is a reference to the BlogPost.new that you passed into the form_for originally. This way you won't need the @blog_post variable at all.

What does your controller look like?

For code blocks, you can write backticks ` around your content so that it shows up as code and doesn't get eaten. :)

```
code
```

Sounds like you just need to set your @blog_post variable in your controller action. Have you set that? You'll also need to modify your form_for to be form_for(@blog_post) to be consistent.

@blog_post = BlogPost.new

Hey Stan,

You'd actually just put an if statement in the JS. If the length of the notifications > 0, display them, else, render your placeholder.

Something like this (I haven't tested this, so it may have some bugs):

  handleSuccess: (data) =>
    items = $.map data, (notification) ->
      "<a class='dropdown-item' href='#{notification.url}'>#{notification.actor} #{notification.action} #{notification.notifiable.type}</a>"

    $("[data-behavior='unread-count']").text(items.length)

    if items.length == 0
      items = "<a>No new notifications</a>"

    $("[data-behavior='notification-items']").html(items)

Something like this should fix it:

desc "Fetch anime info"
task :fetch_anime_info => :environment do
 require "open-uri"
 require 'mechanize'

 Anime.all.each do |anime|
  season_scrape = doc.css('div#content .borderClass .js-scrollfix-bottom div:contains("Premiered")').text.split(' ')[1..-1]
  season_text = season_scrape.blank? ? "" : season_scrape.join(' ')

  season = Season.where(name: season_text).first_or_create
  anime.update(season: season)
 end
end

This way you'll look up the season to see if it exists, otherwise create a new one, and then you'll associate the anime to the season.

Hey Sacha, you would just want to use a where query to scope to a date range before calling to_csv on it. You may need to change it from all.each to scoped.each in order for Rails to respect the scope if it wants to override your where query. That should do it!

Updating the season through the association works well.

And a side note: That url with the UUID at the end is what happens when friendly_id already detects a duplicate.

That's a good question. Aside from a brute force approach, I'm not sure. What I would probably do is just query for the record, make a copy of the object with .dup, switch the tenant to the new one, save the duplicate in the new tenant, verify it exists, switch back to the old tenant and delete the old record (if necessary).