[CLOSED] v34.0.0
-
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. -
@vicb I'm not sure why it's behaving differently now, but there have been a lot of changes around users and favorites. In our codes we rely on
favsChanged
event. I would recommend you to rerender your view on everyfavsChanged
event.const favs = W.require('favs'); const render = () => { // whatever it should do } favs.on('favsChanged', render); render(); // on plugin close you should call favs.off('favsChanged', render);
Hope this helps.
-
@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 !
-
The compiler at https://github.com/windycom/windy-plugins, does not understand named exports,
import * as http from '@windy/http'
does not work.Fortunately
import http from '@windy/http'
still works.The only exception that I could find was:
W.map
. The leaflet map is atW.map.map
, while some custom Windy properties and methods, that were previously added to the leaflet map, are now inW.map
, such asbaseLayer
. (Please correct me if I'm wrong @marekd ). -
@rittels It should be
import { map } from '@windy/map'
. In a case you access the map viaW
object, you really need to useW.map.map
because of named exports. Thanks for pointing it out. I will check the plugin compiler, it should support named exports. -
@marekd
ICON-D2 is a very useful addition and new features probably are appreciated by many users too.
I found some small glitches.- ON A FAVORITE LOCATION, near but out of the ICON-D2 domain, the point forecast still shows ICON-D2 model. But forecast is apparently that of ICON-EU as displayed in grey label here:
Same with all types of meteograms.
-
An other small glitch. I chose just for this test the Radar page as starting layer.
"Click to change units" is confusing as there is only dBZ unit available with the Radar layer.
Then the pulsing blue dot shows a wrong location (50km away) but it is already known. (Why this blue dot is automatically shown with Radar? Couldn't it be possible only when "Find my location" is enabled?)
-
And a minor issue. Some models names in Wind meteogram are cut, specially that of ICON-D2. See first screenshot above
- ON A FAVORITE LOCATION, near but out of the ICON-D2 domain, the point forecast still shows ICON-D2 model. But forecast is apparently that of ICON-EU as displayed in grey label here:
-
@idefix37 Thanks for great report and help!
- ICON-D2 borders are fixed now
- Labels wrapping is fixed now
- "Click to change units" has been reported into our bug tracker with lower priority, it is not a release-breaker
- Getting your location on desktop is by IP address (or browser info if available), so a minor deviation is fine.
Blue dot is shown because we think it is important for radar layer. Typical use case: Will the storm hit me? So you want to know where you are. Of course, it works a little more reliably on devices with GPS.
-
@marekd
This is perfect.
Just a small detail in the Wind table:
-
@idefix37 Thanks! We're about to go through the whole app and find all overflowing texts. I am pretty sure there will be a similar problem in more places.
-
-
Beta test is closed, v34.0.0 has been released. Thank you all for your help!