Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Feb 18 21:30
    ArtemRakov starred dry-rb/dry-monads
  • Feb 18 16:10
    marselmustafin starred dry-rb/dry-monads
  • Feb 18 09:52
    preetsethi starred dry-rb/dry-initializer
  • Feb 17 23:12
    Karnaj starred dry-rb/dry-types
  • Feb 17 23:12
    Karnaj starred dry-rb/dry-monads
  • Feb 16 23:37
    asoules starred dry-rb/dry-system
  • Feb 16 20:37

    dry-bot on master

    [devtools] sync (compare)

  • Feb 16 20:37

    flash-gordon on master

    Update CHANGELOG (compare)

  • Feb 16 20:36

    flash-gordon on v1.3.1

    (compare)

  • Feb 16 20:34

    dry-bot on master

    [devtools] sync (compare)

  • Feb 16 20:33

    flash-gordon on master

    Fix version number (compare)

  • Feb 16 20:32

    dry-bot on master

    [devtools] sync (compare)

  • Feb 16 20:32

    flash-gordon on master

    Update CHANGELOG (compare)

  • Feb 16 20:27

    flash-gordon on master

    Bump version to 1.3.1 (compare)

  • Feb 16 20:26

    flash-gordon on impove-predicate-inferrer

    (compare)

  • Feb 16 20:26

    flash-gordon on master

    Infer hash? predicate for hash … Merge pull request #395 from dr… (compare)

  • Feb 16 20:26
    flash-gordon closed #395
  • Feb 16 20:26
    dry-bot commented #395
  • Feb 16 20:24
    flash-gordon opened #395
  • Feb 16 20:23

    flash-gordon on impove-predicate-inferrer

    Infer hash? predicate for hash … (compare)

Don Morrison
@elskwid
That latest move was a post-rails 4 upgrade, we finally removed all the attr_protected garbage, we’re on strong params but they’re behind some classes with simple interfaces so we can swap out the implementation
Piotr Solnica
@solnic
@elskwid yummy
we're gonna push a major release of dry-v in a couple of weeks, this will be a good moment to try it out
Don Morrison
@elskwid
shove the mess in the corner, deal with the mess later
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