Ancestors

Toot

Written by Stephann V. on 2025-01-30 at 22:04

I think I was trying Hanami with wrong mindset. I was trying to replicate the same things I used to do in Rails apps, but now I'm trying to learn the Hanami-way before I start to tweak some things.

[#]hanami

=> More informations about this toot | More toots from ste@ruby.social

Descendants

Written by Mike Perham :sidekiq: on 2025-01-30 at 23:37

@ste I would love to read a blog post about the differences. Do you have a blog?

=> More informations about this toot | More toots from getajobmike@ruby.social

Written by Stephann V. on 2025-01-30 at 23:47

@getajobmike Not yet. I'm planning a talk about Hanami for a local Ruby community, who knows this might become a blog post in the future.

=> More informations about this toot | More toots from ste@ruby.social

Written by Sean Collins on 2025-01-31 at 02:58

@ste Ah cool. I’d love to hear your experience of what The Hanami Way is! I have some ideas about this too and I’m sure there’s much overlap but I bet we have distinct insights and preferences too.

=> More informations about this toot | More toots from cllns@ruby.social

Written by Stephann V. on 2025-01-31 at 12:20

@cllns the first thing I noticed was that the validation happens at http layer, but I'm not sure about this decision, because I think it can became complex when you need to mix with other type of validations (eg. uniqueness) and give feedback to user. So I think moving the validations to operations layer could make sense, but I'm could not integrate operation with validation contract, so I had to create a inner Contract class.

=> View attached media

=> More informations about this toot | More toots from ste@ruby.social

Written by Damian C. Rossney on 2025-01-31 at 12:56

@ste @cllns

There are other reasons for moving validations to the operation layer: because parameter handling is a business concern, not a framework concern.

I've heard @timriley express the view pushing validation to the farthest boundary is a way to protect your code from invalid values. @katafrakt said the same thing just recently. I would prefer to emphasize the business logic layer and keep actions boring. 😉

I hope it's okay if I follow along.

=> More informations about this toot | More toots from dcrossney@ruby.social

Written by Paweł Świątkowski on 2025-01-31 at 13:11

@dcrossney In years I discovered that most apps have two kinds of validation:

1. "Structural" validation that protects you from people doing abuse to you entry points and, for example, sending array where boolean is expected (or integers larger than reasonable). This makes sense to check as early as possible (i.e. action).

2. Semantic validation (I also use names "business invariants" or "integrity checks") that makes sure the data makes sense during the operation.

@ste @cllns @timriley

=> More informations about this toot | More toots from katafrakt@ruby.social

Written by Paweł Świątkowski on 2025-01-31 at 13:14

@dcrossney I would say @ste is right with the feeling that mixing them together in HTTP layer is wrong. That's a subset of larger issue: that mixing them is, in general, wrong.

The fact that we want to return all errors together to a user is mostly a knee-jerk reaction from doing that for years. There's actually nothing wrong in doing it in steps: if there are failures of type 1, show just them. Email-uniqueness check does not need to fire if the email is in the wrong format.

@cllns @timriley

=> More informations about this toot | More toots from katafrakt@ruby.social

Written by Paweł Świątkowski on 2025-01-31 at 13:16

@dcrossney btw this distinction in web dev context should be quite familiar, because it's the difference between HTTP 400 and HTTP 422. @ste @cllns @timriley

=> More informations about this toot | More toots from katafrakt@ruby.social

Written by Paweł Świątkowski on 2025-01-31 at 13:18

@dcrossney but then some frameworks made really huge effort to convince us that there is no difference between someone sending "false" as an email and the fact the you cannot add line items to an order that is already completed in terms of validation. @ste @cllns @timriley

=> More informations about this toot | More toots from katafrakt@ruby.social

Written by Stephann V. on 2025-01-31 at 14:25

@katafrakt thanks for sharing your thoughts. It makes total sense. Maybe I need to think a structure to validate data in different layers and show errors in a unified way to the user

=> More informations about this toot | More toots from ste@ruby.social

Written by Damian C. Rossney on 2025-01-31 at 13:25

@katafrakt @ste @cllns @timriley

Thank you for elaborating! I appreciate that wisdom.

My thought is that if I keep the action layer as thin as possible (just know the right operation(s) to call and what view to display as a result), then I can do both in the same place.

I like the locality of related behavior. I also like that the params block provides a kind of "type" definition for the operation. This could be used by LSPs to provide annotation and cli/IDE feedback while developing.

=> More informations about this toot | More toots from dcrossney@ruby.social

Written by Paweł Świątkowski on 2025-01-31 at 14:25

@dcrossney I haven't really figured about dry-operations and how they fit in the larger picture. But if we take your approach, won't actions become "unnecessary" proxy layer for the router? I mean, they are already separate classes, I think it makes sense to give them some responsibility.

But I feel that it's all very context-dependent and there are no simple answers.

@ste @cllns @timriley

=> More informations about this toot | More toots from katafrakt@ruby.social

Written by Damian C. Rossney on 2025-01-31 at 14:48

@katafrakt @ste @cllns @timriley

I'm still exploring. I see Actions as handling "http concerns": request/response-related things.

Right now, my actions generally call two interactors: "get user," plus whatever resource the request needs. Then they figure out the view to display.

If the view needs more info, I think I'll call additional interactors from the View (not the template 🙄 ). Eventually some of these additional items will be lazy-loaded with htmx.

(@ste sorry for hijacking)

=> More informations about this toot | More toots from dcrossney@ruby.social