-
Notifications
You must be signed in to change notification settings - Fork 731
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
Allow to inject custom parameters to the Stencil context via command line #253
Comments
|
@krzysztofzablocki Does Sourcery also named its CLI flag If so, why not use |
Also, do you do KeyPath parsing? Like if the user invokes Sourcery with (I don't think that last solution is worth implementing, but just asking in case you do that, for consistency's sake too) |
Right now our version is very simple, we'll need to figure out a way for parsing those extra args properly with commander, related discussion krzysztofzablocki/Sourcery#80 Whatever we do here best we do it in both tools ;) I prefer your syntax for passing in the extra arguments to CLI but I also think we should scope them under a single context item in Stencil |
Yeah I totally agree with your suggestion in scoping them in a single item in the context, hence my question about the name of such key ( |
Why scope them though? It just ends up in more verbose templates. Could be useful if a user wants to override variables provided by the parser? |
well, that is exactly why I want to scope it to avoid potentially overriding one of the things we will add via parser, what use case can you see there? |
It would be handy if we want to provide defaults but that the user wants to override. For example |
Ok that makes sense, if we do that then lets log info that a param is an override of provided data |
Hmm, interesting suggestion. How would you achieve that? Variables should remain just that for a template. We could do some additional type-checking if you're worried about that, so that arrays stay arrays, etc... |
well we control how context is defined before feeding templates, so we can just check before assigning incoming value whether it was already there and then log that info. |
I'm not sure the parser should inject default values anymore. Stencil provides a This way, the default value isn't hard-coded in the source code (nor of |
👍 especially with set node you could easily express all arguments on top of your templates along their defaults |
Besides, by scoping the parameters provided by the command line inside a And this would even make it possible to write Unit Tests for the documentation, like grep-ing |
@AliSoftware in case of SwiftGen I'll raise you even better, you could just scan the given template for the param name and fail build if someone passes in unused argument, thus preventing human mistakes / typos |
That could be a nice idea, but might be dangerous and prone to false positives. Like imagine this hypothetical example:
And calling SwiftGen with:
It would be hard to see that we access the |
We can now call This could be nice to integrate that in the upcoming SwiftGen 4.2 — and make use of it in the storyboards templates to get rid of the import warning mentioned in #264 as I think that's the thing that annoys the most people in the current 4.1 version (me included) 😉 |
Implemented in #265 |
One thing that would add a lot of flexibility in SwiftGen is to be able to inject any custom parameters to the template from the command line:
This would allow us to generalise the special case of
--enumName X
: the--enumName
parameter would disappear in profit of the new--param enumName X
way of injecting it.For example one could imagine using
--param AppModule MyAwesomeApp
to inject a custom value for theAppModule
variable in the Stencil context. Then in the storyboard templates, we'd be able to use{% if AppModule %}{{AppModule}}.{% endif %}
to prefix all class names with the app's module name (to allow disambiguation) if its value has been provided via the command line.The text was updated successfully, but these errors were encountered: