Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Chase Gilliam
@Ch4s3
there's room for everyone, so stay tuned in the channel
:)
Tomek Rusiłko
@rusilko
awesome, thx
Tomek Rusiłko
@rusilko
how is “nailing down scope” happening usually, do you guys discuss everything here?
Chase Gilliam
@Ch4s3
yeah, basically all of the discussion happens here
Piotr Solnica
@solnic
@rusilko I'm busy with work so I'll answer all questions later, re why dry - we just wanted something short ;)
Tomek Rusiłko
@rusilko
cool, I gotta run too, talk ty later
Aleksandar Radunović
@aradunovic
is there some rule of thumb when deciding if something should be a separate transaction step or just included into some operation?
take validation for example…do you validate in CreateSomething operation or define it as a :validate step in transaction?
Ralf Schmitz Bongiolo
@mrbongiolo
maybe dry-v could be used in a similar way that Hanami uses it on its actions, it acts like strong_parameters + validator
Chase Gilliam
@Ch4s3
That could be good
Tim Riley
@timriley
@aradunovic I tried validations as standalone steps in transactions but found it was a level of granularity that wasn’t helping. Our most common commands are mostly built around validate+persist and it made sense to combine them. The validation feels closely related to preparing the data for persistence.
The side benefit was that I didn’t have to define hundreds of transactions. This leaves the transaction level for truly complex, truly multi-step things.
Eduardo de Oliveira Hernandes
@eduardodeoh
@solnic if possible, take a look: https://gist.github.com/solnic/6030ad52c7600257ed09d13537f4f498 - thank you
Ralf Schmitz Bongiolo
@mrbongiolo
@aradunovic Usually I set validations as a step of the operation, something like this:
class Create < Resource

  register :schema, Dry::Validation.Schema {
    # validation logic here...
  }

  perform do
    validate :schema
    tee :persist
    map :decorate
  end
end

Some of the operations are more complex, and I separate "params" validation from model and external validations, something like this:

perform do
  validate :schema
  tee_try :validate_resource_status, catch: Errors::UnprocessableEntity
  map :extract_date
  map :compute_period
  try :get_available_members, catch: Errors::UnprocessableEntity
  tee :update
  map :decorate
end

In this case, :validate_resource_status and :get_available_members could raise an UnprocessableEntity error that would be handled back in the controller, I separated those ones from the main schema because the logic on those cases are not directly related to the input. But for most cases I'll have a single :schema that will validate the input, followed by a :persist or something.

Aleksandar Radunović
@aradunovic
Wow, nice…thanks guys…
@timriley I asked the question because of create operations on berg. I was wondering why didn’t you separate validation, but now I know.
Tim Riley
@timriley
Yeah. I guess everyone can do it in their own way, but this is what’s working for us so far. Seeing those transaction examples just above is something I’ve never done before.
joystick
@joystick
Hi there, looking for help with AR scopes. Is there a room for that on gitter please?
Pablo Herrero
@pabloh
@joystick, try freenode.net
joystick
@joystick
@pabloh Thanks, will try. Which room please?
Pablo Herrero
@pabloh
#ruby ;)
joystick
@joystick
:+1:
Aleksandar Radunović
@aradunovic
is there any way to achieve projects/:id/tasks with multi_route and separate tasks.rb routes
Piotr Solnica
@solnic
@mrbongiolo this is pretty nice, thanks for sharing
Oskar Szrajer
@gotar
yeap it's possible I think. If you set Roda route for project as:
r.on "projects"
    r.on :id 
        r.on "taska" do
             r.route "tasks"   
        end
    end
end
and on taska you will have specific one for taska with r.is it should works, I assume
Aleksandar Radunović
@aradunovic
@gotar Thanks man, it works!
Ralf Schmitz Bongiolo
@mrbongiolo
Piotr Solnica
@solnic
yep
I18n is very slow, but we cache it, so it should be a huge difference
it as in message templates, so the lookup is triggered only once
Ralf Schmitz Bongiolo
@mrbongiolo
Uhm
so 2nd requests should be faster?
Nice, really all subsequent request are way faster
Piotr Solnica
@solnic
yeah, I’ll make it faster but it’s gonna be a continues effort spanning multiple versions
I hoped to make it for 0.8.0 but it’s too much work for me in one month
so I’ll start for 0.9.0
I need to rewrite error/hint compilers, basically
Ralf Schmitz Bongiolo
@mrbongiolo
Wouldn't it be faster to store error messages in a JSON file also?
Any reason why rails and a lot of libs prefer yaml for configs?
Luca Guidi
@jodosha
@mrbongiolo I think it was picked as tool in the early Rails days, and then cargo culted
Ralf Schmitz Bongiolo
@mrbongiolo
@jodosha yeah, you're probably right
unless there's some hidden reason somewhere :D
Piotr Solnica
@solnic
well editing yaml is nicer than editing json
Ralf Schmitz Bongiolo
@mrbongiolo
Yeah, a bit, but JSON is better for putting "anywhere" and is reasonably human readable...
Nikita Shilnikov
@flash-gordon
@mrbongiolo you can place json in yo yaml so you can edit json while u edit yaml
yo dawg
Jeff Dickey
@jdickey
Question about Dry::Types::Value, Types::Class, and constraints: is it possible to define a Class attribute in a value object and require that it respond to certain messages?
Ralf Schmitz Bongiolo
@mrbongiolo
@flash-gordon JSON inception style!! hahaha