Next-gen ruby libs! » github.com/dry-rb » website: https://dry-rb.org » forum: https://discourse.dry-rb.org
@Ch4s3 thanks, yeah I’ll be adding some ‘sum up’ paragraph thanks :)
re promoting our libs, not sure, maybe it won’t hurt to do it :) i was thinking about writing a separate post about some of libs and explain “what and why” there, but a quick mention here would be cool I guess
http://solnic.eu/2016/05/30/abstractions-and-the-role-of-a-framework.html
^^ a follow-up to my prev post, related to what we’re doing here
I’ve been meaning to ask you for some examples of how you’ve actually used pub/sub with your transflow transactions
monad approach is more straight forward, but there are use cases for pub/sub, but my brain is elsewhere now so hard to come up with a concrete example
No worries. I’ll file an issue at some point so we can share some examples.
Actually, let me do that now.
What’s the point behind the auto-registration in dry-component? Since the key is derived from the filenames, I don’t see the big win that Application['logger’] gives you over using Application::Logger. I do get why dry-container is great, but there you can use generic keys, that you can point to different implementations without having to change those classnames all over your codebase.
and it's not enforced, so don't use it if you don't like it :)
Well, the problem is, I have introduced the people at my current project to dry-rb, in the hopes they could use it to cleanup their chthonic legacy rails app. Unfortunately, if something has a feature, they use it… And now I feel obligated to make them use all the nice dry-rb things correctly, while not really understanding everything myself… :sweat_smile:
I used dry-container/auto-inject in a rails app, see my rom-rails-skeleton on github
but I haven't used dry-component in a rails app, no idea if it will Just Work™ in its current form
The biggest hurdle at the moment is instantiating something you get out of dry-container with parameters. Something like Container[’validate’](String) or Container[’validate’](Array)
It’s a dry-transaction step that should validate its input against the given class. I told them to use explicit StringValidator and ArrayValidator steps, but apparently that is ‘too much typing'
Basically, I am doing damage control at the moment :D
you said you're getting objects from the container with parameters
Yes, they used dry-component to define the step objects, and since those are auto-registered, they can’t influence the instantiation of those step objects.
if you need custom instantiation logic, register objects yourself
I understand you're dealing with existing legacy objects?
Yes, allthough a lot of that legacy was an ad-hoc implementation of dry-transaction functionality.
in general, we're trying to promote objects that don't need any state except external dependencies and/or configuration
so ie we don't do
Validator.new(data).call and instead just v=Validator.new;v.call(data)
Yeah, that’s what I have gathered. But try selling that to people who are buried deep in the Rails Way… :sigh:
so object graphs that are being created and exposed by the container don't hold data-as-state
well, that's OO way, not just Rails :)
it's hard to get out of this mindset, been there done that ;)
separating data from logic was one of the greatest improvements for me lately
It’s not even OO, because the people I deal with don’t like having ‘all those classes’.
yeah I hear you, it's a common attitude "more concepts, too complicated", but it's only an impression
I came to this after reading four books about clojure :)
I started doing that in ruby along with ditching mutable objects, so it was a natural consequence
I’m avoiding learning more about other programming languages until after this project, it would just make me sad… :D
then I started looking into clojure and my thinking about this became less blurred :)
the trouble with data/logic in OO was that people treated data as something messy, so hiding it behind objects that "just send messages" was supposed to safe you from having to deal with that messy data
the problem with objects "just sending messages" is that it's really hard to compose functionality
you end up with complex inheritance hierarchies, object decorators etc
and it's still not really flexible
application-specific data structures are as pleasant to work with as your objects, the trick is to be able to have these data structures in the first place (hint: rom-rb)
if your app is working with raw representation of the data that comes directly from your db, then it's gonna be messy (hint: Active Record)
Hey, I’ve looked around a bit in dry-* space and have few questions/observations regarding dry-validations-rails integration thingy (pls don’t mind if some are super obvious):
- dry-v library would shine mostly as a replacement for AM validations, since that’s where validation logic is used.
- Strong params is just a whitelisting of attributes without rule checking, just require/permit kinda thing, right?
- I understand we want to keep them separated, that is validation in models and whitelisting in controllers?
- Or maybe we actually want to pull out validation logic from models and do the validation in the service called from controller directly (using dry-v below ofc)? In such a case maybe it could be combined with strong params functionality?
- In any case the question is that if a dev uses dry-v for strong params it would seem strange not to use it for model validations as well… which bring us to the questions of where to put the Schemas and should they be duplicated for strong params / validations ?
- From more formal standpoint - we want to do it as a separate gem (sorry, no knowledge in this space)
- Should we create a separate chatroom here (less noise)?
- @solnic - why “dry-*”? where is this name coming from? Just curious :)
@rusilko I think the idea is that some of us are about to start writing a dry-validation-rails
and to your last point I think it comes from the phrase "Do not Repeat Yourself"
@Ch4s3 yes, that’s why I am here, I want to help :) My main question is wheter we (or someone) is writing one dry-validation-rails gem to cover both model validations and strong params or rather two separate things?
there's room for everyone, so stay tuned in the channel
:)
how is “nailing down scope” happening usually, do you guys discuss everything here?
@rusilko I'm busy with work so I'll answer all questions later, re
why dry - we just wanted something short ;)
is there some rule of thumb when deciding if something should be a separate transaction step or just included into some operation?
take validation for example…do you validate in
take validation for example…do you validate in
CreateSomething operation or define it as a :validate step in transaction?
maybe dry-v could be used in a similar way that Hanami uses it on its actions, it acts like strong_parameters + validator
@aradunovic I tried validations as standalone steps in transactions but found it was a level of granularity that wasn’t helping. Our most common commands are mostly built around validate+persist and it made sense to combine them. The validation feels closely related to preparing the data for persistence.
The side benefit was that I didn’t have to define hundreds of transactions. This leaves the transaction level for truly complex, truly multi-step things.
@solnic if possible, take a look: https://gist.github.com/solnic/6030ad52c7600257ed09d13537f4f498 - thank you