Storage link leftovers are present in reducers

[theodorDiaconu]

If I have a reducer that uses a link. And the storage is on the current side. There is no mechanism to clean reducer leftovers. This is a difficult problem to solve, because we really don't know what the reducer returns since it's a function.

The reducer may or may not return the object uncleaned.

So it's a question:

1. Do we do another process that does this check ? (can be costly)
2. We leave it up to the developer to take control over what reducer returns (meaning we leave it this way)

[theodorDiaconu]

We don't want to touch reducer's result after it returned. So there's no way to solve this nicely unless we clean storage before passing it to reduce computation. But this propagates to other issues related to performance.

[bhunjadi]

@theodorDiaconu What do you mean by And the storage is on the current side - client side maybe?

Is this situation similart to this test?

In the test groupNames is a reducer that uses groups link. But I am missing something because in this test I believe everything is cleaned properly.

[theodorDiaconu]

I mean that if I query something like this:

posts: { comments: { } }

postId is fetched by Grapher to be able to do the assembly.

But let's say you have a reducer that uses comments, then postId reaches the reduce() function. And if you return let's say the first comment. (Because you have a reducer lastComments), then postId will be present in it.

[bhunjadi]

Thanks, I understand now. Yeah, I agree with your conclusion that cleaning before passing to the compute is probably the correct solution. The problem was that I was under the impression that this is already done in reducer computations because I thought that reducer's body was also used for projection.