Chris Oliver

You can add your own sites in /etc/nginx/sites-enabled/mysite. Just don't use a name that matches an app name in Hatchbox.

Hatchbox doesn't really make any adjustments to the NGINX config other than enabling Passenger, so you're free to add PHP, etc. 👍

I actually have a private beta in Hatchbox that lets you choose a language when you deploy an app. You could deploy your PHP scripts from there (I've tested Laravel and Wordpress I believe). I'll have to add enable that on your account and you can then select the language when you create a new app.

We're working almost finished with the first version of Hatchbox v2, which switches to ASDF so each app can specify their language (and versions) so in the future you'll be able to deploy PHP apps. 🔥

Logging in with invalid credentials does fail and is a bug. I'll get that fixed. 👍

I just updated Jumpstart open source to use Hotwire, so maybe there is a bug in it. I'll have to try it out again.

Also feel free to post this on the Jumpstart repository so I can keep track easier. 👍

What version of Rails are you on?

This will be nice for simpler applications that don't need a lot of JS dependencies. You'll be able to ship all your Javascript really quickly and easily. This will be great for Stimulus controllers and other basic code.

Evan You who created Vue and Vite had some comments on it: https://twitter.com/youyuxi/status/1425933472871456777
He's specifically referring to larger frontend applications and I think those are valid points where Webpacker, Vite, or an alternative will still be the best option.

So it sounds like it depends on what you need. Importmaps will be perfect for applications that don't have a ton of frontend dependencies. I think Rails has always pushed for minimal JS, so it makes sense to use importmaps out of the box.

Sounds like you need the colorize gem: https://github.com/fazibear/colorize

I know Jason Charnes built a testing library for SR when they started using at Podia. Probably the tool to use: https://github.com/podia/stimulus_reflex_testing

Z-index to the rescue! The Places Autocomplete was a lower z-index than the modal, so some CSS fixes that nicely by raising it over the z-index of the modal (which was 9999).

Create app/javascript/stylesheets/components/places.scss

// Raise z-index of Google Places Autocomplete higher than the modal z-index
.pac-container {
    z-index: 10000 !important;
}

Add the following to app/javascript/stylesheets/components.scss

@import "components/places";

I'm leaving for vacation on Thursday so I don't have much time, but if you've got some sample code I can run, send me an email. 👍

Yeah, that is not equivalent there because you're not filtering the evalulations, only the skill. You need to have it in a single query.

DHH doesn't like the Law of Demeter, so I wouldn't worry too much about trying to follow it. He's written about it a few times: https://signalvnoise.com/posts/3341-pattern-vision

I've never really agreed with the single method call (dot) advice, personally.

One thing, you don't need the .try because where will always return an ActiveRecord::Relation object which will always respond to first. It may or may not return a record, so anything you call after that would need to check if accuracy was nil.

A little cleaner version is to use find_by

# Returns an Evaluation
def accuracy
  evaluations.joins(:skill).find_by(skills: { code: 'ACC' })
end

Stimulus monitors for elements in the DOM, so it should apply to them in the modal. Have you added any debugging code to the Stimulus controller to verify it's finding the correct element and initializing the autocomplete correctly?

Tools are located here: https://gorails.com/tool_categories/

I think I accidentally removed the links to the Tools section! Better add that back. 😬

Yep! Just make sure the cookie gets included in the request and that's it. 👍

Hey Maria! You should post this to https://jobs.gorails.com as well!

Sidekiq needs to be configured to process the mailers queue.

If you have the HTML ID in the URL (or sent as a param), you could use that in your turbo_stream.replace.

For example:

<% @cards.each do |card| %>
  <%= tag.div id: dom_id(card) %>
    <%= render partial: "cards/show", locals: { card: card } %>
  <% end %>
<% end %>

<%= turbo_stream.replace dom_id(card), partial: "cards/show" %>

That gives you a consistent ID across things.

Turbo Frames would expect you to have routes for the card show & edit and would handle this for you automatically as long as you had a resources :cards controller filled out with the matching frames.

Yep, you will:

1. Create an account with Stripe::Account.create()
2. Save the account ID to your user
3. Create an AccountLink so the user can be onboarded.

https://stripe.com/docs/connect/connect-onboarding

Stripe recommends using AccountLink instead of OAuth. It's a bit easier and supports both Express and Standard accounts.

Check out the docs for that here: https://stripe.com/docs/api/account_links

Does this work? https://stackoverflow.com/questions/54979195/passing-cookies-with-httparty

get_response = HTTParty.get(url)

cookie_hash = HTTParty::CookieHash.new
get_response.get_fields('Set-Cookie').each { |c| cookie_hash.add_cookies(c) }

response = HTTParty.post("http://localhost:3000/users/other_urls", {headers: {'Cookie' => cookie_hash.to_cookie_string }} )