Research spike to explore the technical details of the Vue,js framework as it relates to the current architecture of VE. The outcome is to identify opportunities, risks, and areas for further exploration.
**Milestones (Updated September 18, 2020)**:
- June 25 - July 25: Expert consultation and trainingDue September 21: Completed experiment wrapping top-level VE editor-component into a Vue component; document trade-offs and level of effort involved
- Due June 30October 1: Completed experiment wrapping top-level VE editor-componcreating a single component Vue interface wrap; document into a Vue component;challenges, trade-offs, document trade-offs and level of effort involved
- Due July 30: Completed experiment creating a single component Vue interface wrap; document challenges, trade-offs, and level of effort involvedOctober 10: Draft migration plan circulated to team for feedback
- Due August 15: Draft migration plan circulated to team for feedback
- Due August 30:October 20: Final migration plan completed
- What “things” (features, classes, patterns etc) are there to migrate?
- Which of them will be challenging?
- What patterns exist in vue.js which might fit with our existing codebase?
- Is there any benefit to migrating our class and mixins handling to vue, now or in the future?
- To vue components entirely?
- To ES6 classes with a transpile step?
- Are there any blockers in the coordination of sync and sync events to making VE a reusable vue component
- Is anything in vue.js behaviors fundamentally inimical to, e.g., IME usage / contenteditable quirks?
- For a complete port
- For switching just the UI components in VE to vue
- For a wrapper around VE which lets it be a contained vue component
- Should we replace OOUI’s EventEmitter or move it into VE?