Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 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
  • Dec 10 21:31
    johnmaxwell commented #116
  • Dec 10 21:22
    flash-gordon commented #116
  • Dec 10 19:41
    johnmaxwell opened #116
  • Dec 10 19:36
  • Dec 10 10:24
    krautcat starred dry-rb/dry-view
Piotr Solnica
@solnic
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
would be nice to make some buzz and publish some tutorials along with 0.8.0 release
(of dry-v)
Chase Gilliam
@Ch4s3
Ok, I'll put that on the list. I'll pester the channel for specifics as I sit down to write it.
Piotr Solnica
@solnic
speaking about writing, I started on a follow-up after my last week’s rails article. anybody interested in giving me some early feedback (it’s still WIP)?