kw-args on components

[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.