weather: add possibility to override njk's and css

[khassel]

This is an approach for #2909

It adds 2 values to the config:

		themeDir: "./",
		themeCustomScripts: []

themeDir must be specified relative to the weather dir.

Example config:

		{
			module: "weather",
			position: "top_center",
			config: {
				weatherProvider: "openmeteo",
				type: "current",
				lat: 40.776676,
				lon: -73.971321,
				themeDir: "../../../modules/MyWeatherTemplate/",
				themeCustomScripts: [ "skycons.js", "weathertheme.js" ],
			}
		},

The themeDir must contain the 4 files

• current.njk
• forecast.njk
• hourly.njk
• weather.css

You can add more files (if needed) and add them to the themeCustomScripts so they are loaded as script.

There are 2 methods inserted which are called if defined:

• initWeatherTheme: For doing special things when starting the module
• updateWeatherTheme: For doing special things before updating the dom

I see this as a simple approach for overriding the default njk templates and css. I did already convert my MMM-WeatherBridge into a template.

[sdetweil]

Weather doesn’t use njk in next release

[khassel]

I used last develop as base, there are still njk's.

[sdetweil]

Weird. I thought he removed them, we had that conversation..

[khassel]

weather was moved from browser-only to using server-side but the "gui" was not touched

[KristjanESPERANTO]

Nice! I think it would be great to have this possibility 🙌

One question without digging into the changes: in the linked issue #2909, @sdetweil suggested a simpler approach – just adding config variables for the template file names and css, defaulting to the current values, something like:

currentNjk: "defaultmodules/weather/current.njk",
hourlyNjk: "defaultmodules/weather/hourly.njk",
forecastNjk: "defaultmodules/weather/forecast.njk",
weatherCss: "defaultmodules/weather/weather.css",

Users could then override only what they need with a path relative to the MM root, e.g.:

currentNjk: "config/mycurrent.njk",

That would already allow users to point to custom files without touching the module code.

Would that cover the main use case, or do you think the themeDir + themeCustomScripts + window.* hooks are genuinely needed for what you have in mind? Just want to understand your approach 🙂

[KristjanESPERANTO]

You can add more files (if needed) and add them to the themeCustomScripts so they are loaded as script.

Ah, that wouldn't be possible with the simpler approach... Right?

[khassel]

I think to define another dir is a simpler approach instead of 4 variables.

You find my (testing) example here, I need 2 additional scripts skycons.js and weathertheme.js from that repo.

Can explain more tomorrow if needed (now too late) ...

[KristjanESPERANTO]

I think I'm starting to understand where you are going with this – looking at MMM-WeatherBridge it makes more sense and gives impressive flexibility 👍

One concern though: wouldn't window.initWeatherTheme and window.updateWeatherTheme cause problems when having multiple weather instances with different themes? The second instance would overwrite the globals defined by the first, wouldn't it?

[khassel]

think so, had no better idea as window ...

[KristjanESPERANTO]

think so, had no better idea as window ...

Me neither, but maybe that's (multiple weather instances with different themes) an edge case that we don't need to support and should just accept as a known limitation.

[khassel]

edge case that we don't need to support and should just accept as a known limitation.

yes, and the user can implement the multiple instances stuff inside the 2 procedures if needed.

[KristjanESPERANTO]

Looks good to me! 🙂

One thought: now that the infrastructure is in place, would it make sense to already ship some themes in core (e.g. under modules/default/weather/themes/)? The MMM-WeatherBridge layout would be a great candidate and would give users something to work with right away.

On the other hand, bundled themes also mean ongoing maintenance responsibility for us. Maybe better to merge this as-is and see if the community picks it up first?

[khassel]

Maybe better to merge this as-is and see if the community picks it up first?

I think so. I didn't want to burden this repository with my weather setup as well.

The idea is to add a detailed example to the documentation after the merge.

[KristjanESPERANTO]

Nice! I'll definitely play around with it, as it has the potential to make many third-party weather modules unnecessary.