Next-gen ruby libs! » github.com/dry-rb » website: https://dry-rb.org » forum: https://discourse.dry-rb.org
Hi @timriley , I just finished your series of blog posts on dry/roda/rom and really enjoyed them. I'm looking forward to their continuation :)
@garrettlancaster thanks! I had a wee break because of RedDotRubyConf but I’ll be back on the blog train again next week.
@garrettlancaster if there’s anything in particular you’d like to see, let me know and I’ll add it to the list.
Glad to hear it!
As far as things I'd like to see, I've always found permissions/access to be poorly organized in most applications. I've often thought about using the container concept to inject validations and access policies dynamically on a per-request basis, but I would be curious what strategies you've found for appropriately isolating those concerns in an extendable way.
That’s actually something I’m yet to do in any serious way. But as soon as we encounter such a requirement in one of our apps, I’ll share our approach.
I’d imagine the injection approach would allow for it to be handled quite cleanly.
My impression was that dry-containers are set up statically at boot time, is there room for that approach here?
@garrettlancaster my original intention was for dry-container to register the request with the container and manipulate it in custom classes in Roda
But it didn't work out, it's better to keep any stateful objects out of the container, so that's why the currying was added when you register using a block with arguments
It simplifies things a lot
So static setup during boot is the best option IMO
@garrettlancaster I was messing about with policies a while ago https://gist.github.com/AMHOL/b0f3e3c3e7b34c155acdddda3eee6f2a
@timriley Going by a typical "roles & permissions" paradigm: after authorizing the user, a role-specific container would be used for the remainder of the request. If user-level permissions were present, I suppose that might affect the specific injections provided in that container.
@AMHOL interesting, will need to dig into that a bit
@garrettlancaster ahh, interesting take. Perhaps rather than providing different containers, what might work instead Is providing a "resolver" for a specific role that returns a bunch of role-specific objects to use...
You end up with race conditions when you put request state into the container
i.e.
# request 1
container.register(:request, request)
# request 2
container.register(:request, request)
# request 1
container[:request].redirect '/home' # request 2 user gets redirect
I started trying to solve it by having a detach method on the container, but I found the best option is just not to do that :p
Functional objects in the container with simple input => output is the way to go
@timriley could you be more specific about which "objects" you are thinking about?
@AMHOL you're right, it would be unfortunate to depend on the full build-up and tear-down of the entire world on each request
@garrettlancaster any objects in your system that you wanted to vary by role
@garrettlancaster you were talking about having whole role-specific containers, which I presume would be filled with objects that are for that role
@timriley Sorry, my thinking is a bit unclear as this is unfamiliar territory. So are you suggesting that rather than injecting e.g.
MyContainer['validate_article'] I would inject MyArticleValidationResolver.new into any operations that needed it?
@timriley and then the operation itself would do something like
validator = validator_resolver.(params); validator.(params)
Dinner time, gotta run but will check back later. Thanks again for all the great work you guys are doing, it's the first hint of a practical feeling solution to all of the Rails woes we're all too familiar with.
The other day someone answered a question on "inheriting" a base validation schema and adding additional rules. Now I want to do that too, but I can't find the answer again (gitter search is terrible!). Anyone who can help me out? (What I actually want to do is have a base "AddressSchema" and then a "TemporaryAddressSchema" with the same rules but also require a start and a stop date.)
def self.Schema(base = Schema, **options, &block)
Forget that, found the spec and it was super simple. :smile:
@timriley I didn't see your answer before posting! Didn't intend to dismiss it - it was exactly what I needed even if I figured it out almost exactly at the same time! So thanks!
Instead of :
time_op = TimeMath().ceil(:week).advance(:hour, 10)
What about :
T=TimeMath()
T().next_week + T(10).hours
@cmrichards the downside is that you create objects too many times instead of just defining your calculation once and calling it many times at run-time
The upside is that it doesn't pollute core objects and feels more intuitive (to me) to use
as in lack of global TimeMath method
you could report an issue and ask about that
it’s an alpha-stage lib
So a monad is basically an object that wraps a returned object from a method and adds additional state that relates to the success or failure of that method?
great primer about monads in ruby right there ^
@cmrichards this was taken from kleisly gem, but the name Left is more ... uhm canonical anyway. You don't have to think about Left as something wrong actually, it's just a common case
so we added helpers
#success? and #failure? for that
Go right for happy path, left for bad path
For a programmer who doesn't know monads, looking at Left() won't mean anything. It seems a bit arbitrary
@cmrichards this ain’t random, it’s from Haskell https://hackage.haskell.org/package/base-4.9.0.0/docs/Data-Either.html
speaking for myself, that's what I gathered, but are we expecting people to be comfortable with Haskell idioms to use this Ruby library?
I think it's better to call the things with their common names, otherwise those who know about monads will come and ask us why?
But there's also a case for being consistent wth existing ideas
and Success/Failure is for Try monad so there’s that too
but that has a bit more implicit knowledge to most Rubyists, I think; methods by those names are used in other libraries and carry plain-English connotations for the meaning of "success" and "failure". Left and right are navigational terms, not logical terms
mixing metaphors
It's maybe worth noting that Rust's equivalents use Ok/Err and Some/None
not sure about Some/None, it’s for maybe values, not control flow
Left/Right is great for control flow, and I think these names fit prefectly, like Andy said, it’s like going down the execution path and deciding where to go, left when it’s bad, right when it’s good
agreed; but I see on RubyGems that over half of Kleisli's downloads to date are from the current version, and I'd bet that a very large subset of those are thanks to dry-rb's use of it
that's fine if you happen to be right-handed :P
but I get it now; I didn't when I first read up on Kleisli
well, we use it for control flow in dry-transaction, it’s a great pattern, I don’t think monads will ever become a standard way of writing ruby all-the-time so…there’ that
true. And, given that I don't have a better idea sitting here at the moment, fine :)
diverging from that would be rather bad
I understand the argument you're making, and I recognise that introducing a new idiom into an existing, highly idiomatic language is always fraught, so yeah; I'll go with the left/right flow here
Seems like it's only the convention that Right is success and Left is failure. Really, Either just means that there are two possibilities, so Left and Right seem fine for that.
jdickey @jdickey crawls back under rock; makes more popcorn
I suggest to create dry-burritos gem that will hold all of them :) I mean we need to wrap this scary
monad word with sutin more usual
jdickey @jdickey throws hot popcorn at @flash-gordon
yeah, fine, how about this; we keep Left and Right as loanwords from Haskell until/unless someone comes up with lower-friction synonyms/aliases for same. Who knows, they might actually catch on
maybe even open that as an issue for further comment along the line
@jdickey I don't remember really where I found it, but that's the old joke, not mine :) Along with "A monad is just a monoid in the category of endofunctors, what's the issue?" :)
no. don't. go. there. I just finished cleaning up the grue from the last time my head exploded on a project discussion :P
not to mention that the actual event is painful as hell
I've had the same thoughts RE Left/Right, I think Success/Failure is the obvious alternative
@AMHOL they are not, Success/Failure is for handling exceptions
also common in other langs: http://www.scala-lang.org/api/2.9.3/scala/util/Try.html
and basicaly Success acts like Right, and Failure as Left, since the monad interface is common
which is what makes it so great
There’s real value is using the right terms for concepts/structures/etc. i.e. map, fold, reduce, etc.
Even if we have to go learn. :wink:
of course, "the right terms" are context-dependent :P
I just felt like saying something...
wanted it to sound deep
did it work?
elskwid @elskwid waits
there might just be an Ugly Bug Monster sitting at the bottom of the chasm feeding on our flailing :D
i am using dry validation for accepting params in place of rails strong params. How can i use it to accept nested attributes ?
found it ..
Thanks :)
If I get a response from an api that returns something like this
{data: [{_type: 'user', ...}, {_type: 'group', ...}]} is there a way to get dry-types to pickup on the _type property for each returned entity and properly deserialize the json into the correct objects?
@solnic so I would basically need to remove the data attribute from the json hash, and then manually iterate, and add those to the main response object?
Using
dry-result_matcher and dry-monads, how would you handle two different failure scenarios? For example, say that you are updating a record and you need to retrieve the record from the DB before updating it. If the record is not found you want to return a 404 status code and if the update is not successful, you want to return the status code 422 + error payload.put '/people/:id' do
UpdatePerson.new(declared(params, include_missing: false)) do |m|
m.success do |person|
person
end
m.failure do |errors|
# check the content of Left and decide?
status 422
errors
end
# code another block to handle 404?
end
end
I see that you have already discussed it here dry-rb/dry-result_matcher#3
@wilsonsilva yes it's gonna be a new feature in the next release :) Tim is wrapping it up
@dnd ok I guess I didn't get what you want to do :) wdym by
pick up on the _type property
@solnic if while deserializing
data it came across {_type: 'user', name: 'bob'} it would create an a new instance of User, basically doing User.new({_type:'user', name: 'bob'})
@wilsonsilva thank you :) although technically speaking dry-result_matcher and dry-monads were created by Tim and Nikita, respectively :D
@wilsonsilva iirc Tim is going to push new matcher stuff ~tomorrow so stay tuned!
@wilsonsilva @solnic yep, I’ll try for the next couple of hours!
Code’s ready. I’m going to rename it to dry-matcher now, then do docs.
@solnic thanks for your contributions to the reddit comments for my RDRC talk :pray:
Now that I think about it, feels like we could build a solid FAQ section based on responses like yours that you’ve had to write!
I want to validate the following yaml file using dry-validation 0.7
remote_printer:
pusher:
secret: 'xxx'
key: 'yyy'
pid: '1'
presence: 'zzz'
labels_printer:
name: 'ZEBRA'
port: 'COM4'
receipts_printer:
name: 'BIXOLON'
port: 'COM5'labels_printer and receipts_printer are optional, but when any of them is present I need to validate that name and port are present too. Any hints?
@hectorsq
optional(:labels_printer).schema { key(:name).filled(:str?); key(:port).filled(:str?) }
you could also pull that out into a re-usable schema and just do
optional(:labels_printer).schema(PrinterSchema)