this pr changes main.js viewEvents() ( which builds the event list ) so that:
when today's date is in that range, the list will use "today" as the start, and still use the specified end. ( previously it used "start" )
when today isnt in that range ( archive pp pages ), it uses the specified start, and still use the specified end. ( same as old behavior )
when there isn't a start and end range, like for the /calendar view, it uses today as start, and today + a constant as the end. ( same as old behavior )
code changes:
moved start date calculations to a function getInitialView(), and put the results in a "view" object to simplify the code some.
switched to dayjs:
daysAfter() isnt needed, now just: .add();
timezoneOffset isnt needed, now just: .utc()
new Date() is dayjs()
when "today" is in the start/end range, getInitialView() uses "today" as the start; all other decisions are the same.
switched from using'something' in options to options.something: the logic is the same for our use cases, and it reads better the more modern way.
removed the var isExpanded, instead the view object has property show_details (which is whatgetEventHTML needs. )
getEventsHTML() only works if called with id or start/end date; so i added an explicit error to make that failure more obvious. ( doesn't affect any current pages b/c they all do the right thing. )
pp pages specify event list options using a start and end date, for example: https://github.com/shift-org/shift-docs/blob/2c826225f8ed506b3a3128b6bc42922bef259b07/site/content/pedalpalooza-calendar.md?plain=1#L9
this pr changes main.js
viewEvents()
( which builds the event list ) so that:code changes:
'something' in options
tooptions.something
: the logic is the same for our use cases, and it reads better the more modern way.isExpanded
, instead theview
object has propertyshow_details
(which is whatgetEventHTML
needs. )