Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 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)

  • Feb 19 22:27
    solnic closed #142
  • Feb 19 22:27
    solnic closed #141
  • Feb 19 22:24
    solnic milestoned #141
  • Feb 19 22:23
    solnic opened #142
  • Feb 19 22:23

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

    Fix compatibility with dry-conf… (compare)

  • Feb 19 21:12
    flash-gordon commented #141
  • Feb 19 20:45
    jswanner opened #141
  • Feb 19 20:45
    jswanner labeled #141
  • Feb 19 17:38
    pmackay starred dry-rb/dry-monads
  • Feb 19 17:18
    tomraithel starred dry-rb/dry-types
  • Feb 19 11:51
    yingce starred dry-rb/dry-types
  • Feb 19 11:45
    yingce starred dry-rb/dry-types
Don Morrison
@elskwid
@solnic no problem. Yes, we have been slowly moving legacy cruft into little corners of the app so we can start to use dry libs.
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.