Page MenuHomePhabricator

Spike to understand the constraints around using WVUI in sticky header
Closed, ResolvedPublic5 Estimated Story PointsSpike

Description

As we embark on our adventure building the sticky header, one question we are not 100% sure about is whether we can build the entire feature in Vue.js. This will influence a decision around how to build our component.

Currently Vue.js and WVUI are pulled down when a user focuses the search box. If the search box is focused on load, the libraries will load straight away.

However we've noticed in other cases, for example the use of Vega library for graphs on the Facebook page, these scripts load on page view. It's not clear if these are bugs, and if so why they are not being treated as UBN (T272530). This has led to some confusion amongst the team around what is acceptable and what isn't.

Questions to answer

To help inform this decision, we should meet with the design systems (first) and performance teams (later) and understand several things from both their perspectives.

  1. What does critical path mean to the performance team, given our JavaScript is loaded asynchronously. What are the risks of loading Vue.js/WVUI on page load for all users? What problems would this manifest to the user/Wikimedia operations? (This question should help us knowledge share and understand the problem better going into the next questions)
  2. Under what circumstances could Vue.js be loaded on page load ? (Note: please avoid the answer "never", there must be some world where this can be true)

2a) For logged in users
2b) For anonymous users
2c) For all users

  1. What events would it be acceptable to load Vue+WVUI ? For example, we currently load on focus, would this loading strategy be acceptable on the following events (and if not why, if it depends please elaborate)?:

3a) Scroll event
3b) click event
3c) (Mutation/intersection)Observer event (e.g. an element comes into view at a certain place in the page)

  1. Would it be acceptable to load WVUI/Vue.js after a time delay?

Outcome

A Google Doc or etherpad should document the learnings here, particularly for those not involved in the conversation. Note, we are not looking to make a decision, just to capture knowledge.

Suggested approach

We'll probably want to tag performance team when ready and setup a meeting. Team members should be made optional, but include those who want to be involved and make sure the document is easy for those that didn't attend to understand.

Prototype

https://di-community-round-2.web.app/Audre_Lorde

Event Timeline

Restricted Application changed the subtype of this task from "Task" to "Spike". · View Herald TranscriptJul 27 2021, 10:34 PM
Jdlrobson renamed this task from Spike to understand the constraints around using WVUI to Spike to understand the constraints around using WVUI in sticky header.Jul 27 2021, 10:34 PM

hi @Jdlrobson - some Qs for you:

To help inform this decision, we should meet with the design systems (first)

I'm happy to set up meetings to get the ball rolling on this spike -- not sure who/which team you mean by design systems? Do you mean UX designers?

I'm intuiting that we want buy-in from the performance team early on in this process. Rumor has it the eng mgr for that team retired recently. I have a foggy recollection of you mentioning getting a meeting set up?

which team you mean by design systems? Do you mean UX designers?

That would be the Vue.js migration team: Volker, Anne and Roan. Sorry for the confusion. I think it might make sense to meet with them alongside the performance team.

Meeting with Design Systems team et al scheduled for 8/17/21

For example the use of Vega library for graphs […], these scripts load on page view. It's not clear if these are bugs, and if so why they are not being treated as UBN (T272530). This has led to some confusion amongst the team around what is acceptable and what isn't.

I wouldn't call this an "example" as it is unprecedented and there is nothing like it anywhere in prod that I'm aware of. In short, no, this isn't acceptable. Details at T285890#7289104.

Debrief from meeting:

The basic consensus was that it does not make sense to build the sticky header using Vue/WVUI at this time since the new shared component library's initial efforts will be to replicate WVUI's components in order to decommission that project as early as possible.

Additional considerations:

  • We would have to custom build most of the pieces of sticky header prototype anyway (user menu, section change of state, custom tooltips, etc)
  • ULS button - Vue implementation not feasible for Language team at this time
  • Project scope: even if we were to build the prototype in Vue, do we want to take on the additional issues introduced by gadgets and other elements in production?
  • Once Vue SSR + Vue 3 is in place, the sticky header (or specific parts of it) could be a great candidate for SSR + client-side migration (maybe in 6 months?).
  • Would the sticky header meet the governance criteria for the shared component library?
    • Some notes on reusability:
      • There's an IntersectionObserver component that was built for MediaSearch's infinite scroll feature (emits event on scroll) that might be applicable to sticky header's section state.
      • There was a component built for Visual Editor using OOUI (sticky popup toolbar element) that hasn't been reused in its 7 years (they even tried to re-use it - complex enough to want to be re-used, yet not simple enough that it needs tweaking) -- would be good to share documentation around that experience even if it's not re-usable code.
  • Hard part already done/built and in production - user menu dropdown includes no-js support with the checkbox hack
  • In future where a Vue menu component exists with SSR, menu can be rendered via SSR with the checkbox hack that works w/o javascript and once it hydrates on the client, we can keep or get rid of checkbox once javascript is available (jives with Vue Summit takeaways where dropping IE11 support can be mitigated by upping no-js support). Good strategy to have minimal interactivity where possible/feasible to be (optional) part of SSR'd components.

Last thoughts:

  • Would be great to have a clear rubric about when and when not to use Vue (i.e. kb threshold) - having Vue SSR will make this much more feasible
  • Or to implement some kind of performance risk assessment like we do to evaluate security risk
  • Perhaps easier to take bytes out of consideration and look at experience requirements (i.e. in the middle of extremes: user dropdown menu that should work on page load vs going deeper into the app experience with a modal dialog ). Fallback will be PHP + mustache which might be higher cost.
  • Proposed base components T289023
cjming added a subscriber: cjming.

I need to watch the recording and read through the notes. Will then sign off.

Adding to above debrief notes, see also the Observer (IntersectionObserver) code in MediaSearch.

Making the sticky header without Vue.js makes sense for at least now. But in web team conversations a requirement to reduce the load time for search inside the sticky header has emerged. This follow up question has been captured in T289718. We have enough to resolve this particular task.