Chris Oliver

You'd define it in config/routes.rb

root to: "controller#action"

In development, Rails will show the "welcome to Rails" screen, but in production that disappears and would 404 without a root route.

The Rails root path is what will be rendered first. If that isn't found, it'll fall back and look for index.html in the public folder. Normally you have a Rails root so the index.html would never be used.

Not off the top of my head, but I can make a screencast on it. 👍

You can either:

1. Make a select that submits "1-10" to a virtual attribute on your model and use Ruby to split on "-" to get minimum and maximum and assign those.
2. Use Javascript to take the select value and fill out hidden fields for minimum and maximum on the Select change event.

I typically use the second approach so I can keep the backend cleaner.

Hey Sam!

Databases don't understand Ranges like Ruby does, so instead you can add the minimum and maximum values of the range to the database and construct the range from that.

t.integer :minimum
t.integer :maximum

class PricingClassification
  def range
    return nil unless minimum?
    (minimum..maximum)
  end
end

They test Jumpstart's functionality. You're free to recreate them in rspec too.

If you want everything that's built with your favorite tools, Jumpstart Pro is not the template for you. Jumpstart Pro is built using everything that comes with Rails and as few dependencies as possible to keep it clean and organized.

You can add rspec. The template will come with minitest and you can choose to ignore or delete them. Makes no difference. 👍

You need to keep it. It manages the configuration. 👍

Jumpstart modifies form submits to be AJAX requests using turbolinks_render.

Your default Rails form submission is a POST request, so the page would fully reload and ActionCable would connect.

I never thought about it, but that is probably something that can/should be triggered after login. A Stimulus controller for this would make sense. It can just check fi the connection is open and, if not, issue the connect. It would probably need to be on every page, unless there's a way to do it after login. I need to think on a good way to do that.

Like I mentioned before, CF is a proxy so it passes the requests to Rails. Rails serves up files just like it always does. Nothing special.

That's the cool part. When you configure the backend, it will accept all requests and then ask your app (the backend) for the files and send them back. It saves them in the CDN so that next request, it doesn't have to ask your app again and can serve it up immediately. It just sits in between the user and the app as a proxy.

Uploaded it to YouTube so you could see it early. 😎

https://www.youtube.com/watch?v=5KuTzT_MWoM

Recorded a video on it. I'll be publishing it in the next week or two. 👍

I may have accidentally missed a little bit of that as I was trying to prepare for the episode. 😬

Great idea!

You can usually just call the sanitize method and that'll do what you need.

Yep! Push notifications would be an API call (similar to Slack, Twilio, and Vonage are). 👍

Well, notifications are a complicated subject. Basic ones like sending an email are easy, but this is a full-featured notification system like you'd see on Facebook or Twitter. I'll talk more about it and show a very basic use case of Noticed soon.

Also for the frontend, I usually build my own helpers to generate the two fields for me. Saves a lot of time and I can just make a small change to each field with a find & replace to call the new helper instead of having to edit each one.

This would make a great screencast talking about the tradeoffs of both approaches.

You can definitely strip out the commas or periods when the user submits the data if you want by overriding the setter methods. That would let any value be submitted and cleaned up before storing it in the model.

def population=(value)
  super(value.gsub(/[.,]/, '')
end

Something like that should do the trick.

Since it's just formatting, it's usually best if that just happens on the client side. That becomes even more useful in other languages that might use a period as thousands separators instead of commas. They can change their locale and the backend data would not have to change for that. Plus, the backend doesn't have to worry about modifying the formatting, just validating it.

Either way will probably work fine though.