RQL ergonomics

[wwaaijer-exh]

Longer term thingy.

Some lose notes:

• find({ rql: q => q.eq('userId', userId) })
• Also for the contains / and / .... rql operators:
  • query.contains('enlistment', subQuery => subQuery.eq('active', true).eq('groupId', groupId))
• Support both forms interface { rql: string | (q:RqlBuider) => RqlBuider }
• v2 → Snake/camel case aware
• v3 → Type aware

[wwaaijer-exh]

Looking at pure character count, it might even be easier to export an Rql helper for the rqlbuilder.

// Internalize
find({ rql: q => q.eq('userId', userId) })
// V.s. helper
find({ rql: Rql.eq('userId', userId) })

Works nicer with sub-queries (like or/contains) as well?

// Internalize
find({ rql: (q) => q.contains('enlistment', subQ => subQ.or(
  subQ => subQ.eq('active', true).eq('groupId', groupId)),
  subQ => subQ.eq('active', false).eq('groupId', groupId2))
)})

// V.s. helper
find({ rql: Rql.contains('enlistment', Rql.or(
  Rql.eq('active', true).eq('groupId', groupId),
  Rql.eq('active', false).eq('groupId', groupId2)
)})

• Also allows for more natural "composability" like you currently can with the rqlBuilder.
• Camel/snake case normalization can still happen by either re-parsing the rql string or the builder being passed as an instance.
• Should still be able to make this type safe as the return type of the builder can inferred from a typed rql option. (to test)
• Easier it implement and move towards to