[Neos] Neos JavaScript Refactoring Work RFC

[Aske Ertmann]

Hey guys

@Sebastian:
Good to hear the review/bugfixing will get some attention. Currently it's something causing quite some issues for our client projects concerning stability. Something I will try to tackle parts of on tuesday.

> For the other half, we'd still like to work on Content Editing
> Refactoring, even though Aske said "the product would not benefit much".
> I quite a lot disagree there; for me it's one of the biggest places
> where we have *huge* technical debt; limiting new features and having
> tons of hidden bugs in there which we did not discover yet.


I’d just like to elaborate a bit on this. What I meant was that in relation to the other things I mentioned I don’t think this topic what will be most beneficial to the product in general at this point. I completely agree that it should happen at some point though. But as I’ve already said I won’t block this, so feel free to continue if you think it makes sense.

I know how the situation is and of the technical debt. I fear that getting rid of this and implementing it ourselves won’t be much less of a challenge, since it’s quite complex and there are many things the existing implementation does handle already. Yes there are bugs which isn’t easy for us to fix, but unidentified bugs wouldn’t differ from re-implementing it ourselves, likely it will introduce even more of them. So I think stabilising it will take quite some work and therefore we should make sure there’s enough time in the budget for that.

Just out of curiosity what features are being limited by the implementation? The split screen stuff or?

@Bastian:

> Personally I think stability (and a better user experience in case of errors) is still the major issue of Neos and I assume that you're planning to address this with the JavaScript refactoring.
> Clients I worked with are already used to press F5 and/or execute "rm -rf Data/Temporary" on a regular basis - a bad sign IMO ;)
> 
> One common scenario:
> Neos session is expired, so the AJAX request gets a 403 but only shows some cryptic error. When reloading the page the login is shown and redirects the browser to the AJAX request that has been intercepted, leading to another cryptic output ;)

As already mentioned I agree that this is a major issue at the moment. I changed the title of https://jira.typo3.org/browse/NEOS-14 from “Improve Content Editing Stability” to “Improving the editor experience” since it’s broader than just stability. I will add additional issues to the topic during the next week. Including making sure that redirect issue is reported.

@Rens:
> A side project I started is a wrapper package for CR as a CQRS / Event-sourcing try-out. This package is for a small part funded by a project we work on, but is a good check to see how event-sourcing could help. I now work on this together with Thomas Maroschik. I don't know about companies interested in this topic, but if there's interest from the EAB (not directly on Neos budget I'd say) or companies that read this: we are of course open to more support :-)


Great to hear that something is happening is this area. This is something I think is becoming more and more something we need. Currently the situation with the workspaces, publishing and proxy nodes has a quite some design flaws leading to content loss and editor frustration. It’s limited multiple editors working on the same content a lot, something currently bound to give issues. Additionally the missing possibility to revert back and see the history is also something editors are missing.

I think CQRS / event-sourcing is the best solution to this and frankly I haven’t heard of anything that will solve quite a many challenges is this. It is however quite a complex topic, which will introduce even more technical debt. But looking at the current situation with proxy nodes I think it not going to be much worse.

I actually think that the Neos budget could be well spend on this. The reason is that I see this being able to solve some very important things:
1) Allow for multiple editors working on the same content, by allowing merging of their changes
2) Decouple moving of nodes with content changes, which is currently causing a lot of issues due to our path node structure
3) History of all specific changes, allowing for seeing the history (what/when), reverting and restoring
4) Allow a more understandable way of counting publishable changes instead of counting the amount of proxy nodes (very confusing to editors when creating/moving pages or content)
5) Prevent loads of duplicated data in proxy nodes

Technically I’d like to see it implemented by getting rid of proxy nodes and only having nodes being snapshots of the events in the node database. All events are of course stored in a table with different kind of events. These events would match actual node migrations, e.g. MoveEvent/MoveMigration or PropertyChangeEvent/PropertyChangeEvent. This would make it possible to have a solid API for working with nodes. For workspaces the snapshot node is used as the base and then the additional events are applied runtime, but the output is cached in the content cache. This does have one major drawback that I know of, which is if the live snapshot is updated by someone else there can be conflicts. Currently we just overwrite those conflicts and ignore them completely, but having to actually have the editor decide on the conflict makes sense. In the case that the editor wants the original content he started editing, taking the snapshot and reversing the events could work or otherwise create a custom snapshot from the beginning. Then the difference between the two can be made into a merge event so that can be applied when publishing again.

Just a few thoughts I’ve had regarding the topic and we at MOC might be interested in helping with this, since I see this becoming a huge problem if we don’t tackle it soon.

Best regards,
Aske