dry-rb/chat

WE MOVED TO ZULIP => https://dry-rb.zulipchat.com <=

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)?

Chase Gilliam

@Ch4s3

I'll talk it up at my local Ruby group soon.

Yeah, I can take a look this afternoon.

Where communities thrive

People

Repo info

Activity