Related tasks:

• T138642: VisualEditor should provide a clean integrated VE/WT editor widget that can be integrated into any context
• T284673: Determine best practices for communicating between VE and other UI components

@dchan and I have had a few discussions about this. Here's a summary of what we've discussed so far:

• We should prioritize assessing the feasibility of migrating VE's UI to Vue.js, so that it can use the same Codex components that will be used by other UIs. Migrating the other layers of VE (CE and DM) is much less valuable, so we're not looking at that.
• Currently, VE is very synchronous, and UI updates often happen synchronously in response to model updates. Vue would introduce asynchronicity here. We want to focus our thinking and our experiments on whether this could cause problems, and how those problems could be avoided.
  • For example, the link context item has an "unlink" button that will remove the link that the selection is in. But what if a click event comes in for that button, and in the meantime the selection has already moved to a different link, or somewhere that isn't a link? How do we detect this case?
    • (Note that the existing implementation in ve.ui.LinearContext already updates context items asynchronously in response to selection changes, so to some extent this is already a theoretical possibility that we don't protect against in the existing OOUI-based code.)
• For now, we think a promising architecture would be to introduce a "glue" layer that sits between the DM/CE and the Vue UI, receiving updates from the DM/CE through synchronous event handlers and updating Vue refs that represent certain aspects of the state of the DM/CE. These refs are updated synchronously, but the Vue UI reacts to those updates asynchronously. This makes the "glue" layer a sort of buffer zone between the synchronous world of DM/CE and the asynchronous world of the Vue UI.
  • This glue layer could be implemented as a Vuex store or a Pinia store. But for simplicity, we think that our proof of concept prototypes should not use a store, but a loose collection of refs and computed refs.
• We think we should start by prototyping Vue implementations of two VE UI components:
  • The toolbar: T308713
  • The link context item (plus, optionally, the link inspector): T308714