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 & Code
editNew quests
edit- 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: https://github.com/wikimedia/eslint-config-wikimedia/pull/298 – people should update their eslint config versions to benefit from new rules
- When writing a Vue component, write
// @vue/component
above yourmodule.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: https://github.com/wikimedia/eslint-config-wikimedia/tree/master/test/fixtures
- Before: self-closing tags like
- 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