kw-args on components (kwargs)

[harshdoesdev]

Continued from this discussion, where we were discussing the implementation of fastn test helpers. Some of those helpers allow users to pass additional arguments that were not explicitly defined on the component.

Proposed by @amitu:

The proposal suggests that users should be allowed to pass additional arguments—arguments that are not explicitly defined on the component. Similar to how we handle caption, body, or children, we can instruct the parser to accept these arguments. We can refer to them as kw-args.

-- component foo:
kw-args args:

-- end: foo

Similar to the caption, the default type for kw-args is string. If you want to change the type, you can specify it explicitly:

-- component foo:
integer kw-args args:

-- end: foo

Here, foo.args is a hashmap of string to integer.

We should allow duplicates and handle them similarly to Django's MultiValueDict.

cc: @Arpita-Jaiswal

[harshdoesdev]

@amitu, if a component accepts kw-args, should all the arguments be made part of kw-args, or can a component be allowed to accept both pre-defined arguments and kw-args?

Example:

-- component foo:
kw-args args:
string bar:

-- ftd.text: $foo.bar

-- end: foo

-- foo:
bar: Hello
baz: World

or only this should be allowed:

-- component foo:
kw-args args:

-- ftd.text: $foo.args.bar

-- end: foo

-- foo:
bar: Hello
baz: World

[amitu]

@harshdoesdev what do you think?

[harshdoesdev]

I think both should be allowed.

Reasons:

1. Handling of caption and body arguments (non-KV headers)
2. People may want to define some arguments that are mandatory

[amitu]

What does Python do? What is strict behaviour?

[harshdoesdev]

Python allows both kwargs and standard arguments to be used in the same function.

[siddhantk232]

I like explicit contracts more than this, a component/function should be able to specify exactly what it needs (we have typing in fastn that should allow this). kw-args would also become a pain in implementing IDE tooling (not much pain tho).

fastn is a typed language and shouldn't need this. https://github.com/orgs/fastn-stack/discussions/463 and other proposals should make typing more convenient.

Please give more examples where you think kw-args is absolutely needed.

[amitu]

Can't think of a great use case right now. And I agree we should not implement anything till we have solid use cases. Happy to not pick it in 0.5.

fastn is a typed language and shouldn't need this.

But this is also typed. By default it is Dict<String, String>, but it can be Dict<String, K> also as mentioned.

[amitu]

@siddhantk232 I have implemented ftd.json in the ftd_json branch in fastn repo, but there is a bug in the base ftd parser, because of which

-- ftd.json:
sign-up-url: $lets-talk.sign-up-url

Is producing:

curl http://127.0.0.1:8000/-/auth/config/
{"sign-up-url":{"String":{"text":"$lets-talk.sign-up-url"}}}

I am working on fixing the base ftd's kw-args parser. Since we ftd can only parse without knowing the type, eg:

-- ftd.json:
x: 1

What is the type of 1, and we do not know the answer to this unless we know we have to parse 1 as integer or string etc, I am bascially assuming if you do x: $y, then the type of x will be whatever is the type of y, but if you say x: 1 (without variable reference) then x will be of type string. Tomorrow we can extend kw-args the way we have extended caption, so kw-args<string> data: we will enforce everything of same type and the type matches whats there.

Things are a bit hazy still tho, kw-args is not going to be same as kw-args<string> as later will enforce every value is tring, where as former as I described I am going to implement, string will only be used for where we have not used the reference. kw-args<any, string>, kw-args<any, integer> and kw-args<string> etc. Then we are capturing both semantics, always given type or if no type is specified use given type.

But then we should look at use cases, and I feel so far the only use case that makes sense (for ftd.json is kw-args meaning use precise type if var is referenced, else default to string), and for map like stuff we need kw-args<$type> semantics, where all values must of of $type. I cant find the use case of kw-args<any, integer>, so we can say we will keep kw-args and kw-args$<type> only and never kw-args<any, integer>.