Hacker News Reader

Comment by revskill | Hacker News Reader

RoR is nice, but it lacks one of the most important abstraction layer: The schema layer for HTTP. Currently the default is to mix model params with http params. It's bad default.

Of course you can use dry-schema for that purpose, but i do think the framework should enforce that for the whole ecosystem to follow.

View on HN

Yeah, the whole permitted params is actually is pretty shitty workaround against something else.

We're missing the 'form' part. Validations should be done against forms, not models. Default forms can easily be derived from models, which is nice for simple apps, but this is really something that's lacking in rails.

Permitted params exists because there is no form (dry-schema for example). There's ActiveModel, but it's not the same, and it's not ad-hoc / bound to the view/controller layer of things.

It's the main reason for bad legacy of many of Rails applications in the wild (noone wants to maintain the model code inside the view/controller). And it's HARD to understand why ? Omasake is bad omasake when you mix "unrelated concerns" together.

Sounds like you want MVVM vs. the default MVC pattern Rails ships. I think there are a few options out there which are bolt on for Rails but nothing out of the box.

I inherited a project where all the validations were in the forms and it meant that you couldn't reliably use the model layer without the forms layer (you'd end up saving invalid data). We eventually moved the validations to the model layer and dropped the forms abstraction. It didn't feel like the right separation of concerns when we had to pretend data was moving through forms to reliably interact directly with the model layer.

The enforcement of allowed params (and type casting from strings) definitely seemed like it was in the right place per-action in the control layer though, so we kept that from the forms even though we implemented it in the controllers.

I wonder if we just didn't understand the idea though? Or maybe if the original implementers didn't implement it right?

permitted params and validations are two different things though.

I've had great success building form objects with portrayal (https://github.com/scottscheapflights/portrayal) and ActiveModel. You can put validations into them, and auto-filter the params by making a `from_params(params)`-type constructor. In it you can call require/permit with `portrayal.keywords`. You're right that it'd be nice to have this out of the box, but this is just a few lines of glue code to setup. I'm in the process of making a new app template that does that.

This gem is just for construction, no validation ?

Schema layer purpose is to enforce invariant at the boundary of HTTP.

The gem is just for declaring struct keywords (slightly more featureful than vanilla structs). Validation is left up to ActiveModel::Model. I would do a setup like this:

    class ApplicationForm
      extend Portrayal
      include ActiveModel::Model

      class << self
        def from_params(params)
          new(**filter_params(params))
        end

        def filter_params(params)
          params
            .require(model_name.param_key)
            .permit(*portrayal.keywords)
            .to_hash
            .transform_keys(&:to_sym)
        end
      end
    end

    class MyForm < ApplicationForm
      keyword :first_name
      keyword :last_name

      validates :first_name, :last_name, presence: true
    end

Can use it in a controller action like

    form = MyForm.from_params(params)
    if form.valid?…
      # the usual

One of the good things about this approach is that you can also use this object in form_for/form_with in your views.

That said, there are similar objects one can make without using the "form" moniker, for API submissions for example. Granted, I also wish a solution was built-in.

Have you looked at ActiveModel::Attributes ? That coupled with ActiveModel::Model makes for simple form objects quite nicely. Also, you can write your _own_ ActiveModel::Type so you can require that a particular attribute is a particular (business) model. I've been finding it a very nice way to write form objects.

It's a bit dated now, but, I did a short presentation for my local ruby meetup and the slides are here [1]

1. https://slides.com/patrickdavey/rails-5-2-attributes-api#/25

Thanks for the suggestion. I actually explored switching to Attributes for a new Rails app, but 3 reasons made me come back to portrayal gem: 1) attributes don't support defaults. 2) I prefer not to set types on form object attributes, since they are supposed to deal with messy user input. Instead I lean on validations. And 3) I like read-onlyness, freeze, equality, duplication, and introspection features of portrayal gem.

Attributes do support defaults. You can absolutely do:

   attribute :my_time_at, :datetime, default: -> { Time.now }
   attribute :persisted, :boolean, default: false

What I like about the types is that it will automatically coerce the messy user data automatically (this is what AR is doing under the hood anyway right?), you can just be more intentional about it.

Anyway, glad you're happy with portrayal :) I definitely agree with you on the "freeze, read-onlyness" etc. being good things to have!

Ah, I accidentally lied by trying to reconstruct a vague memory, apologies. Now I'm remembering it in more detail.

It wasn't lack of defaults, it was handling of defaults. Portrayal does a couple of smart things like evaluating defaults in a specific order in the correct context (while still only evaluating once), such that this becomes possible:

    keyword :name
    keyword :greeting, default: proc { "Hello, #{name}" }

I like being able to do this. (This also works gracefully with subclassing.)

The coercion argument is good, but I'm not a fan of doing it implicitly. (This was the real counter-argument I should've made). I prefer to have a single place where input is entirely processed, such as a `from_params(params)`-style constructor. In that constructor you could either coerce, or do anything else with the input prior to passing it through to `.new`.

I also wasn't a fan of how Rails handles params, so I ended up writing my own lib. And I'm actually working on open sourcing it and extracting into a gem.

    typed_params {
      param :data, type: :hash do
        param :first_name, type: :string, optional: true
        param :last_name, type: :string, optional: true
        param :email, type: :string, format: { with: /@/ }
        param :password, type: :string, length: { minimum: 8 }
        with if: -> { current_bearer&.admin? } do
          param :metadata, type: :hash, allow_blank: true, optional: true
          param :role, type: :string, inclusion: { in: %w[admin user] }, optional: true,
            transform: -> (_, role) { [:role_attributes, { role: }] }
          param :permissions, type: :array, optional: true, if: -> { current_account.ent? } do
            items type: :string
          end
        end
      end
    }
    def create
      # ... controller code here
    end

Each param schema has to be defined by source, e.g. request body vs query string. And params aren't intermixed (including routing params).

We want a generic interface: Think Rack for params parsing/serializing, then you could easily parse any params into your own data structure. Stringly types are out of scope.

Why do you need something so generic? Can you share a use case?

I'm very ambivalent about Grape, but this very much reminds me of something I do really like about it: the param validation. https://github.com/ruby-grape/grape#parameters

Yep! I was very inspired by Grape’s param system.

Yeah, I'm pretty sure every Rails shop has invented some flavor of APIObjectSerializer based on JSON-API, REST, or whatever because doing it ad-hoc will make you pull your hair out.

Reply on news.ycombinator.com