Marc Köhlbrugge

This is great! Never knew about this one. Now I have to try and find uses for it :)

I guess any model attribute that ends up having a lot of auxiliary methods or view helper methods around them would be potential candidates.

Alternative approach to using @scope:

resources :todos, likeable_type: "Todo" do
  concerns :likeable
end

And you can use params[:likeable_type] in your Likes controller.

I find it a bit more explicit and safer as I know exactly what strings I’ll be constantizing.

Anything you'd do differently with Turbo Stream available now?

This has worked quite well for me, with one exception. When changing a password, it ends up calling redirect_to navigation_location but navigation_location is nil at this point.

You mentioned Redis is best for ephemeral data as there's a chance the process crashes and the data is not persisted. That's a clear drawback, but what are some of the BENEFITS for using Redis over say PostgreSQL?

Is Redis more performant? In all cases or only some?

Would love to hear of some more real-world examples where you'd choose Redis over PostgreSQL.

Great tip! I use something similar for designating the thumbnail-image of a gallery of images. Something along these lines:

class Gallery
  has_many :images
  has_one :thumbnail, -> { where(thumbnail: true) }, class_name: "Image"
end

One of the benefits over this approach versus having a regular thumbnail method, is that you can eager-load the thumbnails and prevent N+1 problems using @galleries = Gallery.includes(:thumbnail)

If you need more flexibility, I think you can also use DelegatedTypes. For example if ShippingAddress needs a specific attribute or logic that BillingAddress doesn't need.

Thanks for sharing! Curious to hear about some real-world applications for this?

One thing I've found helpful is to purposefully start with a very concrete approach (like you following the designer's template) and only refactor it later to make it more flexible if and when it's needed. Because it's hard to predict exactly what flexibility you need. You don't want to end up with the wrong abstractions.

Curious to hear your views on this. Do you think you would have found this composable approach for the receipts gem if you didn't first start out with the more fixed approach?

How do you balance the trade-offs of A) getting something shipped quickly that works and can be refactored later, versus B) taking a more flexible/composable approach from the beginning and risk using the wrong abstracting or even spend additional time on code that might be removed in the near future anyway (e.g. if it's a feature users don't end up using).

Interesting topic. Thanks for sharing!

Curious to see more examples. Chris, do you use any web components for GoRails or Jumpstart Pro?

Thanks for the follow up either way. I think I got it resolved by simply upgrading the sidekiq gem

I'm running into a similar issue right now. ActiveJob/Sidekiq cannot find the record even though it exists. After a retry it does find it.

Did you solve your issue? Curious to hear your findings.

An individual user will create one consumer-connection pair per browser tab, window, or device they have open. ( source )

Very cool. I imagine a real-time comment feed like this will make a website feel come alive.

One issue I’d love to see addressed in a follow up video is the page kinda moving around as you’re reading comments. I believe Disqus solves this by not I’m immediately appending new comments, but adding a placeholder like “5 new comments” which you can click to reveal.

I imagine we could do something similar with Stimulus but it right require some changes to the broadcasts.

Once security concern to be aware of when implementing this type of registration system is that many support systems can be abused to receive email on a corporate domain name.

For example, when creating a support ticket with Spotify they might generate a ticket-12345@spotify.com email address for your support ticket. You could then use this email address to by sign up to a service that uses the described corporate-email restriction. The confirmation email would be send to the support ticket email address, which you then (as the original Spotify user creating the support ticket) would likely to get notified of. Allowing you to confirm the email address.

The protect yourself from such a hack, make sure to use a special subdomain (e.g. support.spotify.com) for these kind of support ticket emails and code your corporate-email validation such that only root domains (@spotify.com) are allowed. (as described by Chris)

Did you consider automatically generating the sentinel if a pre-existing namespace was used? That way the API of the route method can remain unchanged, but you still solve the issue of having duplicated namespace definitions.

Alternatively a route_namespace method that accepts a block might work to. Something like this:

route_namespace :madmin do
  route …
  route …
end

You can use ruby/setup-ruby's bundler-cache feature to have it take care of installing your gems and caching it. Saves you from adding those steps yourself.

https://github.com/ruby/setup-ruby#caching-bundle-install-automatically

It sounds like your Comment model doesn't have the commentable_type attribute yet.

Make sure to run your database migrations (rails db:migrate) and try again. If it still gives you the error, then check your database schema file (db/schema.rb) and see if the comments table has a commentable_type column. It probably has not which suggests you need to write a migration that adds it (and potentially the commentable_id column as well).

See the video for how to do this.

Actually, now that I think about it you might run into issues when adding webpack-bundle-analyzer as just a development dependency. As the webpack config still refers to it.

So if you do want to add it as just a development dependency, make sure to only configure it in config/webpack/development.js

UPDATE:
I was wondering if it still worked with RAILS_ENV=production bin/webpack. It does. That's unexpected, but what we want in this case. There's probably no harm in loading the dependency in production though, so it might be simplest to stick with Chris' approach.

Thanks Chris. Very timely as I've been trying to optimize my assets.

Two quick suggestions:

1. You can skip the duplicate BundleAnalyzerPlugin reference by typing this instead:

const { BundleAnalyzerPlugin } = require('webpack-bundle-analyzer')

1. You probably don't need this plugin in production. So you can add it to your devDependencies instead:

yarn add webpack-bundle-analyzer --dev

Chris indeed!