What would you do differently and why?

Howdy all…

I’ve carved up a completely useless pair of partial templates to show a general pattern for partials…

caveat emptor, I’ve not actually tested them…
( so its possible they don’t even work as is…)

my point was to create a minimal skeleton of two partials interacting in some fashion with all the boilerplate so people could point and laugh offer advise on better ways of …

I’m sure it’s terrible for lots of reasons…

or…

I’m sure that people with lots of opinion and experience will find ample opportunity to advise improvements / be able to explain to me why my logic is flawed in the benefits of … (whatever )

I’d love to hear y’alls (constructive) thoughts on the design pattern and why/how/where I’m doin it wrong :wink:

I know some of my choices are contentious… and for the most part I’m okay with it… but I also like hearing others’ insights into doing things in better ways.

TIA… hope y’all are having a great day.

w

Without reading deeper into the partials (I somehow expected ten lines, not something this “voluptuous”):

one thing you can outright drop is the whole {{- define "partials/util/bareSVG.html" -}} if the file itself is in partials/util/bareSVG.html. it’s either or. Either a partial in a file under partials, resulting in its name being pathname under the partials directory, or a define partialname anywhere, but available to the calling layout file.

Basically, if you have one layout with a table and checkboxes that you implement via svg, then add two “inline partials” with partial partialname for checked checkbox and unchecked checkbox at the end of your layout file and in the table just use the call to the partial.

I personally prefer to put my configuration into the configuration. You define some settings at the beginning of the file. You can get rid of confusion by having the following somewhere in your config:

[param.dnb.myplugin]
parameter1 = true
parameter2 = false

the dnb is akin to a namespace (no accidental overriding for other peoples plugins) and the myplugin is a slug for your plugin/module/partial (no accidental overriding of your own plugins).

The do something like the following:

{{ $config := dict }}
{{ with site.Params.dnb.myplugin }}
{{ $config = . }}
{{ end }}

After that $config.parameter1 is true. You can use the default function to add common defaults to your layout and keep the config small and clean.

(note: code samples are typed, not tested)

heh. nice description :wink:

yeah. I wanted to hear opinions like this.

thank you!

I’m doing a lot of this already… I intentionally put a few things that I consider antipatterns in to see what people would say

I do add a lot of global scope params, and I was trying to be as explicit as possible so as to not be confusing.

regardless, I appreciate your advise.

Thanks!

[= No electrons were hurt or unwillingly coerced in the creation of this message =]