Should useMeta follow the Stimulus member variable naming convention?

[leastbad]

I'm genuinely excited to put useMeta to work. I use meta tags to do everything from JWT tokens to tenant keys.

I do wonder if "we" should change the member variables useMeta creates to follow the convention established by targets and values. That is, if we define:

static meta = ["token"]
// ....
// we should access:
this.tokenMeta

Not only is this a reasonable expectation based on this.tokenTarget and this.tokenValue, but there's a very real chance that existing controllers might have a token member variable in play, or that someone working with a token might want to create one.

Since the feature is out only a few hours, perhaps there's a "5 second rule" cool off possible.

[adrienpoly]

Thanks for this excellent and valid suggestion

I don't think anyone put it in production so having a breaking change is largely acceptable for me at this point. I was thinking about putting a process where new mixin would be released in some beta version first with potential breaking changes without having to bump the full library to a major version. (other topic any way)

Back to the subject, one solution I can think of would be to pass an option

useMeta(this) // this.token
useMeta(this, { suffix: true }) // this.tokenMeta
useMeta(this, { suffix: "value" }) // this.tokenValue

Does it default to false ? My experience was to use it for some pretty obvious things such as userId, environment, feature flags etc with rather low risk of collusion

Also I had another very interesting feedback from someone doing similar things but with data attributes on the body tag. There is a major difference when using Turbolinks. Head with Turbo won't change on page visits therefore this Meta trick is valid only for values that are constant during the session (userId, env etc).
Params on the body are updated on page visits so.

I bring this up because I will probably add this support for params in the body tag and introduce some kind of opt-in option for that. So this is another reason to add some option.

[leastbad]

Admittedly, I don't have a lot of first-hand experience with TL behaviour when it comes to content in HEAD. The very first paragraph of the TL README suggests that upon navigation it "merges" the HEAD, which I've always assumed meant that if a new meta tag was served, it would be added to the current live HEAD. Am I close in my understanding?

My honest feedback to the compromise you offered is "no thanks". I'd rather keep the 1:1 naming you've established than complicate this library with a feature that potentially makes the problem worse (eg. someone could specify suffix: "property" and not even realize that they are a horrible moron person 😀 ).

I hope you interpret this for what it is: potentially right, potentially wrong, but valuable for being opinionated and not wishy-washy. I think you should change it, but I'll sleep fine if you don't, too. ❤️

[leastbad]

Also: I love the idea of expanding this concept to the BODY tag.

Even though the code would be very similar, I'd keep them as separate mixins eg. useBody or even useBodyTag or even still: useBodyMeta.

And yes, principle of least surprise would expect this.fooBody or this.fooBodyTag or this.fooBodyMeta.

[adrienpoly]

My bad The head is merged and therefore meta are updated. Which is a good news. I don't know why I have this idea in mind!!!!
RTFM!!!!

I will follow your suggestion. makes a lot of sens to follow more closely the Stimulus conventions.

[leastbad]

You're awesome, Adrien. I'm so glad you're in this crazy soup with us.