Chris Oliver

A couple reasons:

1. You only should see notifications where you are the recipient.
2. The actor doesn't matter, it's just some other person that took an action that you should be notified of. You don't really care about the actor, so you can pretty much ignore that relationship which means you don't need to define that second set of notifications. It's a relationship that could exist, but since you will probably never use it, we don't define it.
3. A little unrelated, but you'd also need to change the name of the second "has_many :notifications" because that would override the first one.

There are, although I haven't personally used any so I can't confirm if they're any good. You can check out like https://www.nitrous.io/ and https://c9.io/

I would rewrite those tests to use those classes directly. It'll clean up the tests and then you can optionally have the test for the Customer model that tests the integration of the two classes if you keep that.

My bad :) Should have given an example.

  link = $(event.target).data("url")

Replacing that line with the above code should do it. The event argument contains all the data about the event, including the link that was clicked. That's the target attribute. You can then just access that like the above and everything is nicely scoped.

Yeah, that makes sense given the scale of support they need to have. I bet the average user for them is connected to like 20 chat rooms in each organization, and then like most of my friends, connected as well to like 5+ organizations. That's a lot of DOM manipulation that you can postpone until later.

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