Tue, May 4
Mon, May 3
I'm afraid my method wasn't terribly efficient or effective, but here it is:
Whew, I'm glad to hear it's working on prod now! Thanks for keeping an eye on this one, @Etonkovidova
Wed, Apr 28
Also, from a code organization standpoint, we could lean on the composition API to contain reusable props, computed properties, methods, etc. I need to make sure that props pulled in from a composable display as expected in Storybook, to make sure separating code doesn't make it harder to read components, but I'm hoping this won't be an issue.
Tue, Apr 27
Thanks for the explanation, @Etonkovidova! I'm glad to hear it's working in the latest Chrome versions now—this is a tricky piece of functionality to get right in all browsers
Mon, Apr 26
@Mooeypoo shared this helpful article and pointed out that we should consider whether this input is truly binary if it can have an indeterminate state. The other libraries I looked at treat this state separately from the on/off states, and I especially like Buefy's treatment where it's just used as an attribute on the input for the sake of styling it properly. But I'd like to get a better understanding of exactly what we need from an indeterminate state (which, I should note, seems to be very rarely used in MediaWiki projects).
I'll add this when I add the Radio component as part of T281186.
Sun, Apr 25
Wed, Apr 21
Tue, Apr 20
Mon, Apr 19
Calling this "done" might seem a little hasty, but I think this ticket can be closed. We've reviewed the readme and decided to keep following the processes, although we may add and amend some as we do things like introduce a front-end build step to MediaWiki, evolve our testing paradigms, and add more code. I think this task has served its purpose and more specific discussions can happen in future tasks or patches.
Thu, Apr 15
Wed, Apr 14
@Raymond do you have thoughts on Matthias's comment above?
Tue, Apr 13
Fri, Apr 9
Thu, Apr 8
I'm going to be a bit opinionated here because I'm happy with the way the binary inputs turned out in MediaSearch. We based these components on the Buefy implementation, and they're quite simple both from a library code standpoint and from an end-usage standpoint. Some details:
I've opened a patch to fix the layout problem, but the select lists are working as expected now.
Hey @sbassett, all patches are now merged and I've updated my comment to reflect this. Thanks again for the useful feedback!
Wed, Apr 7
@DannyS712 good call, I've added information on where icon data is located to the icon implementations listed here.
@DannyS712 Please see above, and let me know if you notice anything missing!
MediaWiki Vue projects
Tue, Apr 6
I've opened T279469 to track the new issue.
This is resolved, although there are some errors popping up in logstash related to the change (9 in the past day): Unable to get property 'appendChild' of undefined or null reference
@sbassett Thanks very much for fitting this in, and for the helpful feedback! I've added responses below more for my own organization and ability to communicate with the team, but I'll update with a separate comment once all of the medium risk items are mitigated.
Apr 5 2021
Apr 1 2021
Thanks for compiling all of this, @Catrope! Some initial thoughts:
Fix has been deployed, but I'll keep an eye on the logs for a while before closing this.
Mar 31 2021
@sbassett Thanks for letting me know! Totally understand—we'll look for more later this week.
Mar 30 2021
@mwilliams I'm curious to hear what you think about the hover behavior for the namespace filter. Should it match the hover behavior of the select lists, or should it be different? The namespace filter button is an actual button, so we could consider using button hover styles, which I think is what the select lists use too.
Mar 26 2021
Mar 24 2021
Sounds good, thanks!
@mwilliams thanks for all the thoughts!
@mwilliams, what do you think about item 2 in Elena's comment above? What she's describing matches the acceptance criteria, but I just want to confirm that we should reset the namespace filter to the current state represented in the search results. I'm concerned about throwing out someone's choices if they close the dialog and come back to it, or if they accidentally close the dialog.
Mar 23 2021
Thanks @matthiasmullie! I think the only thing missing from that plan is the messages - seems like we should update the MediaSearch extension to depend on WBMI messages for now, then as part of deployment 3(?), we can go through the process outlined here to move WBMI messages to MediaSearch, rename them, and remove them from WBMI.
Mar 22 2021
@matthiasmullie would you mind outlining the process you think we should follow to transition from Special:NewMediaSearch to Special:MediaSearch in the new extension? Will we need to merge this change right before deployment with a corresponding one in WBMI?
Mar 19 2021
Thanks for the update, @sbassett! If you can ping me here when you start your review, I'll make sure we pause merging work into the extension.
@Seddon The new select list styles made me realize that there's an existing problem with the gradient that we're showing at the end of the filters on small screens to indicate that the user can scroll for more: