Problem/Motivation
While working on #1678002: Edit should provide a usable entity-level toolbar for saving fields, it became more apparent that our Create.js/VIE.js architecture in the Edit module would not support (easily) the interaction pattern we're trying to build. Namely that one interactions primarily with an entity for in-place editing -- one edits fields in the context of an entity and saves changes in the context of that entity.
jessebeach took several days to determine if it would be feasible to factor Create/VIE out of the Drupal codebase #1678002-71: Edit should provide a usable entity-level toolbar for saving fields and we determined yes, we could do it in a reasonable amount of time and effort. Wim Leers developed these reasons for the refactor in #1678002-72: Edit should provide a usable entity-level toolbar for saving fields:
- It depends on VIE.js, which does five zillion things we don't need; it assumes RDFa (which is "not correct/accurate enough" in Drupal, see earlier issues) and JSON-LD (which won't be in D8 core after all). It's *huge*. 34 KB minified! We're currently only really using a tiny, tiny subset of VIE.
- Create.js deeply depends on jQuery UI Widgets, which are a huge PITA to use. It's extremely confusing. We've been wanting to refactor that out of Create.js, but that is a *huge* undertaking. And it's not clear how we'd retain backwards compatibility, which is a requirement.
- https://github.com/bergie/create/issues/133, https://github.com/bergie/create/issues/137 -> Create.js doesn't have per-field state change handling, like we need. Instead, we've been pretending for all the time that Create.js has been in core that each field is an entity, which is obviously not the case. Now that we need entity-level state AND field-level state, that breaks down. It's possible to hack around, but… it requires a significant change in Create.js and it will break backwards compatibility. Bringing those changes to Create.js (in a BC way, mind you!) is likely going to be at least equally complex as moving away from Create.js. And that's not the only issue. And we'd still be fighting jQuery UI Widgets. Etc.
- Overall, Create.js makes *way* too many assumptions. Because it was originally built as a specific implementation of in-place editing, with its own UI. Whereas it now claims to be a platform for in-place editing. That's not really true yet.
- It's abstraction for in-place editors ("PropertyEditor widgets") is not really an abstraction. It, too, makes way too many assumptions. It does event binding+handling, which it should not do *at all*. That's why we've been unable to reuse or even just subclass Create.js' PropertyEditor widgets.
- https://github.com/bergie/create/issues/142
- With all of the above, the removal of Create.js and particularly the removal of VIE.js would result in a huge decrease of the amount of JS to be downloaded, parsed and executed for in-place editing.
The most salient reason from the list above is this one:
Create.js doesn't have per-field state change handling, like we need. Instead, we've been pretending for all the time that Create.js has been in core that each field is an entity, which is obviously not the case. Now that we need entity-level state AND field-level state, that breaks down. It's possible to hack around, but… it requires a significant change in Create.js and it will break backwards compatibility.
We will keep #1678002: Edit should provide a usable entity-level toolbar for saving fields focused on the introduction of an entity-level toolbar for in-place editing. This issue here will become the home of the Create/VIE out-factoring.
Proposed resolution
Remove Create/VIE from Drupal. Refactor the existing Edit JavaScript to leverage Backbone Models and Views. This is already the case to some degree, but because Create uses jQuery UI to handle Widget creation and eventing, these aspects of the application will need to be ported to Backbone. Most of this porting is already completed and working as before.
Remaining tasks
Separate #1678002: Edit should provide a usable entity-level toolbar for saving fields into two issues and move the refactor code here.
Finish porting functionality to the new Backbone Models and Views.
User interface changes
See #1678002: Edit should provide a usable entity-level toolbar for saving fields.
API changes
Some, but since no code is leveraging these systems yet outside of Edit/Editor, the changes will not break anything.
Related Issues
#1678002: Edit should provide a usable entity-level toolbar for saving fields