lockstep / rails_new

A thoughtfully designed template for building modern Rails apps. Get started in minutes instead of hours 🔥🚀

Lockstep Labs

Welcome to the future of web development.

rails_new's Issues

Allow delegation/forwarding to other objects besides wrapped

Right now you can do forward calls to wrapped via ApplicationDecorator::forward. I recently encountered a case in a presenter (which inherits from ApplicationDecorator) where it would be convenient to use forward *methods, to: :elsewhere instead of forwarding them to the wrapped object. In this case I couldn't use delegate on the model level to accomplish the desired forwarding, so I ended up using def_delegators directly. Maybe better if we add an optional to: to the our base decorator forward method?

Decide on serialization method

Background: What's happening to AMS

They themselves seem to suggest that jsonapi-rb could be a good alternative, so I'm interested in opinions.

Please check out the docs and provide feedback on whether or not we should move forward with this:

http://jsonapi-rb.org/guides/getting_started/rails.html

For reference: I always liked JSON API and built similar structures myself before it became a thing, so might be biased.

Upgrade to CircleCI 2.0

After August 31, 2018, CircleCI 1.0 will no longer be available.

@hiattp @citizen428

NameError: uninitialized constant Rack::Timeout

NameError: uninitialized constant Rack::Timeout

initialize application form with resource attributes by default

Whenever I override the initialize method in ApplicationForm I use the resource attributes as the default params instead of {}. This provides more intuitive behavior because you can initialize the form object passing only the resource and the form object will behave (state-wise) as the object itself (default values are set to whatever the current resource values are). Otherwise you can pass a user into the form initializer and no params (e.g. on an edit action) and see no default values populating the form.

I suggest we do something more like this in the application form, but wanted to propose it as a question first in case I'm missing any obvious disadvantages here:

def initialize(resource = self.class.resource_class.new, params = resource.attributes)
  ...
end

Add TODOs to specific lines that need to be changed?

@citizen428 I was wondering if we should add TODOs wherever changes are needed so you can easily search for them without checking back with the readme once you clone the repo. Thoughts?

What version of Ruby are we actually using?

@citizen428 The Base system section in the repo says we use Ruby 2.3.4 but what's in the .ruby-version is 2.4.1.

I'm using RVM myself, not sure if anybody notice this. Should we change the .ruby-version to reflect with the README?

ApplicationDecorator instead of Draper

Right now we're including Draper in the default Gemfile. However, as part of a recent discussion I came up with a pretty functional yet minimal decorator that could just be good enough™ and would remove a pretty big and magic external dependency:

require 'forwardable'

class ApplicationDecorator
  extend Forwardable

  def self.forward_all
    define_method :method_missing do |m, *args, &block|
      return record.send(m, *args, &block) if record.respond_to?(m)
      super
    end

    define_method :respond_to_missing? do |m, include_private = false|
      record.respond_to?(m) || super(m, include_private)
    end
  end

  def self.forward(*methods)
    def_delegators :record, *methods
  end

  def self.forward_aliased(hash)
    hash.each do |old_name, new_name|
      def_delegator :record, old_name, new_name
    end
  end

  attr_reader :record

  def initialize(record)
    @record = record
  end
end

Example decorator (with a fake user object):

require 'ostruct'
user = OpenStruct.new(first_name: 'Michael', last_name: "Kohl")

class UserDecorator < ApplicationDecorator
  include ActionView::Helpers::TagHelper

  forward_all

  def full_name
    content_tag :strong, "#{first_name} #{last_name}"
  end
end

du =. UserDecorator.new(user)
du.full_name
#=> "<strong>Michael Kohl</strong>"

As you can see this allows:

1. forwarding all methods the wrapped record supports via forward_all.
2. forwarding selected methods via forward.
3. forwarding methods while renaming them via forward_aliased.
4. full access to the wrapped object via the record method.
5. integrating whichever helpers one needs via a basic include call (no magic)

This was a ~20 minute hack, but I think it's rather promising. If we can agree to replace Draper I'd spend some more time on this and also add tests etc.

Handle ActionController::InvalidAuthenticityToken

I see this in virtually every (non-API) application—someone leaves their browser open for a long time and then tries to submit a form (or log out), and they see an error due to an invalid authenticity token. It seems like we should at least rescue this by default and show a default flash message. Otherwise it just pops up eventually in every production app and we deal with it as it arises, which isn't a good experience for our clients or their users

Use Ruby 2.7

I tried the upgrade and it went well. We could either upgrade now (and live with the deprecation warnings) or wait until a new Rails release which will fix 90% of them. Then we can fix the warnings originating from our code. There's also an option to suppress them. I'd prefer not to do that.

What are your thoughts on that @hiattp?

Notes:

• pry-doc in not 2.7-compatible but I don't think that's an issue

Pwned passwords support

Is this something we should do by default?
https://www.twilio.com/blog/2018/03/better-passwords-in-ruby-applications-pwned-passwords-api.html

Looks trivial to plug into Devise.

consider use of global SETTINGS in js

See discussion in #118

Constants not loaded

I just tried having this enabled in production and saw the app crash with uninitialized constant Constants.

rails_new/config/environments/production.rb

Line 122 in ec0f15d

# host: Constants::HOST_URI.host

Can be replicated with having it enabled in development.

Question: UUID by default?

@hiattp @citizen428 I like the anonymity of UUIDs when the IDs are exposed in URLs etc. Thoughts on making them default? Can be configured in application.rb like g.orm :active_record, primary_key_type: :uuid + a migration with enable_extension 'pgcrypto'.

best practice for high voltage

@citizen428 what is the best practice for adding high voltage pages? Looks like the routes are disabled by default and the pages will operate at the root, is the intent to add individual/explicit page routes for any high voltage pages?

Fix .validators_on

Currently, this only returns form object validators. We need to include all validators defined on the resource.

This will fix simple_form not formatting required fields correctly.