Send custom variable to the rules

I couldn’t find a way to send variables to the rule via shield. I’d like to do something similar to this and be able to send multiple variables to the rule(), is it doable? I’ve seen it’s used for cache and fragment, but is there a way?

const rules = shield({
  Mutation: {
    addPage: hasPermission("create", "page"),
    addSpecialPage: hasPermission("create", "special_page"),
  },
});
const hasPermission = rule(action, resource)(async (parent, args, ctx, info) => {
  return true;
});

[maticzav]

Hey @gmahe 👋,

That’s an interesting question! I believe you could solve it by making a rule “constructor” or maybe more of a wrapper.

function createHashableName(action, resource) {
  // this could make use of more sophisticated logic
  return `rule-${action}${resource}`
}

const ruleWithParameters = (action, resource) =>
  rule(createHashableName(action, resource), {
    fragment: 'you can add fragment if you wish',
    cache: 'contextual',
  })(async (parent, args, ctx, info) => {
    return true
  })

const permissions = shield({
  Query: {
    book: ruleWithParameters("read", "book")
  }
})

Pay attention to the createHashableName function. I have used a function to define the name of a rule, but you could also provide string directly. This is especially important for caching functionality since graphql-shield relies on naming conventions of your application. In that sense, if you are to give the same name to two different rules, it will warn you. Long story short, if anything might go wrong, you’ll be warned.

Let me know if you need any help with the implementation! 🙂

PS.: shield generate rules like this; ${name}-${suffix} where the name can be predefined value - like in our case, or a random number assigned to a particular rule. Don’t make a mistake though; rule’s name is generated during rule construction. In that sense, if you reuse the same rule multiple times in your permission tree, it has the same identifier, or, based on your functionality, it should appropriately differ.

suffix, on the other hand, is defined based on the cache option you choose. no_cache yet again generates a random identifier, contextual has no suffix since it won’t differ during execution, and strict hashes the suffix based on parent and args of the resolver.

A simple cheat sheet;

• name -> construction (shield({}), new GraphQLServer)
• suffix -> execution ({ query }, args)

[gmahe]

@maticzav My bad I’ve got confused with the rule’s name in case if action is an array rule-${action}${resource}