Scope and plan the JavaScript work for Q4 2021/2022

[vanitabarrett]

What

We know that the scale of "the JavaScript work" is huge. We need to:

• brainstorm all the things that this work could include (e.g: identify issues, pain points and areas of improvement)
• figure out any dependencies
• prioritise this work somehow

Why

We need to have a clear idea of what the JavaScript work involves and develop some kind of plan/roadmap for delivery.

Who needs to work on this

Developers; PM

Who needs to review this

Developers; PM

Possible things to include

This is a list of issues that have come up in recent developer catch-ups and L&D sessions that we might want to include in our scoping/planning:

• Duplicated JavaScript code (specific example was copying the error summary JS to help with the new skip link JS). Could we write and use helpers more?
• Lots of large functions (specific example was the accordion JS). Should we be breaking down our JS functions into smaller chunks? The Frontend Masters course on Enterprise Architecture Patterns suggests that functions should only do one job and should be no more than 20 lines long (3-8 is ideal).
• We can't currently write unit tests for our JS
• We use gulp tasks to build Sass, copy and move assets around etc in our build pipeline. Gulp and its plugins are old and not well maintained. Some of these things are pinning us to dependencies with security vulnerabilities. We also lack gulp knowledge on the team, so it's difficult for us to work on changes to the gulp tasks
• Similar to the above, we use Metalsmith for the Design System website which is old and not well maintained now.

Done when

• Collect together all the possible issues with our current JavaScript
• Run session(s) to figure out if any issues are linked/dependent on each other
• Run session(s) to prioritise issues, lay out a rough roadmap and decide our goals for the quarter
• Update the epic card

[nitin094-hub]

hey, could you plz explain how can I contribute to this project? I am a beginner,

[vanitabarrett]

Hi @nitin094-hub - if you're interested in contributing to this project it's probably worth reading our Community information and our Contribution guidelines. We welcome people raising Github issues if they spot any bugs and/or contributing fixes and new components themselves if they feel something is missing.

[vanitabarrett]

We're collecting all the JavaScript issues in a Mural board which we'll go through in a session on Mon 17th Jan. After the session, I'll make sure all issues are written up on Github and tagged with the 'javascript' label so they can be viewed together in one place.

[vanitabarrett]

Moving this into blocked until we've had the session on 17th.

[vanitabarrett]

Summary of effort / value sessions

3 sessions over 2.5 hours from 17th-19th of Jan 2022.

The tech squad had several sessions this week to build a shared understanding of everything contained within the “JavaScript work”. For each issue we discussed what it is, the problem(s) it’s causing, any linked cards or dependencies, and we attempted to map it on an effort/value chart (seen below).

Summary of effort/value mapping

• We didn’t map anything to high effort & low value (i.e: things we’d probably put to one side for now)
• The majority of the issues were mapped to medium-high value and effort, for example: revisiting our JavaScript testing strategy; shipping polyfills to all browsers; and internationalisation.
• A couple of outliers which seem like more stand-alone issues and which we could potentially pick up (but it depends if we see value in picking them up on their own):
  • Review application can mislead if a component is polyfilled #674
  • Investigate components being initialised more than once #1127
  • Get visibility over web performance metrics #2076
  • Components failing initialisation break due to .js-enabled styles #999
  • Cannot import standard ES6 modules from npm #711

There were a couple of issues which we didn’t feel we could map. These were mostly things we think we need to consider throughout the JavaScript epic/every time we pick up a ticket. These were:

• How any changes we make will work for maintainers of ports. We know that some currently have to re-implement our JavaScript and therefore lose some of the benefit of using ours (e.g: accessibility built in).
• Documentation, e.g: code conventions, tooling choices

One ticket which kept being mentioned and which seems to underpin a lot of this work is revisiting our legacy browser support. This will help us make decisions on things like our approach to polyfills and tooling choices. Depending on our decision, it may mean we can use features we currently avoid.

Next steps

We think the next steps are to make sure we've identified as many dependencies as possible, and then begin to map out a rough sequence for the work. As part of this, we will consider whether work needs time for research, proposals and/or community engagement as this will extend how long it takes to complete.

[vanitabarrett]

We've continued to map out the work on the Mural board. Our focus of this quarter is #711 and #2503 . We still need to finish a conversation around how and when we begin work on supporting internationalisation - we could put a short-term solution in place to "buy" us a bit more time. We didn't really have time in the session today to come to a conclusion on this as there are pros and cons for each option (short-term i18n; building a perfect i18n system first time; a welsh language toggle)

[vanitabarrett]

I'm going to close this card for now as we've planned out the majority of the work for this quarter (at least enough to keep us going for the next month). We can write up a new epic card when we start planning the i18n work.