I'm completely new to helm/k8s. Following question might not be best way to do things or it might not make a lot of sense, but I don't know best(or any other) practices yet, and this is my best attempt to solve something much more complex, while not understanding it properly. Thanks(I beg) for patience with me.
In values.yaml say I have something like this:
whatever1: true
whatever2: true
myConfigs:
variantA:
test: tooSteep
variantB:
test: learningCurve
in reality it's a lot bigger, of course. Then I have some template, which I need to generate in 2 (or more) variants and I cannot use whole different configs for it, which would overwrite data in values.yaml(it's complicated). Previous solution by college who understands this more than me involves some heavy copy-pasting. What I'd like to see instead is to have one abstract template, say:
whatever1: true
whatever2: true
test: {{ .Values.myConfigs.$what.test}}
which I'd include/tpl somehow within child templates, and say how it should behave conditionally, say:
{{- $what := "variantA" -}}
{{ tpl (.Files.Get "stubs/abstract.template") . }}
The syntax is obviously wrong, and it does not work. I know this is wrong, I cannot find any way which would enable this. I don't know the correct way how to write that. What I need to do is somehow express, which part of .Values should be used in specific part of template. IIUC if I have all data in 1 file I cannot, just use tpl function, load template and pass it context of specific variant, as won't have access to whatever then. So I need to pass the broader context and somehow pass some selector.
I understand, that correct way is probably restructuring files so that I can actually work effectively with context, but that would require me to actually understand which part of configuration will have to go together every time, and I'm far from ready for this refactoring.
Not sure what is the correct way, but what could be actually used to solve described problem: do the decision when calling template, and alter the passed context to contain all required information. In my case it wasn't possible just to select specific subtree in actual context, so what I was missing was function dict, which creates a new dictionary, which then can be passed as context.
Related
Usually I use paginate when I want the user to view a list (or a narrowed down list based on filters). Simple example below:
Thing::query()
->orderByDesc('created_at')
->paginate(40);
If I wanted the user to view a short list, like get the five newest models, I would create a separate api with a query like below:
Thing::query()
->orderByDesc('created_at')
->take(5)
->get();
I want to combine the two eloquent queries in such a way that it gets the paginated list by default, but will take 5 if the query param 'take=5' is present. I can do this the following way:
Thing::query()
->orderByDesc('created_at')
->when(
$request->query('take'),
fn ($query, $count) => $query->take((int)$count)->get(),
fn ($query) => $query->paginate(50)
);
The above works but has been described by a colleague as a little confusing, since the 3rd argument to when() is if the first argument is false (documentation) but that isn't immediately apparent when viewing the code. The "confusing" part might be subjective here but I would like to make sure my code is quickly understood by other devs as best as possible.
Does anyone know of a simpler/clearer or just another way to achieve this? In an ideal world the take()->get() would only exist in the when() method and paginate() would exist outside of it, but be overridden by the when() condition if true.
Note: I anticipate some people might say that they should remain as separate api's, however in my opinion the extra logic here is so simple that the gain in reduced code outweighs the gain in "do one thing well".
I noticed that hyperHTML preserves references I make to elements:
let div = document.createElement("div");
div.textContent = "Before Update";
hyperHTML.bind(document.body)`static1 - ${div} - static2`;
div.textContent = "After Update";
Above will produce a page that says:
static1 - After Update - static2
It is my understanding that hyperHTML ultimately clones an HTML <tempate> element to render the final output. However, don't you typical lose references when cloning an HTML template (like the variable "div" in the example above)?
Therefore, on the initial render, does hyperHTML somehow replace cloned elements with their originals after cloning the HTML template?
Here's how I think it works:
Create an HTML Template of the original template literal while
replacing all interpolations with comments.
Clone the html template with comments left in.
Make elements or document fragments out of each interpolation originally recieved
Replace each comment in the clone with its processed interpolation.
Is this correct?
I am not sure what is the question here, but there is a documentation page, and various examples too to understand how to use hyperHTML, which is not exactly in the way you are using it.
In fact, there's no need to have any reference there because hyperHTML is declarative, so you'd rather write:
function update(text) {
var render = hyperHTML.bind(document.body);
render`static1 - <div>${text}</div> - static2`;
}
and call update("any text") any time you need.
Here's how I think it works ... Is this correct?
No, it's not. hyperHTML doesn't clone anything the way you described, it associates once per unique template tag a sanitized version to the output and finds out all interpolated holes in it.
The part of the library that does this is called domtagger, and the mapping per template literal is based on the standard fact that these are unique per scope:
const templates = [];
function addTemplate(template, value) {
templates.push(template);
return template.join(value);
}
function asTemplate(value) {
return addTemplate`number ${value}!`;
}
asTemplate(1);
asTemplate(2);
asTemplate(Math.random());
templates[0] === templates[1]; // true
templates[1] === templates[2]; // true
// it is always the same template object!
After that, any other element using once that very same tag template will have a clone of that fragment with a map to find holes once and some complex logic to avoid replacing anything that's already known, being that text, attributes, events, or any other kind of node.
hyperHTML never removes comments, it uses these as pin and then uses domdiff to eventually update nodes related to these pins whenever there's a need to update anything.
Domdiff is a vDOM-less implementation of the petit-dom algorithm, which in turns is based on E.W Myers' "An O(ND) Difference Algorithm and Its Variations" paper.
Whenever you have DOM nodes in the holes, hyperHTML understand that and fill these holes with those nodes. If you pass repeatedly the same node, hyperHTML won't do anything 'cause it's full of algorithm and smart decisions, all described in the documentation, to obtain best performance out of its abstraction.
All these things, and much more, normalized for any browser out there, makes hyperHTML weight roughly 7K once minified and gzipped, bit it also offers:
Custom Elements like hooks through onconnected/disconnected listeners
lightweight components through hyperHTML.Component
SVG manipulation as content or via wire
easy Custom Elements definition through HyperHTMLElement class
As summary, if you need these simplifications and you don't want to reinvent the wheel, I suggest you give it a better try.
If you instead are just trying to understand how it works, there's no need to assume anything because the project is fully open source.
So far, all I've read from your questions here and there, is that you just believe to understand how it works so I hope in this reply I've put together all the missing pieces you need to fully understand it.
Do you want to write your own lit/hyperHTML library? Go ahead, feel free to use the domtagger or the domdiff library too, few others are already doing the same.
I'm doing some competitions on a website called topcoder.com where the objective is to solve algorithmic problems. I'm using Eclipse for this purpose, and I code in Java, it would be help me to have some predefined templates or macros that I can use for common coding tasks. For example I would like to write methods to be able to find the max value in and int[] array, or the longest sequence in an int[] array, and so on (there should be quite many of these). Note I can't write these methods as libraries because as part of the competition I need to submit everything in one file.
Therefore ideally, I would like to have some shortcut available to generate code both as a method and as a calling statement at once. Any ideas if this is possible?
Sure you can - I think that's a nifty way to auto-insert boilerplate or helper code. To the point of commenters, you probably want to group the code as a helper class, but the general idea sounds good to me:
You can see it listed in your available templates:
Then as you code your solution, you can Control+Space, type the first few characters of the name you gave your template, and you can preview it:
And then you can insert it. Be sure if you use a class structure to position it as an inner class:
Lastly - if you want to have a template inserts a call to method from a template, I think you would just use two templates. One like shown above (to print the helper code) and another that might look like this, which calls a util method and drops the cursor after it (or between the parentheses if you'd like, etc):
MyUtils.myUtilMethod1();${cursor}
Is there any way to have a user defined parameter in a file and then have the dist.ini set the value for the parameter. For example, a file might contain {{$THE_ANSWER}} and the dist.ini file would provide a value like THE_ANSWER = 42? I'm pretty new to using dist::zilla to work with perl distributions, and I'm having problems understanding how it treats files as templates. There seem to be only a couple of hard-codeed parameters, varying by plugin, that can be used for any file. One such parameter is the {{$NEXT}} variable made available by [NextRelease] in the Changes file.
I read through the tutorials and searched the modules on CPAN and can't figure out if this is even possible. It is not an acceptable work-around to use the [GenerateFile] plugin to put the whole file in the dist.ini file. Besides a lack of flexibility and just plain ugliness, it doesn't seem possible to add lines with leading white-space that way.
What I would do is use a stash or plugin to store the variables. Stashes are like plugins, but they don't do anything but store data, and they can be put into your global configuration as well as your dist.ini.
[%Vars]
favorite_pie = pumpkin
Then you can get at them like this:
$zilla->stash_named('%Vars')->favorite_pie
This assumes that you've made Dist::Zilla::Stash::Vars and given it a favorite_pie attribute.
You could make a totally generic stash, though, which accepts anything as a key. For that, I'd look at the source of Dist::Zilla::Plugin::Prereqs, which allows arbitrary configuration options and shoves them into a hash attribute in its BUILDSARGS method.
You could make that Dist::Zilla::Stash::Generic, and then register it as many times as you want for different reasons:
[%Generic / Pies]
favorite = pumpkin
hated = rhubarb
firstever = quince
[%Generic / Passwords]
pause = PeasAreDelicious
google = secret
reddit = SecretPeasAreDelicious
...then, as needed, say in templates...
{{ $zilla->stash_named('Passwords')->get_var('pause' }}
If I was making a lot of files that used this sort of generic thing, I'd pass their Text::Template instance a closure called get_password like this:
get_password => sub { $zilla->stash_named('Passwords')->get_var($_[0]) }
Then your template could include:
Login with: {{ get_password("pause") }}
This answer obviously leaves some source digging for you, but I think it should point at all the pieces I'd use to do what you want.
I've done some searching on this, but I cannot find info. I'm building an application inside sinatra, and using the coffeescript templating engine. By default the compiled code is wrapped as such:
(function() {
// code
}).call(this);
I'd like to remove that using the --bare flag, so different files can access classes and so forth that I'm defining. I realize that having it more contained helps against variable conflicts and so forth, but I'm working on two main pieces here. One is the business logic, and arrangement of data in class structures. The other is the view functionality using raphaeljs. I would prefer to keep these two pieces in separate files. Since the two files wrapped as such cannot access the data, it obviously won't work. However, if you can think of a better solution than using the --bare option, I'm all ears.
Bare compilation is simply a bad practice. Each file should export to the global scope only the public objects that matter to the rest of your app.
# foo.coffee
class Foo
constructor: (#abc) ->
privateVar = 123
window.Foo = Foo # export
Foo is now globally available. Now if that pattern isn't practical, maybe you should rethink your structure a bit. If you have to export too may things, you nest and namespace things better, so that more data can be exposed through fewer global variables.
I support Alex's answer, but if you absolutely must do this, I believe my answer to the same question for Rails 3.1 is applicable here as well: Put the line
Tilt::CoffeeScriptTemplate.default_bare = true
somewhere in your application.