Decouple `Node` read-model from `NodeType` (remove `Node::nodeType` field)

[mhsdesign]

With https://github.com/neos/neos-development-collection/pull/4466 the fallback nodetype handling was removed from the core nodetype provider and extracted to neos. (inside a trait NodeTypeWithFallbackProvider) That required to make the nodeType field nullable on the NodeType and we also deprecated it.

Staying in this intermediate step for longer has the following downsides:

• Nodes must always be build with the NodeType attached, which in-turn means the NodeType cannot be readonly immutable because they must be lazy for performance reasons.
  • This fact blocks refactorings/ cleanups like this https://github.com/neos/neos-development-collection/issues/4228
  • Also a high level catchup hook alternative will profit from using the node readmodel similar to signal slot, which is not possible if it requires the schema attached: https://github.com/neos/neos-development-collection/issues/4992
• People will likely not fetch the NodeType via the manager but still rely on Node::nodeType even if its discouraged which will lead to possibly buggy code.
• As we have already a migration from 8.3 Node::getNodeType to Node::nodeType i could very well imagine to adjust this migration to use the nodeType manager: https://github.com/neos/rector/blob/4843c45f5bd901bd63aad0d1d0367df394e2cd1e/config/set/contentrepository-90.php#L145

Same / similar points phrased slightly different from @bwaidelich in slack:

There are two more architectural challenges due to technical debt, that I would like to address with this change:

1.) Node::nodeType it's a nullable property because the actual node type might no longer exist. IMO it would make a lot of sense to get rid of this in favor of $nodeTypeManager->getNodeType($node->nodeTypeName) – again, it should be fairly easy(tm) to replace that with a corresponding helper. And as a result we would not have to load and parse the node type configuration if it is not needed which....

2.) ...will be the case, except that the implementation of Node::getLabel() currently requires the node type instance: return $this->getNodeType()->getNodeLabelGenerator()->getLabel($this) . I would like to get rid of this oddity as well somehow. I'm not sure about the best way, but once again my tendency is another helper that does e.g. $label = $nodeTypeManager->getNodeType($node->nodeTypeName)->renderNodeLabel($node) . An alternative would be to pass the label/label generator to the Node instance at creation time. But that would mean, that we'd always have to load the whole NodeType schema again

[mhsdesign]

As discussed in here

10.) Idk why node label generation is THE most complex thing and it should rather be a Neos concern? It will be tricky to crack that nut while keeping everything lazy. But i dont think that the NodeLabelGeneratorInterface should be constructed with the NodeType and have the Node passed on the actual call. That seems like duplicate information.

I'm not sure what you mean. You wonder why it should be a Neos concern or you suggest to make it a Neos concern? I think the latter, right? And my gut feeling is the same.

$node->getLabel()

would have to be replaced with s.th. like

$nodeLabelRenderer->renderNodeLabel($node);

which would do sth like

$nodeTypeManager->getNodeType($node->nodeTypeName)->metadata['label.generatorClass'] ?? ...

Perfect. For node label generation we introduce a standalone Neos' singleton NodeLabelRenderer which serves as factory for the registered label.generatorClass (the actual extendable NodeLabelGeneratorInterface) and will just require the $node as argument:

https://github.com/neos/neos-development-collection/blob/3fb0d57fd568539f746ee642b944319f8ba8f562/Neos.ContentRepositoryRegistry/Classes/Factory/NodeTypeManager/ObjectManagerBasedNodeLabelGeneratorFactory.php#L23-L32

For Fusion we can create a migration that rewrites node.label to the (new) helper method Neos.Node.label(node) and we are lucky that Node::getLabel is not actually used in the ESCR core itself but only in Neos and Ui, which will be fairly easy to adapt.

[bwaidelich]

Node::getLabel is not actually used in the ESCR core itself but only in Neos and Ui, which will be fairly easy to adapt.

In the core we could easily fix it anyways. The real issue is, that it is used out in the wild. But with rector we should be able to fix fusion and PHP usages hopefully

[mhsdesign]

Fixed via https://github.com/neos/neos-development-collection/pull/5021