Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 12 21:34
    flash-gordon commented #376
  • Dec 12 21:34
    flash-gordon labeled #376
  • Dec 12 21:34
    flash-gordon opened #376
  • Dec 12 19:32
    RyanLafferty starred dry-rb/dry-types
  • Dec 12 05:53
    technofreak starred dry-rb/dry-monads
  • Dec 12 00:14
    thekuwayama starred dry-rb/dry-monads
  • Dec 11 09:29
    blasterun starred dry-rb/dry-monads
  • Dec 11 08:34
    flash-gordon closed #115
  • Dec 11 08:34
    flash-gordon commented #115
  • Dec 11 08:31

    flash-gordon on v1.3.3

    (compare)

  • Dec 11 08:30

    flash-gordon on master

    Bump version to 1.3.3 (compare)

  • Dec 11 08:30

    flash-gordon on master

    Update CHANGELOG (compare)

  • Dec 10 23:46
    johnmaxwell commented #116
  • Dec 10 21:54

    flash-gordon on master

    Halt with mutable backtrace Ex… Merge pull request #116 from jo… (compare)

  • Dec 10 21:54
    flash-gordon closed #116
  • Dec 10 21:54
    flash-gordon commented #116
  • Dec 10 21:49
    johnmaxwell commented #116
  • Dec 10 21:47
    johnmaxwell commented #116
  • Dec 10 21:43
    johnmaxwell commented #116
  • Dec 10 21:39
    johnmaxwell commented #116
Alexander Gräfe
@rickenharp
Yes, allthough a lot of that legacy was an ad-hoc implementation of dry-transaction functionality.
Piotr Solnica
@solnic
you can also override .new and put custom logic there
in general, we're trying to promote objects that don't need any state except external dependencies and/or configuration
so ie we don't do Validator.new(data).call and instead just v=Validator.new;v.call(data)
Alexander Gräfe
@rickenharp
Yeah, that’s what I have gathered. But try selling that to people who are buried deep in the Rails Way… :sigh:
Piotr Solnica
@solnic
so object graphs that are being created and exposed by the container don't hold data-as-state
well, that's OO way, not just Rails :)
it's hard to get out of this mindset, been there done that ;)
separating data from logic was one of the greatest improvements for me lately
Alexander Gräfe
@rickenharp
It’s not even OO, because the people I deal with don’t like having ‘all those classes’.
Piotr Solnica
@solnic
yeah I hear you, it's a common attitude "more concepts, too complicated", but it's only an impression
Nikita Shilnikov
@flash-gordon
I came to this after reading four books about clojure :)
Piotr Solnica
@solnic
I started doing that in ruby along with ditching mutable objects, so it was a natural consequence
Alexander Gräfe
@rickenharp
I’m avoiding learning more about other programming languages until after this project, it would just make me sad… :D
Piotr Solnica
@solnic
then I started looking into clojure and my thinking about this became less blurred :)
the trouble with data/logic in OO was that people treated data as something messy, so hiding it behind objects that "just send messages" was supposed to safe you from having to deal with that messy data
the problem with objects "just sending messages" is that it's really hard to compose functionality
you end up with complex inheritance hierarchies, object decorators etc
and it's still not really flexible
application-specific data structures are as pleasant to work with as your objects, the trick is to be able to have these data structures in the first place (hint: rom-rb)
if your app is working with raw representation of the data that comes directly from your db, then it's gonna be messy (hint: Active Record)
Tomek Rusiłko
@rusilko
Hey, I’ve looked around a bit in dry-* space and have few questions/observations regarding dry-validations-rails integration thingy (pls don’t mind if some are super obvious):
  1. dry-v library would shine mostly as a replacement for AM validations, since that’s where validation logic is used.
  2. Strong params is just a whitelisting of attributes without rule checking, just require/permit kinda thing, right?
  3. I understand we want to keep them separated, that is validation in models and whitelisting in controllers?
  4. Or maybe we actually want to pull out validation logic from models and do the validation in the service called from controller directly (using dry-v below ofc)? In such a case maybe it could be combined with strong params functionality?
  5. In any case the question is that if a dev uses dry-v for strong params it would seem strange not to use it for model validations as well… which bring us to the questions of where to put the Schemas and should they be duplicated for strong params / validations ?
  6. From more formal standpoint - we want to do it as a separate gem (sorry, no knowledge in this space)
  7. Should we create a separate chatroom here (less noise)?
  8. @solnic - why “dry-*”? where is this name coming from? Just curious :)
Chase Gilliam
@Ch4s3
@rusilko I think the idea is that some of us are about to start writing a dry-validation-rails
and to your last point I think it comes from the phrase "Do not Repeat Yourself"
Tomek Rusiłko
@rusilko
@Ch4s3 yes, that’s why I am here, I want to help :) My main question is wheter we (or someone) is writing one dry-validation-rails gem to cover both model validations and strong params or rather two separate things?
Chase Gilliam
@Ch4s3
I don't think we've nailed down scope yet
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