Option to pass return value as argument of next callback

[sminnee]

For graphql 4, I created a “ComposedResolver” class which does almost the same thing (sequential user defined callbacks) except it passes the previous result into the next callback. Maybe a feature request? We could consolidate. 😏

A sort of reducer or "iterative transformer" could be provided by passing the return value of the first function as the argument of the 2nd, and so on. At the end, return the final result.

• Presumably this would only work for a function of a single argument. If multiple arguments are passed to such a call-back, it should probably ignore subsequent arguments.
• Should a return value of null be handled specially? Does it mean "pass null to the next callback" or "pass the original value to the next callback"? The former risks erroneously created callbacks causing heisenbugs, the latter means that null can never be returned.
• How should such a callback-chain be set up?
  • A property setter on the class to switch to this mode of operation? Now the call/invoke methods need a different return-type signature.
  • A subclass with an overridden call() method? That breaks liskov substitution.
  • An alternative call method? Now it's opaque from looking at the class how it's intended to be used.

[unclecheese]

So have a look at this and see if it makes sense: https://github.com/silverstripe/silverstripe-graphql/blob/cedacb79929745bd1d49bf9309e68c7679c7a90e/src/Schema/Resolver/ComposedResolver.php

Presumably this would only work for a function of a single argument. If multiple arguments are passed to such a call-back, it should probably ignore subsequent arguments.

Not necessarily. In my example, you see I'm just replacing the first argument each time, but that's very graphql specific. I reckon you just pass $prevResult as the final argument.

I also append a $done argument to the params so that any single function can cancel execution (like event propagation).

Should a return value of null be handled specially?

I think it null is okay, because in my example, you're not destroying anything. Each callback still receives all the original values.

    public function call(...$args): array
    {
        /** @var array<mixed> $results */
        $results = [];
        $prevValue = null;
        foreach ($this->callbacks as $callback) {
            $callbackArgs = array_merge($args, [$prevValue]);
            $prevValue = \call_user_func_array($callback, $args);
            $results[] = $prevValue; 
        }

        return $results;
    }

You might not want to have $prevValue default to null so that a user could hook into "this is the first callback", in which case, you would leave it undefined and do the array_merge in an isset condition, and a user would have to do a count($args) check to see if it's one short.

[sminnee]

Could you post an example of how the linked resolver in GraphQL is used?

[unclecheese]

So if you look here, this is the abstract PaginationPlugin (no assumptions about DataList):

https://github.com/silverstripe/silverstripe-graphql/blob/cedacb79929745bd1d49bf9309e68c7679c7a90e/src/Schema/Plugin/PaginationPlugin.php#L92

It's using ->addResolverAfterware() to apply a (to be defined in the concrete layer) pagination function.

Then if you look at the concrete layer, the DataList paginator:

https://github.com/silverstripe/silverstripe-graphql/blob/cedacb79929745bd1d49bf9309e68c7679c7a90e/src/Schema/DataObject/Plugin/Paginator.php#L31

It can assume there that $obj is a DataList that has already had ->filter() calls made against it, for instance.

A key place where this matters would be something like the canViewPermission plugin, where you need to ensure that it comes absolutely last, so it can do a filterByCallback and obscure any sensitive data from the result set.

... if only there was some hastily scrawled ACL module we could use 🤔