Manual talk:Coding conventions/Vue

Suggestions

edit

@Jdforrester (WMF): I started documenting my own conventions for my Vue work in the global watchlist extension at User:DannyS712/Vue coding conventions, if any of that is of use --DannyS712 (talk) 19:37, 15 December 2020 (UTC)Reply

Thanks. I mostly posted this as tabula rasa to trigger people to propose specific standards, so feel free… :-) Jdforrester (WMF) (talk) 22:42, 15 December 2020 (UTC)Reply

I will add the current "working guidelines" the Structured Data team has been using for Vue development over the next day or two as time allows; if I introduce anything controversial feel free to move it here for discussion or refinement. EGardner (WMF) (talk) 19:28, 16 December 2020 (UTC)Reply

"Use the directive short-hands" - I explicitly chose to use the long form in my work, to be clearer and easier to understand for those (like me at the start) unfamiliar with Vue DannyS712 (talk) 20:08, 16 December 2020 (UTC)Reply
The Vue community seems to prefer the short form generally but I actually agree that long-form syntax is easier and more obvious for folks not familiar with Vue. I'm open to recommending the long-form if we have consensus around that. EGardner (WMF) (talk) 21:05, 16 December 2020 (UTC)Reply
"Component tags must not be self-closing" - this currently is not the case in the ContentTranslation vue files - see [1] DannyS712 (talk) 20:09, 16 December 2020 (UTC)Reply
ContentTranslation Vue components are bundled with Vue-cli / Webpack, meaning that they are not constrained by the current limitations of RL's Vue support. The flip side is that developers working this way have to commit the resulting webpack bundle output (a big blog of minified/uglified JS) to source every time they make a change. I am hopeful that we can come up with some kind of MediaWiki-wide front-end build step in the near future so that this approach is not necessary, but for the time being it's an either/or: Either developers write ES5-compatible Vue code that is delivered by RL and subject to some limitations, or they use their own build tool but must commit the output. We'll have to distinguish between these two use-cases for the time being. EGardner (WMF) (talk) 21:05, 16 December 2020 (UTC)Reply

Backends for Frontends (BFFs)

edit

To what extent does it make sense to shape our APIs to support Vue? Should this be part of the coding conventions? --EProdromou (WMF) (talk) 16:44, 16 December 2020 (UTC)Reply

Good question. For WikiLambda we're definitely shaping our APIs around our "internal" needs first and foremost, though there are other primary external use cases we're seeing. That said, in the past API-driven front-ends were discouraged on the grounds of efficiency/load management, and I guess we'd need to reconsider that if/when it becomes a significant part of the production experience. Jdforrester (WMF) (talk) 17:17, 16 December 2020 (UTC)Reply

Vue CSS conventions

edit

@ATomasevich (WMF): Want to take a first pass at CSS/LESS conventions for Vue files? EGardner (WMF) (talk) 22:39, 16 December 2020 (UTC)Reply

Are they distinct from our normal CSS conventions? Jdforrester (WMF) (talk) 01:46, 18 December 2020 (UTC)Reply

ES5

edit

Code should be written in ES5 and polyfills should be provided for any feature being utilized which may not be present in all Grade-A browsers of MediaWiki's browser support matrix (which still includes IE11 at the time of writing)

Is this still true given Compatibility/IE11? Izno (talk) 20:12, 26 May 2021 (UTC)Reply

vue/html-self-closing error in vue3-es6

edit

There is self-closing-tags limitation within mediawiki, therefore I need to off this rule `vue/html-self-closing` to avoid seeing eslint error. Perhaps should we include this rule off in `wikimedia/vue3-es6`? HTan (WMF) (talk) 09:18, 4 February 2022 (UTC)Reply

Return to "Coding conventions/Vue" page.