Fork me on GitHub
#yada
<
2016-06-14
>
jonathanj13:06:11

In this example https://yada.juxt.pro/manual/030_hello.md (in the “Parameters” section specifically) the say-hello function has explicit knowledge of the path in the context to find the parameters.

jonathanj13:06:38

Is this how everyone does this? I would have imagined that it’s not too interesting to know whether your :name parameter came from the query string or the path or the body.

dominicm13:06:07

@jonathanj: In this simple case it might not make sense. But if you have overlap in query params and path it might. I'm sure @malcolmsparks will whoop me for using (probably) the wrong http verb, but: POST /user/foo/change-name?name=bar

dominicm13:06:37

Also, for POST and such, I find it's pretty important to make sure the params are in the body.

jonathanj14:06:01

@dominicm: Typing my question out loud did actually cause me to think about that.

jonathanj14:06:00

I guess you could always write some higher-order functions to wrap lower-level functions to keep them nicely isolated.

dominicm14:06:13

Bingo ^^ I was just about to say this.

dominicm14:06:28

I also believe there is a generic parameter you can use which is all of them merged.

dominicm14:06:42

But essentially, yes, it's all about what abstraction you want to program at. My "cathedral architecture" centers around having yada extract the parts from http for me, and me calling out to .lib or .impl namespaces to do the heavy lifting.

jonathanj14:06:06

Yeah, that sounds like the kind of approach I’d prefer.

jonathanj14:06:25

It makes testing things easier without getting the details involved.

dominicm14:06:27

Some people like to do "The framework is your application" where everything is inside the resource/handler, which (again, depending on your abstraction) would probably want to pull out of the "master parameter"

dominicm14:06:45

For me, http handlers are focused on: - Pulling out parameters and "input" - Passing off implementation - Formatting result for client.

jonathanj14:06:16

I feel exactly the same way.

malcolmsparks18:06:36

I don't have very strong opinions about whether to merge parameters into a single map. It gets messier with form, header and body params. Merging is lossy and unmerging painful. Duplicating has trade offs too: the context gets big which makes printing/logging it less attractive. So I'm siding with @dominicm right now. Yada tells you where those params came from. Merging together would be easy enough in user space. You could even do this via a custom interceptor. Although I could be persuaded by an argument from convenience. Decisions decisions!

jonathanj19:06:32

@malcolmsparks: I think how it is now is better. After asking my question out loud I realised that the operation would be difficult if you did want to know where the params came from or cared about using params from a specific source.

malcolmsparks20:06:58

Another reason for today's behavior is: what would happen if you had a query param called 'query' or 'path'. Once yada has namespaced keys (advocated by Rich) this is less of a problem.