Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 05:53
    technofreak starred dry-rb/dry-monads
  • 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
Piotr Solnica
@solnic
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)?
Chase Gilliam
@Ch4s3
I'll talk it up at my local Ruby group soon.
Yeah, I can take a look this afternoon.
Piotr Solnica
@solnic
cool man, thank you. it’s in a gist right here
it’s a short one ;)
Chase Gilliam
@Ch4s3
Excellent! I didn't just volunteer to proof a novel!
off topic have you looked at Helix/Rust?
Piotr Solnica
@solnic
I did, it doesn’t support modules so I couldn’t use it, I asked about module support in an issue, no reply so far
Chase Gilliam
@Ch4s3
Helix you mean?
Piotr Solnica
@solnic
si
Chase Gilliam
@Ch4s3
Yeah, they seem to have a sort of stable proof of concept. I'm watching eagerly. It hits a sweet spot for me that I think JRuby sort of works for, but I just don't like the ffi with Java very much
Piotr Solnica
@solnic
yeah I’m super excited about this, we can make tons of stuff multiple times faster
Chase Gilliam
@Ch4s3
Yeah, agreed. And Rust is much nicer to work in than C, and I feel like once I know it I'll probably prefer it to Java.
I wonder if it would be faster for writing validation code since it has pattern matching
Chase Gilliam
@Ch4s3
@solnic If I have notes on the article, do you just want them in comments, or direct message here?
Piotr Solnica
@solnic
comments are ok :)