Create the Neos JS Content-API / Separation of Core UI from API logic #30
Comments
|
💯 So we won't call this API layer directly in React components, but rather in async action creators, right? Sidenote: to leverage full potential of Redux, we can try to put as few logic as possible on React side (even in containers) and rather create meaningful action creators + selectors, and bind them in @connect. |
|
Right, the points you've mentioned: 👍 |
|
Note for later use: For JSON scheme validations we could use https://github.com/hapijs/joi |
ToDo: Move all of the neos api related actions/reducers into the API bundle ToDo: Move all statements to the new object.
|
Though I could see a stream based API as a more future proof solution, for example if you want to retrieve bunch of nodes and want to process them one node at a time(faster rendering), I think we should start small. So here comes a small and simple API draft. // Needs to be set initially, otherwise the API throws errors.
window.neos.setCsrfToken('myToken');
// Retrieve a node, returns a promise.
window.neos.node('path/to/my/node').get().then(nodeData...);
// Set data of a a node, returns a promise as well.
window.neos.node('path/to/my/node').set({
data...
}).then(newNode).catch(e);I think this will cover pretty much everything, except one thing. We still need events in some way, since inspector editors/wizards will set data of nodes and this needs to be reflected in the main UI (publish dropdown f.e.). Currently I don't know if events will be a good solutions for this, since I don't want us to create a big event mess in bigger UIs with a lot of custom inspector editors. And thats why I was thinking about streams as well... Would love some feedback on this @dimaip @grebaldi @skurfuerst |
|
How do we get multiple nodes with such API? E.g. to render a list of nodes, or render a tree of nodes. |
|
Path is important if you moved nodes and work with structure. Basically on a structural level you will want to deal with paths (child named "foo" of parent "/sites/mysite/home/" etc.) and on a technical level you might want or need to work with identifiers to keep same stuff together across dimensions and workspaces (like references, I reference a specific node and the only valid replacement for other dimensions is a node iwth the same identifier regardless of the path). |
TASK: IconButtonDropDown improvements
|
we won't do this now (before 1.0.0); maybe lateron based on Graphql |
Hey guys!
So today I had a phonecall with @skurfuerst and we both agreed that we need to move fast from the current separation into folder to a standardized API which will in future be shipped with the Neos core package.
For example, currently the service layer and all of the logic for communicating with the Neos Backend endpoints is placed directly in the
Host/folder. @grebaldi already stated in several places that he wants to refactor most of this (f.e. the ChangeManager service).I think we should take this opportunity seriously and go straight into the process of moving most of the logic into a separate API bundle which will always be loaded in the
<head>before every other tag. Afterwards we might want to create an abstraction layer for the current UI, which binds the Neos Content API to the redux-actions.Note that the API itself should not use redux, so we have a clear separation of UI logic/actions and the API itself. A stream based API for the
NodeService, which is accessing the unified node model(which also needs to be created ASAP), and aPublishingServicewhich uses Promises/Generators(?) may be an appropriate solution, but this is only a rough idea in the back of my head.Anyway, looking forward to thoughts of all of 'ya
CC: @grebaldi @dimaip @skurfuerst
The text was updated successfully, but these errors were encountered: