Option to pass return value as argument of next callback

[sminnee]

Option to pass return value as argument of next callback

[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 🤔