Chris Oliver

So what I would probably do here is actually:

resources :milestone do
  member do
      post :activate, to: "milestones/activations#create"
        delete :deactivate, to: "milestones/activations#destroy"
    end
end

Then you can have a app/controllers/milestones/activations_controller.rb that handles them. That's great for separating out the logic from the main CRUD, and your routes aren't too complicated.

I'll often make a singular resource for things like this too.

resources :milestone do
  scope module: :milestones do
      resource :activate
    end
end

Works a bit better if you're doing like resource :advanced_search or something.

In your case, DELETE /milestones/1/activate doesn't make sense, and you'd want the destroy route to be DELETE /milestones/1/deactivate so it's more intuitive. And that's why I'd probably write the custom routes instead of resources in this case.

I think it's fine for you to make some non-standard actions here.

Are these actions changing the Milestone record or are they change an Activation / Completion records associated to a Milestone?

Helpy is great! Deployed it via Hatchbox a little while back and it keeps improving.

I think you can probably use the API to create users after they're created in the main app. https://support.helpy.io/api/#operation/postApiV1Users

If they both use Devise, you can sync the user accounts between the two databases and then set the cookies to store on *.domain.com so they're automatically logged into both. The apps would need to share a secret key base for that since it would be decrypting the same cookie.

That's the ideal so you don't have to have the users go through any process.

You can do omniauth and make your main app where the user logs in the provider and then every other app can be the client. That will work too. You might be able to tweak it so they don't have to approve and it automatically approves the OAuth request so it is more seamless.

Yeah, it'd be a great way to test and make sure your Vue app was integrated correctly with the Rails app. You can also look into things like Jest to test just the JS independently, without Rails.

You'll need to use their API to do that. Check out this gem: https://github.com/eddiezane/sendgrid-actionmailer

Shouldn't be too bad. You'd want to figure out what it means to abandon the cart. Is that a cart that was last created 1 hour ago that wasn't checked out?

Then you'd want a cron job to look for those carts every X minutes or so, and then send the email. You'll probably want to mark those carts as "abandonment email sent" or something so you know to filter them out next time.

The cron job running every X minutes should always find ones created one hour ago and incomplete, so that the emails get sent out regularly.

Probably at some point. I don't have any specific plans for it yet.

Yep, check out the JWT from scratch episode instead. That one will work just fine and you won't have to depend on other maintainers.

You should be able to use mixins in the asset pipeline, as long as your filename ends in .scss so it gets processed with scss.

It won't hurt to use Webpacker for everything. In fact, you need to in some cases like when you're using TailwindCSS.

Images don't really need to go through it since they don't need to be preprocessed and if you have simpler CSS, then the asset pipeline is still around for that.

@Ivan, no, not during deploy. You should already have done that so they're added to your package.json. The assets:precompile step will make sure they're installed during deploy.

Heroku does need you to add the node buildpack alongside the ruby buildpack so you can use yarn.

heroku buildpacks:add heroku/nodejs
heroku buildpacks:add heroku/ruby

That's actually using the data-confirm-modal gem to use Bootstrap instead. It's kind of hacky how it replaces the confirm method in Rails JS, but you can check out the source here. https://github.com/ifad/data-confirm-modal

iTerm is so dope, thanks for sharing that! 🙏

Yeah, one of the reasons I choose to use Minitest over Rspec is that it's mostly just pure Ruby. You have a couple wrappers around assert, but it's really just Ruby code. Less magic means it's more reliable to reason about.

Headless browsers I do believe can still generate screenshots. I will try it to make sure. The main reason you need a headless browser is on your server, you don't have a screen, so there's no windows to actually render. It's all virtual.

If you're looking for something quick and you already have it, ActiveAdmin might work alright. Looks like you'd have to add the Javascript to ActiveAdmin yourself, similar to this post: https://stackoverflow.com/questions/57886802/how-can-i-use-action-text-on-active-admin

Administrate has a plugin or two for ActionText if you are adding an admin.

And probably the best long-term approach would be to just build it yourself that way you have full control over how the CMS works and aren't fighting with an admin gem. That said, it's a lot more work so may be something to do later on.

Create new ones like has_many :old_associations, foreign_key: :old_id or whatever options are necessary.

You can specify the column on your association that's used for joining tables. You'd just specify that old_id column and you should be good to go.

@Vitor the Apartment docs should have a good explanation for that. 👍

I would use a Stimulus controller to listen for "change" event on the radios and then update the hidden fields accordingly.

You can either:

1. Add some code to the model to transform the selected value here to what you want in the attributes before_validation
2. Add Javascript to change hidden fields based upon the selection

I'd probably go with Javascript personally in this case as I think it'd be a little simpler.