Where communities thrive

Join over 1.5M+ people
Join over 100K+ communities
Free without limits
Create your own community

Explore more communities

dry-rb/chat

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

People

Repo info

Activity

Feb 24 17:22

Josiassejod1 commented #31
Feb 24 15:36

johansenja forked
johansenja/dry-types
Feb 24 08:36

solnic commented #419
Feb 24 08:32

solnic commented #31
Feb 23 17:32

Josiassejod1 edited #31
Feb 23 17:19

Josiassejod1 labeled #31
Feb 23 17:19

Josiassejod1 opened #31
Feb 23 17:19

Josiassejod1 labeled #31
Feb 23 16:38

robertojnior starred dry-rb/dry-system
Feb 23 16:38

robertojnior starred dry-rb/dry-types
Feb 23 16:35

robertojnior starred dry-rb/dry-system
Feb 23 16:35

robertojnior starred dry-rb/dry-types
Feb 23 12:43

timriley synchronize #158
Feb 23 12:43

timriley on support-component-dirs-with-mixed-namespaces

Update tests (compare)
Feb 23 06:00

timriley edited #159
Feb 23 05:56

solnic commented #159
Feb 23 02:57

Neo35567 starred dry-rb/dry-types
Feb 23 02:24

mahmoudimus starred dry-rb/dry-types
Feb 22 12:44

timriley synchronize #158
Feb 22 12:44

timriley on support-component-dirs-with-mixed-namespaces

Update component unit specs (compare)

Tim Cooper

@coop

The idea of hashes is fine, we do something similar for event sourcing, each aggregate keeps list of events to persist to the database which are effectively an array of hashes.

We wrote so much code that is similar to dry-types.

Tim Riley

@timriley

heh

Tim Cooper

@coop

All of our events are typed… We enforce types when constructing events. I’ve tried substituting for dry-t and dry-v but it’s quite a lot of work. It will be worth it because dry-t and dry-v integrate so nicely, we’ll be able to delete a lot of code at the end.

Tim Riley

@timriley

Cool, that’ll be nice to get in place :)

Andy Holland

@AMHOL

hanami/validations#98

Fran Worley

@fran-worley

@AMHOL Some sound arguments, it's just a shame that there can't be some kind of consensus amongst rails alternative ruby 'frameworks'.

Andy Holland

@AMHOL

@fran-worley Yeah, the point about not being able to wrap the API was the only real valid argument IMO, but each to their own I guess

Fran Worley

@fran-worley

@AMHOL I can kind of see the argument for having lots of dependencies but if it keeps code DRYer then why wouldn't you...

Andy Holland

@AMHOL

Yeah, I think the adding more gems argument is a non-issue

Fran Worley

@fran-worley

I'd rather have 30 small dependencies that use each other than 5 large ones that have to re-implement common functionality. I just appreciate that others don't agree.

Andy Holland

@AMHOL

Unless those gems make changes to the runtime environment

:+1: * :100:

Fran Worley

@fran-worley

Yeah. Also the point about the wrapable API, isn't this being addressed to some degree by the discussions on custom input processors and Error handlers

and surely there is nothing to stop you writing your own macros to reintroduce the validates :title, :presence type syntax ?

Simon Schmid

@sled

I'm currently working on something like dry-activemodels, basically composes the errors and output of a schema to an activemodel

(error messages, output hash) => activemodel and (full type) => activemodel

some simple delegations

but getting attribute translations and form builder compatibility :)

Andy Holland

@AMHOL

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

Simon Schmid

@sled

I think the only external gem dependency of dry-* is the Kleisli gem

Andy Holland

@AMHOL

Also concurrent-ruby

Simon Schmid

@sled

yep concurrent-ruby is a beast ;)

Andy Holland

@AMHOL

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

I can't wait to see what Tim does with https://github.com/icelab/dry-web-skeleton tho, hopefully will be able to get the full stack running on top of dry and rom soon

Fran Worley

@fran-worley

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.

Andy Holland

@AMHOL

Oh cool, I guess I missed that

Fran Worley

@fran-worley

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.

Tim Riley

@timriley

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)

Tim Riley

@timriley

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

Andrew Kozin

@nepalez

@timriley thanks! with my rungnish writing a post is too time-consuming challenge. I'd postpone it to the weekend

Tim Riley

@timriley

@nepalez no worries, take your time :) BTW, if you need a hand with proof-reading/minor editing, I'm happy to help.

Tim Riley

@timriley

dry-web just got its first rubygems release: http://rubygems.org/gems/dry-web

Tim Riley

@timriley

I also started documenting the skeleton that we use for icelab dry-web projects: https://github.com/icelab/dry-web-skeleton

Fran Worley

@fran-worley

@timriley looks good I'll try and find the time to have a play with it at the weekend!

Tim Riley

@timriley

@fran-worley cool! Would love your feedback on how things feel. In the next 2 months, I want to focus on massively improving the dry-web experience for newcomers.

S/massively/as best I can/ :)

Tim Cooper

@coop

@timriley https://github.com/hanami/validations/pull/98#issuecomment-212694147

That was a fanatstic reply.

Tim Riley

@timriley

Oh, thanks @coop!

Benjamin Klotz

@tak1n

@timriley awesome, I think I will soon start a toy project with dry-web etc :)

Tim Cooper

@coop

It was a good explaination without touting that “it is better”. Well done.

Fran Worley

@fran-worley

@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!