I cannot think of a valid use case for isset anymore. It is superseded by with and the Support Forum has several threads from users who encounter problems because a code block is not escaped when using isset.
Latest example here
Obviously this will be a breaking change and it's up to the community to decide.
Thoughts?
Obviously this will be a breaking change and it's up to the community to decide.
It doesn't have to be breaking. It can be a warning for now. And then removed for good after something like 6 months?
I'm also curious to know of a use case whereisset has to be used because with cannot work. Once we know that, that needs to go to the documentation.
All my sites are isset -free.
__Minor correction__: I see that I am using isset are part of my internal figure shortcode mod. But that should be easy to replace.
Turns out isset would be needed in shortcodes to check if user passed a parameter.
What would be an elegant alternative for isset for such use cases?
As @onedrawingperday points out later, {{ with .Get "<param name>" }} would work.
Turns out isset would be needed in shortcodes to check if user passed a parameter.
I am using e.g. {{ with .Get "class" }} to check for parameters in shortcodes.
@onedrawingperday Thanks. Yes, that would work. I happened to test that same thing but stumbled across this in the process: https://github.com/gohugoio/hugo/issues/4965.
What about for data-driven sites? For example, I have a page with the following:
<h2 id="group-shows">Selected Group Shows</h2>
<dl class="hxList">
{{ range sort .Site.Data.group_shows "dateBegin" "desc" }}
<div>
<dt>{{ dateFormat "2006" .dateBegin }}</dt>
<dd>{{ .eventName }}, {{ .venue }}{{ if isset . "venueCity" }}, {{ .venueCity }}, {{ .venueState }}{{ end }}</dd>
</div>
{{ end }}
</dl>
For example, if the venue is online, there is no city or state, so the data for that entry would look like:
- eventName: OPA Online Showcase - Fall 2013
eventTitle: null
eventUrl: 'http://opaonlineshowcase.com/paintings/121/?s=all'
dateBegin: 2013-10-01
dateEnd: 2013-12-15
sponsor: Oil Painters of America
sponsorUrl: 'http://www.oilpaintersofamerica.com'
venue: OPA Online Showcase
venueAddress: null
venueCity: null
venueState: null
venueTZip: null
venueUrl: 'http://opaonlineshowcase.com'
Would {{ with .Get "dataKey" }} work for that instance, where I need the context to remain the same?
@StephenBrown2 In your example, replacing
{{ if isset . "venueCity" }}, {{ .venueCity }}, {{ .venueState }}{{ end }}
with:
{{ with .venueCity }}
, {{ . }}
{{ else }}
, {{ .venueState }}
{{ end }}
should work.
But I get that deprecating isset for good would break a lot of sites. And not everyone would have time to do the refactoring like above.
That said, it might be slightly useful if we state in the docs something along the lines that user should use with instead of isset.. If we agree, someone needs to come up with the right wording for that :)
@kaushalmodi I agree that a notice should go up in the Docs. Basically the problem is that isset does not escape code blocks if a variable is not set unlike with.
@kaushalmodi Except I want _both_ city and state if the city is found, and neither if it's not.
With your example, I would need to write:
{{ with .venueCity }}
, {{ . }}
{{ end }}
{{ with .venueState }}
, {{ . }}
{{ end }}
Or would a single with work?
{{ with .venueCity }}
, {{ . }}, {{ .venueState }}
{{ end }}
This hasn't worked for me in the past, as the "dot" scope is now just .venueCity.
EDIT: For completeness, I _could_ use the Scratch and go with this:
{{ $.Scratch.Set "loc" (trim (delimit (slice .venueCity .venueState) ", ") ", ") }}
<dd>{{ .eventName }}, {{ .venue }}{{ with ($.Scratch.Get "loc")}}{{ if ne . "" }}, {{ . }}{{ end }}{{ end }}</dd>
But I feel that's pretty ugly when a simple isset check would work.
Except I want both city and state if the city is found, and neither if it's not.
Sorry, that was obvious; I made a mistake in interpreting that example.
This hasn't worked for me in the past, as the "dot" scope is now just .venueCity.
That's the whole beauty and purpose of with. I agree that the code is slightly less verbose when using isset here, but you don't necessarily need to use scratch.
This would match your original example that used just one isset:
{{ $venue := . }}
{{ with .venueCity }}
, {{ . }}
, {{ $venue.venueState }}
{{ end }}
But I wouldn't do it like that because that assumes that .venueState would be present if user had set .venueCity. I'd do it this way:
{{ $venue := . }}
{{ with .venueCity }}
, {{ . }}
{{ with $venue.venueState }}
, {{ . }}
{{ end }}
{{ end }}
Good point with setting the current context to a variable, though that's still a bit too verbose for me (but might work for another issue I have in that same template).
I ended up going with extending the trim delimit slice method I had stumbled upon for each of the variables in the line, i.e.:
{{ trim (delimit (slice .aventName .venue .venueCity .venueState) ", ") ", " }}
And for the other issue (an optional website link for some text), I defined a inner template:
{{ define "optlink" }}{{ with .href }}<a href="{{ . }}">{{ end }}{{ .text }}{{ with .href }}</a>{{ end }}{{ end }}
becomes:
<dd>{{ .award }}, {{ template "optlink" (dict "href" .website "text" (.event | markdownify)) }}{{ with .sponsor }}, {{ . | markdownify }}{{ end }}</dd>
isset and with are not redundant, and I think we should keep things as-is.
Most of the past confusion with isset revolved around people passing unsupported data types that we silently ignored. We now warn the user about invalid usages of isset.
@StephenBrown2 gave an use case that's valid. There's no reason to force the user to overload their current context just to see if a key/index exists.
Also, the forum post linked to in the OP doesn't demonstrate the confusion claimed on this issue. The error seen by the user appears unrelated to their use of isset.
Ok @moorereason you know best.
I am closing this issue since the Hugo issue tracker is pretty full as is and there is no need for this to remain open.
Most helpful comment
Ok @moorereason you know best.
I am closing this issue since the Hugo issue tracker is pretty full as is and there is no need for this to remain open.