Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Feb 22 20:32

    dry-bot on master

    [devtools] sync (compare)

  • Feb 22 20:32

    dry-bot on master

    [devtools] sync (compare)

  • Feb 22 20:32

    dry-bot on master

    [devtools] sync (compare)

  • Feb 22 20:32

    dry-bot on master

    [devtools] sync (compare)

  • Feb 22 20:32

    dry-bot on master

    [devtools] sync (compare)

  • Feb 22 20:32

    dry-bot on master

    [devtools] sync (compare)

  • Feb 22 20:32

    dry-bot on master

    [devtools] sync (compare)

  • Feb 22 20:32

    dry-bot on master

    [devtools] sync (compare)

  • Feb 22 20:32

    dry-bot on master

    [devtools] sync (compare)

  • Feb 22 17:27
    dskecse starred dry-rb/dry-monads
  • Feb 21 12:45
    sadjow commented #344
  • Feb 20 17:31
    jswanner commented #141
  • Feb 20 06:15
    lazebny starred dry-rb/dry-types
  • Feb 19 22:35
    solnic commented #141
  • Feb 19 22:32

    solnic on v0.17.0

    (compare)

  • Feb 19 22:32

    solnic on master

    Bump dry-system to 0.17.0 (compare)

  • Feb 19 22:31

    solnic on 141-fix-compat-with-dry-configurable

    Bump dry-system to 0.17.0 (compare)

  • Feb 19 22:31

    dry-bot on master

    [devtools] update changelog.yml… [devtools] sync (compare)

  • Feb 19 22:27

    solnic on 141-fix-compat-with-dry-configurable

    (compare)

  • Feb 19 22:27

    solnic on master

    Fix compatibility with dry-conf… Merge pull request #142 from dr… (compare)

Don Morrison
@elskwid
Excellent!
@solnic gotta love that kind of work
It’s what careers are made of
Piotr Solnica
@solnic
this type of refactoring is really healthy for an app, even if you don't change how it works under the hood (ie you still use the same libs) what you achieve is a narrower, app-specific interface :)
Don Morrison
@elskwid
yessir!
give it a name, give it a place, rinse, repeat
Piotr Solnica
@solnic
:)
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!