API beta test

marekd

@shahramt Do not init map again. Init is a procces, where all windy libraries are loaded and initialized. After the map is once set, you should work only with its API. Eg. clean all markers, create new markers, change location, zoom, change layers, ... You should handle this programmatically according to available methods mentioned here: https://api.windy.com/map-forecast/docs.
Reinit drops whole HTML and init all already inited modules again. It was a miracle it had worked till now. I had to do really ugly stuffs to make it work somehow in the current beta version.

Thiago Gabriel

@marekd Hi marekd. I face the same issue regarding the reinitialization of the map in my React web app. If i do not explicity reinit the map when I come back to the page that contains the windy div after navigating to another url, the map is not rendered again (I just get a gray screen). Am I missing something? Why the class that I use to define the windy map doesnt seem to target the windy map div after the first initialization of the API?

marekd

@thiago-gabriel I am sorry, but I am affraid I cannot help you. I think the problem could be the div is not visible. It is something our library does not count on. But I did not write anything in react for 4 years, so I do not know what exactly and how it works. I think the safe "solution" (workaround to be more precise) would be to have the map in an iframe and unmount the iframe on component unmount. Then load the iframe again on mount. I have not tried that, but I suppose it will work correctly and it will be safe even for next versions.
It's a little half-baked on our part we do not count on someone would like to hide the map for a while. The API library comes directly from our client codes and our website has map all the time. Sorry about that, but there are no plans to change that :-(

ShahramT

@marekd
Ok, but would you tell me how do I reach the map object and can redefine the center (and the content) by an example?
https://touchngo.se
I get the new position from the user but I do not know how to access the map-object later.
Many thanks in advance

marekd

@shahramt You should be able to store the map object into your custom variable which is accessible from the part of code you need. Or W.map.map (yes, 2 map) should work as well.

marekd

Beta has been released to production. Thank you all for your help.

CompassDSNM

@marekd

Hi @marekd, could you please tag us in future? You have taken down our application in production this morning. Issues been reported to support.

CompassDSNM

@mared Could someone please help us? This version has completely broken us.

CompassDSNM

@marekd We have made some progress with the issues using the following:

windyInit(options, windyAPI => {

                const { map, picker, utils, overlays, store, broadcast, particles } = windyAPI;

                let baseLayer = W.map.baseLayer;

                W.map = W.map.map;
                W.map.baseLayer = baseLayer;
}

The rest of our code uses W.map to address the map, so we have to assisn W.map.map to it. But this then lost w.Map.baseLayer, so we need to reassign it too.

This has brought our application back to life, but one need issue could you look at?

We create a form on the map to control turning on / off other layers. Since the new version of Windy we are now getting a "cursor: not allowed;" when hovering over the checkboxes shown in the screenshot.

The CSS is matching on input:read-only but our input checkboxes are not read only.... As you can see in the screenshot nothing is set to read only. But on hover of those inputs you get :

CompassDSNM

@marekd

I can override the CSS with

    #windy .form-group input:read-only {
        cursor: initial; /*This is like a weird bug where it was showing checkboxes as disabled even if the input was not read-only*/
    }

but seems like a bug at your side.

marekd

@compassdsnm Sorry for all problems. I am glad it works for you again. Just please be careful with using of W object. As it stands in the documentation https://api.windy.com/map-forecast/docs

Do not use features not listed here as we cannot guarantee that they will be available in other versions of Map Forecast API.

And accessing W object and its inner properties are definitely risky part. It can happen again. I would suggest you to use only windyAPI object returned after initialization.

CompassDSNM

@marekd We will need to discuss this internally. Initial feeling is that we would rather stay as close to a standard leaflet implementation as possible. Windy is a small part of our application.

@marekd can you reproduce the above CSS issue? I could create a simple page and set this up if you would like.

Euan

marekd

@compassdsnm CSS pseudo class :read-only is applied correctly, checkboxes and radio buttons are considered as readonly inputs in browsers by default. There is nothing wierd about that. If you need to change this behaviour, feel free to override styles like you did.

CompassDSNM

@marekd said in API beta test:

checkboxes and radio buttons are considered as readonly inputs in browsers by default.

@marekd I have never seen a checkbox or radio button having a default readonly value in all my life. Please can you share any documentation you have on this?

Mozilla's documentation says it is not default.
https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/readonly

Prior to your release on Monday morning, this was working as expected.

Thiago Gabriel

Hi again! I'm facing some issues with the WIND overlay in my ReactApp (not sure if the problem is related to React or not, though).

When the windyApi loads, the legend that shows the color scale is not generated. If I change the overlay manually, to any other overlay, the legend for that overlay is generated correctly. If then I change back to the WIND overlay, the legend is now generated.

I also noticed that I cannot change to the WIND overlay programatically. Using store.set("overlay","wind") yields to no results. Once again, this works if I use any other overlay as argument.

Here is a minimal reproduction of the issue: https://codesandbox.io/s/romantic-cloud-tio6qd?file=/src/App.jsx

Could you guys please take a look at this issues?
Thiago

marekd

@thiago-gabriel Thanks for the report! You are right, it looks like a bug. To hofix this issue, please use:

store.set('overlay', 'wind', { forceChange: true })

We try to fix it and release update today.

marekd

@thiago-gabriel It is fixed now, thanks again!

DaFish

@marekd Thanks for the new updates and sorry haven’t seen the thread. I recently noticed that a couple of features have changed during the update.
1 Now data of ICON (Eu and Global) is only displayed every 3 hours by default, even though the time step is shown every 1 hour. GFS defaults to data every 1 hour as before
2 The satellite data is no longer automatically included as before. If ‘satellite’ set as the default layer of the API, it is visible. If the default is something else and the satellite is only in the favorite layer, it will not be visible at all.
Or have I previously used the wrong name for the satellite data (‘satellite’) and the layer has only been shown because it was the only data I had in that API

DaFish

Sorry confusing, I have two account Saaneuvos and DaFish. Recently use the rare one

saaneuvos

@marekd Thanks for the new updates and sorry haven’t seen the thread. I recently noticed that a couple of features have changed during the update.
1 Now data of ICON (Eu and Global) is only displayed every 3 hours by default, even though the time step is shown every 1 hour. GFS defaults to data every 1 hour as before
2 The satellite data is no longer automatically included as before. If ‘satellite’ set as the default layer of the API, it is visible. If the default is something else and the satellite is only in the favorite layer, it will not be visible at all.
Or have I previously used the wrong name for the satellite data (‘satellite’) and the layer has only been shown because it was the only data I had in that API