Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Don Morrison
@elskwid
ha
Chase Gilliam
@Ch4s3

@solnic re:

defining schemas in the controllers would be too messy I think, so we could have some simpler and more concise API that would set up validation schemas behind the scenes and cache them (rebuilding schemas on each request makes no sense)

What I do in rails w/ dry-validation is set up a validations folder with schemas in it. What do you think the advantage would be setting them up behind the scenes?

Piotr Solnica
@solnic
oh I was
(sorry pre mature send is premature)
So, I was thinking from a rails user who is used to the slim strong-params api point of view
Andrew Kozin
@nepalez
@solnic could you help, please. I cannot figure out how to idiomatically check whether some object is a dry-type
Piotr Solnica
@solnic
@nepalez first of all, don't :)
did I help? :D
Don Morrison
@elskwid
so helpful
Andrew Kozin
@nepalez
in a sense, yes :)
well, I could back on #[] interface
Piotr Solnica
@solnic
you should
Andrew Kozin
@nepalez
I'd like to drop support for any types except for dry-types in dry-initializer (my bad, this was a mistake)
Piotr Solnica
@solnic
every time you see is_a? in ruby you should consider this as a code smell, I hate it every time I use it :laughing:
you should just rely on #call API
#[] is an alias
Andrew Kozin
@nepalez
yes, you're right. this is why I do not think any more that modules and classes are good candidates for types ;)
Chase Gilliam
@Ch4s3
We could hang schemas on the model. But what about non-ar backed API endpoints?
Piotr Solnica
@solnic
we could have schemas infered from models, but models shouldn't know about schemas
ie it should be possible to have a single schema for a whole model, including nested stuff for associations
dry-v supports optional keys, so that should be possible
and since we're more concerned with defining valid params (from a request pov) only, the we can do it like that
Chase Gilliam
@Ch4s3
Interesting. I'll give that some thought
Tim Riley
@timriley
Success with dry-rb/dry-auto_inject#16 ! Will PR it with a few extra tests, then move onto refactoring. Nearly 500 lines is too long for a class file :grimacing:
Tim Riley
@timriley
Method#parameters has entirely different data on rubinius :weary:
At least it appears to be a known bug: rubinius/rubinius#3538
We’ll have to fail auto_inject on rbx until that is fixed
Nikita Shilnikov
@flash-gordon
@timriley great job! :+1:
Piotr Solnica
@solnic
it’s pretty cool that we’re contributing to making rbx and jruby better by finding subtle bugs like that :)
Aleksandar Radunović
@aradunovic
Hi all! I have a question about where to register a dependency (core component or sub-app) based on dry-web-skeleton.
My application will consist of JSON API sub-app and admin sub-app.
Now, for API i intend to use Yaks. My intention is to create some kind of wrapper around yaks (maybe called Serialize) which will receive object that needs to be serialized and mapper as #call arguments.
My question is:
Should I register this (Serialize) object in core container or in API sub-app container? I’m in doubt since looking at berg, all “wrappers” are a part of core component, however, in this case, serialization will be performed only for sub-app.
Thanks!
Tim Riley
@timriley
@aradunovic I’ve actually used yaks in one of our other dry-web apps. Here’s how I did it:
require "yaks"

module Main
  class JsonSerializer
    Serializer = Yaks.new do
      # yaks config here
    end

    def call(*args)
      Serializer.call(*args)
    end
  end
end
So then it could be fetched from the Main container as Main[“main.json_serializer”]
This message was deleted
Aleksandar Radunović
@aradunovic
Interesting. I assumed you would auto-inject alredy configured Yaks instance in Serializer.
Tim Riley
@timriley
You could do that too.
But you have to put that instance somewhere.
So your option is to assign it to a constant like I did there, or register it manually with your sub-app’s container.
n.b. with the approach I took, this JsonSerializer basically just “wraps” the yaks instance
so that’s the thing that gets injected into any other object that wants to serialize JSON
Aleksandar Radunović
@aradunovic
Oh, I get it…Like I mentioned previously, I don’t expect to use Json serialization in my other sub-apps. So, is that good enough reason to register Serializer only in API sub-app container?
Tim Riley
@timriley
Yep, as a general rule I try and restrict things as much as possible.
Aleksandar Radunović
@aradunovic
Great. Thank you very much for your help and guidance. I just started exploring dry-web and there are still some things I need to wrap my head around, but IMHO this is truly a great approach!
Tim Riley
@timriley
@aradunovic glad you’re liking it so far!
Chase Gilliam
@Ch4s3
A lot of cool info is accumulating here, it would be awesome to get some of it into the docs, perhaps into some short tutorials.
Piotr Solnica
@solnic
yes we are missing tutorials :(
right now we have usage docs only
and very little API docs, but that’s OK IMO, the libs are unstable
Chase Gilliam
@Ch4s3
Well, it's early days, so that's not a big problem. Maybe I can help doc and write up a bit about dry-validation in prep for dry-validation-rails
Piotr Solnica
@solnic
that would be great