Discussion about Recoil patterns
ulises-jeremias opened this issue ยท 7 comments
I just saw the different states that can be found on this repo and I wanted to ask if it is possible to define states that contains arrays using memoization (or if is already being defined like this).
For example, you have the atom
/**
* Used to know which nodes (ids) are being selected by the user.
*
* Can be a single node, several nodes, or none of them.
*/
export const selectedNodesState = atom<string[]>({
key: 'selectedNodesState',
default: [],
});
So I can imagine that there is another state that contains nodes like this
const nodesState = atom<NodeType[]>({
key: 'nodes',
default: [],
});
and use it as
const [nodes, setNodes] = useRecoilState(nodesState);
but maybe it is interesting to use something like this that react europe showed on their video about recoil using memoization
const nodesState = memoize((id: string) => atom<NodeType>({
key: `nodes-${id}`,
default: { . . . },
}));
and use it as
const id = "specific-id";
const [specificNode, setNode] = useRecoilState(nodesState(id));
so then you can implement components for specific single atoms, and then render those components inside a .map
or things like that.
What do you think? would it be possible to think of something like this for this project?
Could you point to the Recoil Europe video you're mentioning?
I don't understand the benefit of using memoization with recoil. (but I'm not familiar with the topic)
Do you mean it would be possible to update only one node/edge at a time, instead of updating the whole dataset?
The code you're looking for is:
canvasDatasetSelector
https://github.com/Vadorequest/rwa-faunadb-reaflow-nextjs-magic/blob/main/src/states/canvasDatasetSelector.ts which handles all elements (nodes/edges) at the top-level and relies onnodesState
andedgesState
nodesState
https://github.com/Vadorequest/rwa-faunadb-reaflow-nextjs-magic/blob/main/src/states/nodesState.tsedgesState
https://github.com/Vadorequest/rwa-faunadb-reaflow-nextjs-magic/blob/main/src/states/edgesState.ts
My reasoning behind this design was I didn't want to update all nodes when mutating a single node (in practice, that never happens), or to update all edges when mutating a single node (that happens much more often).
But, having the ability to control the whole dataset and each element individually to avoid rendering everything when something changes would be very interesting, performances-wise.
Sorry for the delay! I had a lot of work to do! Yes, I was talking about this video https://www.youtube.com/watch?v=_ISAA_Jt9kI&ab_channel=ReactEurope that appears in the main page of recoil js.
Yes! It is exactly that, It makes it possible to update only one node/edge at a time, instead of updating the whole dataset.
I can do a PR with a small change to do it for those atoms you mentioned and we can discuss it on the PR ๐๐ป
@ulises-jeremias Hey! I was away a few months working on something else, I don't quite remember where we left the conversation, but I'm still interested in having the dual ability of mutating the whole dataset at once, or item by item.
Have things evolved on Recoil's side?
Edit: I haven't watched the video, I'll do it soon!
The video is really interesting, I've learned a few things!
I'd love a PR, if you still have the time ๐
Hey! Yes! Recoil is more stable now and also I planned some new features for the devtools hehe
I'll try to do a PR shortly ๐๐ป
I think we can keep this issue open to track the progress and continue the discussions here
Awesome! One thing I didn't quite get by watching the video is how to achieve both "per-item" and "batch" mutations. As some operations will need to mutate all elements at once (e.g: "reset" feature), although most of them should perform per-item mutations, for better performances.
Also, I wonder how that change should affect the DB. At this moment both the DB and the nodes
/edges
Recoil stores behave the same way, it's basically an array that's being mutated when any change occur.
If we change the way nodes
/edges
Recoil stores work, it seems logical to apply the same logic to the DB, especially considering the app performs real-time DB mutations and is meant to be efficient in a collaborative context (where many people might mutate the state at the same time).
Altough it's possible not to do everything at once (start with Recoil first), it's something worth being considered for later.