Effective Volto 2023 #793
Effective Volto 2023 #793
Conversation
✅ Deploy Preview for plone-training ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
| ## Using a dataAdapter pattern | ||
|
|
||
| Sometimes is useful to adapt the incoming data to other data format, structure or type. | ||
| You can use the dataAdapter pattern in `BlockDataForm` as this: |
There was a problem hiding this comment.
This pattern will cause confusion.
Why is the BlockDataForm looking for a dataAdapter for a certain block? (it's not explained that the BlockDataForm is used internally by the teaser block).
It's not explained how to register the data adapter (although this would be obvious, in theory). The data adapter function uses CamelCase naming, usually reserved for components.
I think it's dangerous to have the data adapter directly call onChangeBlock. I think it's better if the purity of the data operations is kept. No side-effects. If the data adapter is called too late in the data "fixing" chain, then we need to figure out a solution to call it sooner, at the top of the chain, at the level of the "big form".
There was a problem hiding this comment.
@tiberiuichim I completed the docs to make them more consistent and understandable.
Regarding the purity... we are already calling it virtually everywhere, since the default pattern is:
onChangeField={(id, value) => {
onChangeBlock(block, {
...data,
[id]: value,
});
}}in all places. So calling it inside the dataAdapter is "legit", right? Granted, it could be handled better, but as a general improvement of the BlockDataForm.
|
|
||
| function MyComponent(props) { | ||
| const [myVal, setMyVal] = useAtom(mySharedStateAtom); | ||
| return <button onClick={() => setMyVal(val + 1)}>Count up</button> |
No description provided.