haxetink / tink_querystring

Macro powered query string parsing and composition.
The Unlicense
11 stars 7 forks source link

Anon object flavor #6

Open kevinresol opened 7 years ago

kevinresol commented 7 years ago

I am working with some API that expects key value pair to be expressed by brackets:

i.e. {obj:{key:'value'}} would be obj[key]=value

Should there be an option for that?

back2dos commented 7 years ago

Yeah, this one bit me already. Workaround: define a Client that will split each entry in the query string by . and wrap all but the first part in brackets. But yeah, we should properly support this ^^

kevinresol commented 5 years ago

We also need to support Map/DynamicAccess here.

If I am into it, where should I start with?

kevinresol commented 3 years ago

I am choosing between a compile-time solution or a runtime solution:

@back2dos any suggestions?

back2dos commented 3 years ago

Mhh, I think the performance difference will probably be negligible.

But in the context of tink_web you can't really access the query string builder or parser. So I would assume that typedefs would be annotated to recursively use one style or another, no?

kevinresol commented 3 years ago

Yeah, on the other hand I actually want to introduce something more flexible to tink_web in contrast to the current hardcoded approach on the reader/writers. A really rough illustration:

@:put
@:queryBuilder((obj:QueryObj) -> tink.QueryString.build(obj))
@:queryParser((query:tink.url.Query) -> tink.QueryString.parse(query))
@:bodyBuilder('application/json' => (obj:BodyObj) -> tink.Json.stringify(obj))
@:bodyParser('application/json' => (body:Chunk) -> tink.Json.parse(obj))
function foo(query:QueryObj, body:BodyObj):Noise;
back2dos commented 3 years ago

I like that idea.

OTOH, let's not lose sight of the use case that prompted this: picking a specific object syntax flavor. When that's all you want, this level of configuration induces quite a bit of noise. Basically, these two accomplish the same:

The former also allows to consistently apply the same flavor for something like a set of search params available across a whole API or to use the information in something like a macro based form builder.

In any case, the two approaches are in no way mutually exclusive. The former (type based) can definitely be implemented via the latter (adhoc config based).