FANDOM


  • I will soon update the Chat-js button integration so that it's more responsive.

    When in desktop view, any resizing or button additions reflows the dropdown! I added a dev.chat.reflow hook, in case you'd like to add JS to your scripts to fix them.

    There's a screenshot of it here:

    Chat-js_dropdown_update.png

    If you would like to test it, go to Special:Chat and import this in your console:

    importArticles({
        type: 'script',
        articles: [
            'u:speedit:User:Speedit/chat.js',
        ]
    });

    I'll add it to Chat-js documentation by next week, pending some final testing. Any queries or suggestions are welcome :)

      Loading editor
    • Seems good! Though at line 223/224 of Chat-js.js, I'm not sure why wds-button class is removed and immediately added back.

      I did notice some small styling issues but not sure if they're directly Chat-js related, or just issues in WDS. Notice the top border has a 1px gap at the top-left of each button, and the dropdown seems to be inconsistently coloured. Also, if all items are in the dropdown, the dropdown has no left border.

      One thing I wonder (but not directly related to this change) is why $.proxy is used? Unless you need to support IE8, the native bind function seems a better choice. Also, relying on an animation event seems fragile, but if you have no alternative…

        Loading editor
    • OneTwoThreeFall wrote: Seems good! Though at line 223/224 of Chat-js.js, I'm not sure why wds-button class is removed and immediately added back.

      I did notice some small styling issues but not sure if they're directly Chat-js related, or just issues in WDS. Notice the top border has a 1px gap at the top-left of each button, and the dropdown seems to be inconsistently coloured. Also, if all items are in the dropdown, the dropdown has no left border.

      In the case where there are buttons in the main list and dropdown, the .wds-button class isn't consistently present. So the script accounts for:

      • whether the class is already there (not in dropdown; will result in duplicate class)
      • making sure .chat-toolbar__button is a higher priority class

      I think I also confused myself when writing it, so I've made it less redundant & muddled now.

      The dropdown coloring is entirely in Chat-js, so it's likely a bug there. I'll have a look at styling fixes today, thanks for reporting.

      One thing I wonder (but not directly related to this change) is why $.proxy is used? Unless you need to support IE8, the native bind function seems a better choice. Also, relying on an animation event seems fragile, but if you have no alternative…

      Bind sounds okay. I believe bind does not override function guid, but a well named jQuery event namespace can deal with that. animationstart.devchat :)

      The animation event has been more reliable than the other methods (setInterval, MutationObserver etc). But yes, perhaps something more DOM-agnostic would be useful.

      Here's one solution:

      1. for Chat._init event, chain 'mediawiki.api' event with load event of the chat_js2 script (in comination with $.ready). A custom Chat._controller.$ready Deferred promise would be effective.
      2. bind to the 'initial' event of mainRoom for Chat._main. Code's in the Chat-js documentation.

      Due to Chat's nature, I'd have to do a lot of testing to verify it can achieve the same load order in all cases. Chat events are slower than one would expect, but if it's one event to listen for, that's arguably fine.

        Loading editor
    • Update: it turns out that the Chat and Chat-js load order are mostly unaffected by ditching the animationstart order! :D Here is the code so far.

      By exerting better control on the load order of Chat things, I've also been able to reduce conditional depth to 1 max. But I'll be holding onto it till Monday, seeing as a bug in Chat-js will set all of Dev Wiki on fire :p

        Loading editor
    • Quite nice! Ideally Fandom would add a mw.hook in there, but failing that, this seems like a decent alternative!

      Regarding this lines:
          document.querySelector('script[src$="chat_js2"]')
              .addEventListener('load', this.$ready.resolve);

      You may want to add a .bind(this.$ready) to the event listener, else this will be the object the event was added to. I'm not sure if jQuery's deferred uses the current this value or caches it when creating the deferred object, but just in case!

      On a similar note, lines like this._socket.bind(this)(); could be simplified to this._socket(); - the this value will already be correct.

        Loading editor
    • $.Deferred does cache the this value as self, but it passes the current context to fireWith in the callback.

      > dev.chat._controller.$ready.resolve
      $ ƒ () {
            self.fireWith(this, arguments);
      	 return this;
        }
      

      I've chosen to bind it as a precaution, and unbind any window.dev.chat method calls (a win-win on script length & safety!).

      Here's the final code.

        Loading editor
    • A FANDOM user
        Loading editor
Give Kudos to this message
You've given this message Kudos!
See who gave Kudos to this message