Change Details

#### Description #Graph currently uses the #Graphoid service to render graphs on the backend. In order to retire that service, we are planning to switch on the existing front-end-only graph rendering that already exists in the extension. This work has not yet started, as the contractor tasked with it has not yet been hired - we anticipate it will be a short project, and ready for review on beta sometime in February, at the latest. #### Preview environment N/A currently. Listed in TODOs below. #### Which code to review Generally: #Graph Specifically: Whatever changes we make to the code for maintenance purposes, bugfixes, etc. - TBD at the moment. #### Performance assessment Please initiate the performance assessment by answering the below: - What work has been done to ensure the best possible performance of the feature? -- TBD - What are likely to be the weak areas (e.g. bottlenecks) of the code in terms of performance? -- Potentially increased processing on the frontend may cause issues with some devices - check mobile, etc. -- See, e.g., https://en.wikipedia.org/wiki/Template:Graph:Street_map_with_marks for a widely used template which may cause issues for some users. cf. T236892 for more information. - Are there potential optimisations that haven't been performed yet? -- TBD - Please list which performance measurements are in place for the feature and/or what you've measured ad-hoc so far. If you are unsure what to measure, ask the Performance Team for advice: [[ mailto:performance-team@wikimedia.org | performance-team@wikimedia.org ]]. -- TBD TODO (for contractor): [] Test configuration change [] Make changes to Graph extension for maintenance/bugfixes as needed [] List changes here for examination [] Deploy config change and any new code to beta [] Create a test page with at least 1 graph [] Ping this ticket and edit this description to link to the test page [] Briefly audit performance, answer above questions. P.S., sorry for all of the TBD/TODO items. Given the requirement for lead-time and our current lack of progress, we wanted to give you all a heads up so you can schedule a cursory review of the code in time for our rough deadline (middle of Q3).

#### Description #Graph currently uses the #Graphoid service to render graphs on the backend. In order to retire that service, we are planning to switch on the existing front-end-only graph rendering that already exists in the extension. This work has not yet started, as the contractor tasked with it has not yet been hired - we anticipate it will be a short project, and ready for review on beta sometime in February, at the latest. #### Preview environment N/A currently. Listed in TODOs below. #### Which code to review Generally: #Graph Specifically: Whatever changes we make to the code for maintenance purposes, bugfixes, etc. - TBD at the moment. #### Performance assessment Please initiate the performance assessment by answering the below: - What work has been done to ensure the best possible performance of the feature? -- TBD - What are likely to be the weak areas (e.g. bottlenecks) of the code in terms of performance? -- Potentially increased processing on the frontend may cause issues with some devices - check mobile, etc. -- See, e.g., https://en.wikipedia.org/wiki/Template:Graph:Street_map_with_marks for a widely used template which may cause issues for some users. cf. T236892 for more information. - Are there potential optimisations that haven't been performed yet? -- TBD - Please list which performance measurements are in place for the feature and/or what you've measured ad-hoc so far. If you are unsure what to measure, ask the Performance Team for advice: [[ mailto:performance-team@wikimedia.org | performance-team@wikimedia.org ]]. -- TBD TODO (for contractor): [] Test configuration change [] Make changes to Graph extension for maintenance/bugfixes as needed [] List changes here for examination [] Deploy config change and any new code to beta [] Create a test page with at least 1 graph [] Ping this ticket and edit this description to link to the test page [] Briefly audit performance, answer above questions. P.S., sorry for all of the TBD/TODO items. Given the requirement for lead-time and our current lack of progress, we wanted to give you all a heads up so you can schedule a cursory review of the code in time for our rough deadline (middle of Q3). Follow up to @Gilles remarks in T240626#6256188 - [ ] There is no visual fallback when JS is disabled. - user configurable via {T255420} - but we should really provide a default one as well: {T299642} - and there is an issue about being able to know about size mismatches: {T299643} - [ ] The progress spinner appears even if it's only going to be visible for a split second - {T256641} - [ ] The spinner is both embedded in CSS and referred to as a URL - {T256641} and T242855 - [ ] There doesn't seem to be any instrumentation of the performance from the end-user's perspective. - T256638 - [ ] The JS request oddly includes jQuery - haven't checked this yet - [ ] Loading the JS and the data isn't parallelised - this isn't currently even in use, but correct. - [ ] The graph JSON isn't cached - {T256642} - but this is currently not even in use as all graphs are in the variable in the Head of the document

#### Description #Graph currently uses the #Graphoid service to render graphs on the backend. In order to retire that service, we are planning to switch on the existing front-end-only graph rendering that already exists in the extension. This work has not yet started, as the contractor tasked with it has not yet been hired - we anticipate it will be a short project, and ready for review on beta sometime in February, at the latest. #### Preview environment N/A currently. Listed in TODOs below. #### Which code to review Generally: #Graph Specifically: Whatever changes we make to the code for maintenance purposes, bugfixes, etc. - TBD at the moment. #### Performance assessment Please initiate the performance assessment by answering the below: - What work has been done to ensure the best possible performance of the feature? -- TBD - What are likely to be the weak areas (e.g. bottlenecks) of the code in terms of performance? -- Potentially increased processing on the frontend may cause issues with some devices - check mobile, etc. -- See, e.g., https://en.wikipedia.org/wiki/Template:Graph:Street_map_with_marks for a widely used template which may cause issues for some users. cf. T236892 for more information. - Are there potential optimisations that haven't been performed yet? -- TBD - Please list which performance measurements are in place for the feature and/or what you've measured ad-hoc so far. If you are unsure what to measure, ask the Performance Team for advice: [[ mailto:performance-team@wikimedia.org | performance-team@wikimedia.org ]]. -- TBD TODO (for contractor): [] Test configuration change [] Make changes to Graph extension for maintenance/bugfixes as needed [] List changes here for examination [] Deploy config change and any new code to beta [] Create a test page with at least 1 graph [] Ping this ticket and edit this description to link to the test page [] Briefly audit performance, answer above questions. P.S., sorry for all of the TBD/TODO items. Given the requirement for lead-time and our current lack of progress, we wanted to give you all a heads up so you can schedule a cursory review of the code in time for our rough deadline (middle of Q3). Follow up to @Gilles remarks in T240626#6256188 - [ ] There is no visual fallback when JS is disabled. - user configurable via {T255420} - but we should really provide a default one as well: {T299642} - and there is an issue about being able to know about size mismatches: {T299643} - [ ] The progress spinner appears even if it's only going to be visible for a split second - {T256641} - [ ] The spinner is both embedded in CSS and referred to as a URL - {T256641} and T242855 - [ ] There doesn't seem to be any instrumentation of the performance from the end-user's perspective. - T256638 - [ ] The JS request oddly includes jQuery - haven't checked this yet - [ ] Loading the JS and the data isn't parallelised - this isn't currently even in use, but correct. - [ ] The graph JSON isn't cached - {T256642} - but this is currently not even in use as all graphs are in the variable in the Head of the document