Front-end standards group/2020-06-24

Attending: Itamar Givon, Lucas Werkmeister, Jakob Warkotsch, Tonina Zhelyazkova, Joe Walsh, Ed Sanders, Eric Gardner, Stephen Niedzielski,  Jan Drewniak, Volker Eckl, Anri Bolon, Roan Kattouw, Anne Tomasevich, Sarai Sánchez

Action & CodeEdit

New questsEdit

  • Self-closing tags rewrite needed and shorthand syntax: [RK]
  • Using RemexHtml gerrit:598133 instead of PHP's HTML Parser – In practice, this change means:
    • Before: self-closing tags like <slot /> or <mw-button icon="trash" destructive /> work
    • After: self-closing tags break, so instead you have to write <slot></slot> and <mw-button icon="trash" destructive></mw-button>
    • Before: shorthand syntax doesn't work, so you have to write <mw-button v-bind:disabled="buttonDisabled" v-on:click="onButtonClick">
    • After: shorthand syntax works, so you can write <mw-button :disabled="buttonDisabled" @click="onButtonClick">
    • Putting it together: we used to write <mw-button v-on:click="buttonDisabled" />, now we will write <mw-button @click="buttonDisabled"></mw-button>
    • There are lint rules to enforce this: – people should update their eslint config versions to benefit from new rules
    • When writing a Vue component, write // @vue/component above your module.exports = { ... statement to get linting
    • ES: […] Generally one should avoid eslint warnings; to make warnings into errors, you'd have to add max-warnings=0 which some do
    • Have a look at the test fixtures to see what is considered valid/invalid:
  • Lil discussion about general rules how to write Vue yet, with some early decisions and orientation on  default Vue guidelines. Future plan: Manual:Coding conventions/Vue.js alongside eslint-config-wikimedia
    • Folks seem generally happy with short-hand syntax for now
  • Newly started OOUI component migration path outline Vue.js/OOUI migration guide [SN]
    • ES: Clarify “Avoid inheritance”. OOUI Mixins (f.e. ButtonElement) are useful not to repeat yourself
    • EG: Vue doesn't really follow an inheritance paradigm. Vue mixins has private state too
    • Some discussion about when to keep components in individual projects and when to contribute them to the library; some considerations:
      • don’t want to slow down project development
      • don’t want to slow down library development
      • early library development gives others more opportunity to give feedback on the components before they solidify
      • using the library in production brings additional responsibilities for library development
      • proposal: start a first pull request for one component soon!
      • Phab ticket per component
    • Action: Create Phabricator tasks to keep track of features that new components are still missing compared to OOUI (when they’re not in scope for the initial PR)
  • Eslint works, stylelint doesn't
  • WMDE is building a separate component library specific to Wikibase. Design is mostly aligned with WMF design, process for technical alignment is still in progress. Experience: When different feature teams contribute to the same library without consulting UX, it leads to a lot of confusion and components that cannot be used because they don't comply to design.
  • Action: Involvement in exemplatory component PR discussion for WVUI