Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

named argument support #27

Open
opqdonut opened this issue Sep 16, 2019 · 4 comments
Open

named argument support #27

opqdonut opened this issue Sep 16, 2019 · 4 comments

Comments

@opqdonut
Copy link

It would be great if tempura supported named arguments, for example like "Hello %{name}! How are you?" or perhaps "Hello {name}!"

I could write a PR for this. Any opinions on what the syntax should be like?

I'd also like to throw errors for unset parameters. Currently with the positional parameters you can supply too many or too few arguments and still get a string. Should strict parameter checking be a confugurable option?

Related: #13

@ptaoussanis
Copy link
Member

Apologies for the slow response! PR welcome. Feel free to propose something re: syntax, can be adjusted if need be.

@aatkin
Copy link

aatkin commented Sep 21, 2023

Hello,

We recently added (experimental) support for named arguments in our project and thought this could be of interest: CSCfi/rems#3181

This was written and tested with Tempura version 1.2.1. The approach used reads named arguments from resource string, turns them into vector indexes and transforms given map argument to vector arguments, and lets Tempura default resource compiler take over (with modified resource and args). I created a small gist that holds the key parts (without noise from domain specific details): https://gist.github.com/aatkin/fabb8fda95014af31d2ea04c5578ceac

Syntax is adjustable, we chose %:keyword% for initial version as it resembles vector index arguments somewhat.

@ptaoussanis
Copy link
Member

@aatkin Hi Anssi, thanks a lot for this! 🙏

Some initial feedback:

  • Could you please share some examples of resources and output, including resources with backtick escapes?
  • What's the behaviour when a given keyword doesn't exist?
  • Just checking: has this been tested on both Clj and Cljs? (Regex behaviour sometimes varies, for example).
  • You mention that this is "experimental" - in what way exactly? How ready do you feel the current approach would be for a potential Tempura PR?

Cheers! :-)

@aatkin
Copy link

aatkin commented Sep 21, 2023

@aatkin Hi Anssi, thanks a lot for this! 🙏

Some initial feedback:

  • Could you please share some examples of resources and output, including resources with backtick escapes?
  • What's the behaviour when a given keyword doesn't exist?
  • Just checking: has this been tested on both Clj and Cljs? (Regex behaviour sometimes varies, for example).
  • You mention that this is "experimental" - in what way exactly? How ready do you feel the current approach would be for a potential Tempura PR?

Cheers! :-)

Hi @ptaoussanis,

Thanks for the reply. Lets see:

Could you please share some examples of resources and output, including resources with backtick escapes?

;; given somewhat contrived map argument {:arg "example" :arg2 "example 2"}
"Argument is %:arg%" ;=> "Argument is example"
"Argument `%:arg2% is %:arg%" ;=> "Argument %:arg2% is example"
"%:arg2% is %:arg% is %:arg2%" ;=> "example 2 is example is example 2"
[:b "Argument is `%:arg2% is %:arg%"] ;=> [:b "Argument is %:arg2% is " "example"]

What's the behaviour when a given keyword doesn't exist?

What the default resource compiler chooses. Named parameters are processed into vector arguments step-by-step, like so:

"%:arg-2% %:arg-1% %:arg-2%"
;=> {:resource "%1 %2 %1" :resource-keys [:arg-2 :arg-1]}

(mapv
 {:arg-11 "typo" :arg-2 "argument-2"} ; actual arguments
 [:arg-2 :arg-1]) ; resource keys
;=> ["argument-2" nil]

Here argument map becomes ["argument-2" nil], and default resource compiler decides the result (local testing shows the nil argument turned into empty string). A static check could automatically warn about mismatching arguments in translations on start-up and/or in continuous integration.

Just checking: has this been tested on both Clj and Cljs? (Regex behaviour sometimes varies, for example).

Yes. Some regex implementations had indeed different behaviour in clj/cljs, and current one seemed to work in both JVM and browser javascript environment.

You mention that this is "experimental" - in what way exactly? How ready do you feel the current approach would be for a potential Tempura PR?

Some points off the top of my mind:

  1. Performance is not exactly measured,
  2. Potential edge cases,
  3. Configurability (e.g. keyword syntax).

Integration into Tempura is not currently clear to me, as this approach uses the resource compiler API. I'm happy to work on a PR given some guidance, though. :)

Writing this answer also made me notice a bug in the handling of hiccup (or vector) resources in the custom resource compiler. Worked as a code review at the same time!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants