Very important: also investigate adding MobileFrontend's lazy loading images implementation and, assuming it's practical, add tasks for:
- Copying or consolidating lazy load JavaScript some place (either in wikimedia-page-library itself or, if necessary, a new place to avoid a cyclical dependency between the page library and MobileFrontend)
- Integrating with iOS, Android, and (if consolidating) MobileFrontend
- Measuring the performance on iOS, Android, and MobileFrontend (just make sure the last report is reproducible)
Compile a list of:
- JS that is not in the WWW folder (in source): none
- JS that is the same as iOS; also consider lifecycles and API
- JS that is different than iOS
- CSS that is the same as iOS
- CSS that is different than iOS: iOS actually uses LESS and supplies override styles locally; Android keeps overrides in an extension
- HTML that is the same as iOS: index.html and preview.html are about the same
- HTML that is different than iOS: very minor differences for static content; iOS loading uses one step file loading, Android uses multistep section loading over the JS bridge
This list will be used to discus potential first action steps for consolidation.
Features for consideration:
- Link preview formatting
- Collapsible elements
- High resolution image transformation
Questions:
- How does iOS order sections for loading into the WebView? How does it cancel loading? iOS saves HTML to a file and then tells the WebView to load it
- How does iOS mix native components with the WebView? What are they? On Android, we have some fancy scroll logic for the lead image, title, and read more. We also have some integration for edit here and share a fact
- Does iOS have bridge message size limits?
- What is iOS currently using the Content Service over MediaWiki API for? How does this affect the JS library? iOS uses MediaWiki