Posts made by vicb

It seems like the windy sounding plugin has that hardcoded:

u = ["ecmwf", "gfs", "icon", "iconD2", "iconEu", "bomAccess", "namConus", "namHawaii", "namAlaska", "hrrrAlaska", "hrrrConus", "ukv"]

Follow up question for @marekd

Is there an easy way to know if the model has sounding data? (i.e. mbue doesn't)

Thanks

Seems like the correct way is:

W.require('models').getAllPointProducts({lat: 37, lon: -121});

I use the following code in my plugin:

const windyStore = W.require("store");

      const models = windyStore
        .get("visibleProducts")
        .filter((p) =>
          SUPPORTED_MODEL_PREFIXES.some(
            (prefix) => p.startsWith(prefix) && !p.endsWith("Waves") && !p.endsWith("Analysis")
          )
        );

I have to do some filtering (aka black magic) to remove unwanted values.

There should be a proper way.

I see that the built-in plugin also displays a list of available model.
But it is buggy: the list is only updated when the plugin is opened. So when you open the plugin over the USA and navigate to i.e. Europe, the list is wrong.

/cc @marekd

It would be nice if Windy gives more a little more consideration to plugin developers.

During the migration to TS we had to ask for a way to be able to test the plugins.

I have reported this query issue last September it nothing has been done since then - I think it would be an easy fix to make this.query available as it was before.

Having a dev version (windy.com/dev) that is not in sync with windy.com does not help.

It seems like some other changes are on the way. I hope windy can provide a way to test the updates before they are released.

@rittels

I was checking on windy.com/dev and it is not populated there - could this version be lagging behind?

I see it being populated on windy.com

@rittels W.plugins.plugins.pluginInfo is undefined

So digging into the code I found:

W.define("Plugin", ["rootScope", "utils", "trans"], (function(e, t, n, i) {
    var r = i.loadLangFile
      , o = function(e) {
        var t, n, i, r;
        this.initProperties(),
        this.dependencies = null !== (t = e.dependencies) && void 0 !== t ? t : this.dependencies,
        this.exclusive = e.exclusive,
        this.ident = e.ident,
        this.langFiles = e.langFiles,
        this.location = e.location,
        this.close = null !== (n = e.close) && void 0 !== n ? n : this.close,
        this.paramsChanged = null !== (i = e.paramsChanged) && void 0 !== i ? i : this.paramsChanged,
        this.redraw = null !== (r = e.redraw) && void 0 !== r ? r : this.redraw
    };

If you add a this.query = e.query in this code then the former behavior is restored and you can access this.query in i.e. your plugin onopen.

@marekd Is that something that can be fixed in windy so that we restore the former behavior or is it intended and we need to retrieve the query from somewhere else?

So it is indeed something that break in windy at some point.

We use to be able to use this.query in the plugin to access the parsed query string. It is not defined any more.

I've asked @rittels if he knows where this has moved and I will also try to dig a but in windy sources to figure out.

@Korina when you use the URL I give in the first post, the plugin is supposed to open at the location passed in the parameters wherever you physically are located.
It does not work anymore and the plugin opens at your current location.
I'm talking about the initial location, not subsequent plugin openings.
It is probably due to a running change in windy. I might be able to workaround that.

@Korina The passed location is ignored and it opens at my current location

For example
https://www.windy.com/plugins/windy-plugin-sounding?lat=38.594480333494715&lon=-112.12185243531977

open the plugin at my current location instead of the passed location

@rittels I'm using windyPicker.on("pickerMoved", ({ lat, lon }) => {...}) and it still seems to work, do you confirm ?

@marekd said in v35.0.0:

https://www.windy.com/beta-test

Thanks for the heads up - it is super convenient to test plugins (and I am happy to have nothing to do this time)

@marekd Thanks, it solved my issue.

It was not too hard (a couple hours) to make my plugin work with both the beta and the stable version.

Thanks for continuously improving windy !

My plugin calls W.require("favs").getArray() to retrieve the favorites.

With the beta version W.require("favs").getArray() returns an empty array. However the same code executed from the JS console returns the list of favorites as expected.

My guess is that the favorites are not initialized at the time of the call by my plugin. What would be the best way to solve this ?

Edit: I wrapped the call inside a setTimeout(,1000); and it works again with the the beta. This seems to confirm something is not initialized yet.

@marekd said in Plugin developers, stay alert. We are refactoring Windy.com client codes to typescript!:

windyVersion

Looks great.
Thanks and good luck with the refactoring.

@rittels

I was actually thinking the other way around:

main would be the default (i.e. dist/plugin.js)

and main_updates would be your old_windy_version but if the version is >= 33.0.0 then the other js would be loaded instead.

Algo would be: use the highest version from main_updates that is less or equal to current windy API version and use main if none found.

But I guess both would work

I have updated my plugin to use:

const $ = W.require("utils").$ || W.require("$");

Note that the order is important here as W.require("$") would crash the next version if first in the expression (as the module is going away).

That should be the only required change for my plugin.

@tdevito There is indeed a link to the "home site" on webcam pages - I am not sure if that's what you are looking for: