Windy Community

    • Register
    • Login
    • Search
    • Unread
    • Categories
    • Groups
    • Go to windy.com

    Plugin developers, stay alert. We are refactoring Windy.com client codes to typescript!

    Windy Plugins
    5
    17
    1794
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • vicb
      vicb Paraglider @marekd | Premium last edited by

      @marekd Hey what is no clear to me is how the changes will be deployed.

      i.e.

      • Will W.$ start to break when the new version is released ?
      • Can we update to use W.utils.$ now ? If not will W.$ be an alias in the next few version so that the plugins do not break on the release day ?
      • Would there be a way for windy to offer a staging of the new version before the release so that we can test/update the plugins before ?

      Thanks.

      1 Reply Last reply Reply Quote 1
      • marekd
        marekd Administrator last edited by

        Hey @vicb. Yes, it will break plugins at the moment of release. I would recommend to use e.g:

        const $ = W.$ || W.utils.$;
        

        This should work on current and also future version of the client.

        Public test version for plugin developers is a great idea! We will figure it out somehow for the next iteration :-) Send me a PM if you need it now, for the current release.

        vicb 2 Replies Last reply Reply Quote 1
        • vicb
          vicb Paraglider @marekd | Premium last edited by

          @marekd One thing that could be great too is to be able to load different js files according to windy version. That should be easy to implement by adding an extra field to the package.json of the plugin.

          With that plus a public test version you can prevent plugins from breaking when the API has a BC break.

          rittels 1 Reply Last reply Reply Quote 1
          • vicb
            vicb Paraglider @marekd | Premium last edited by

            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.

            1 Reply Last reply Reply Quote 1
            • rittels
              rittels Code contributor @vicb | Premium last edited by

              Hi @vicb

              How would write the package.json? how about:

              "old_windy_version":{"33.0.0": "path_to_other.js"},
              "main": "dist/plugin.js"
              

              So if the version < 33.0.0, use path_to_other.js, else use main.

              vicb 1 Reply Last reply Reply Quote 1
              • vicb
                vicb Paraglider @rittels | Premium last edited by vicb

                @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

                marekd 1 Reply Last reply Reply Quote 0
                • marekd
                  marekd Administrator @vicb last edited by marekd

                  @vicb Thanks to @rittels there will be support in a next windy version for specific loading as you discribed in your last post. Just for to be sure I copy-paste the logic of finding the version:

                  let path = '';
                  if (json && json.main_updates) {
                      const mainUpdates = json.main_updates;
                      const windyVersion = ver2num(rs.version);
                      let min = Infinity;
                      for (const version in mainUpdates) {
                          const diff = windyVersion - ver2num(version);
                          if (diff >= 0 && diff < min) {
                              min = diff;
                              path = '/' + mainUpdates[version];
                          }
                      }
                  }
                  // ...
                  // load `${pluginRootUrl}${path}`
                  

                  Feel free to suggest anything you need for surviving this crazy period of windy refactoring :-) It is easy to change the logic while it is in a dev branch.

                  vicb 1 Reply Last reply Reply Quote 2
                  • vicb
                    vicb Paraglider @marekd | Premium last edited by

                    @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.

                    1 Reply Last reply Reply Quote 0
                    • marekd
                      marekd Administrator last edited by

                      @jakubvrana @rittels @vicb Hey guys, public beta is available and a lot of breaking changes are inside. Please, see this post for more details:
                      https://community.windy.com/topic/18358/v34-0-0

                      We would like to release a new version to production at the end of next week, or the beginning of the week after that.

                      We apologize for any complications and hope to complete the refactor soon. Thank you for all your work, we appreciate it!

                      1 Reply Last reply Reply Quote 1
                      • marekd
                        marekd Administrator last edited by marekd

                        @rittels @jakubvrana @vicb If you have accessed the property bounds of any model/product (eg. W.products.iconEu.bounds), please change your codes.

                        We added into client version 34 support for general polygons, so instead of { west, east, north, south } object it is an array of [lat, lon] arrays: [[lat, lon], [lat, lon], ...].

                        All inner methods using bounds still have the same interface, only this property has been changed.

                        1 Reply Last reply Reply Quote 2
                        • Unpinned by  marekd marekd 
                        • First post
                          Last post
                        Windyty, S.E. - all rights reserved. Powered by excellent NodeBB
                        NodeBB & contributors, OSM & contributors, HERE maps
                        Terms and Conditions     Privacy Policy