but getting attribute translations and form builder compatibility :)
Well you could build an entirely custom API and make use of the AST in theory, but I think Luca would rather spend the time implementing a similar validation library from scratch, rather than go to that effort and have the underlying dependencies too
Be interesting to see what Piotr thinks when he gets back though, I'm not all that familiar with dry-validation myself
I think the only external gem dependency of dry-* is the Kleisli gem
yep concurrent-ruby is a beast ;)
It is indeed, I preferred thread-safe TBH
But again, people don't want too many dependencies, so lets have a gem for utitility classes, a gem for managing concurrency and a gem for active anything
It would be good to hear Piotr's opinion but I remember him saying a while ago that his vision for Macros was to enable people to build their own. I know that there was talk a while ago of building something into Reform to make the migration to Dry-V easier.
Oh cool, I guess I missed that
I could be wrong and I know that at this stage it's not been explored to its full potential but that combined with custom processors for inputs and errors would in theory allow you to 'wrap' the library.
I think Piotr and Luca may have different opinions on the importance of validation.
I can see Luca's opinion on the API stability front. It's something he's decided to take on, with hanami being a "one stop shop"/all-encompassing solution for developers, something they can rely on above all else.
I guess it's a bit different to how an app using e.g. dry-web or other non-frameworks is put together, where you decide to use whichever gems you want, and then learn/use them directly and keep on top of any API changes they may (or may not) ever need.
(I know that's possible with hanami too, but in offering a full range of functionality as an in-house option, I'd imagine the majority of hanami users would follow that path)
Anyway, the improvements to their validation system look nice! Even if they cover similar ground to dry-v.
I'll release a dry-web gem release today and try to get some minimal docs in our icelab skeleton, @AMHOL :)
I also want to think about what constitutes a viable minimum skeleton too, something perhaps less opinionated than ours (which comes out of the box with things like a background job runner, etc., things that people might not necessarily want).
On dependencies, they're not something people should be afraid of, especially the right type of dependencies :)
@timriley thanks! with my rungnish writing a post is too time-consuming challenge. I'd postpone it to the weekend
@nepalez no worries, take your time :) BTW, if you need a hand with proof-reading/minor editing, I'm happy to help.
@timriley awesome, I think I will soon start a toy project with dry-web etc :)
It was a good explaination without touting that “it is better”. Well done.
@timriley you have the power of words my friend. I avoid trying to put my thoughts in comments as I just sound opinionated... Well said!
@tak1n great! Would love to hear how you go. Let me know if you have question.
BTW, at Icelab we're currently building our now company site as a dry-web app started from this skeleton. It's still very early, but it may serve as a helpful point of reference. It's on GitHub as icelab/berg.
@timriley cool thx :D
I hope to bring our other young example app (icelab/Alpinist) up to date soon too. that one hasn't been touched since December, and we've progressed our dry-web setup a fair bit since then.