Generic Type for current workpiece

[Bastianowicz]

Hi. i haven't thought this through but is it possible to let the Builder instance know what the current Type of its work piece is? This would introduce the benefit of querying only existing properties and also the ability to split cyphers into components (Match Component and return component for example and combine them as you like)

I give you a brief example.

MATCH (u:User {id: $id})-[r:KNOWS]-(f:User)
RETURN {userId: u.id, friend: f.name}

But with the match clause above i could as well like to return sth like
RETURN {userName: u.name, relationship: r.type}

If i change some business logic in how users are connected i have to change every cypher. So i'd like to encapsule the match part and use it for different return cyphers.
I know this is possible already but i think its likely to introduce errors to that since we dont have any reassurance of the type returned.

So what i was thinking about is typing the clauses.
const matchQuery = db.matchNode<UserModel>('user', 'User', { active: true }) where active would be only be available it it is available in the Usermodel.

const matchWhereQuery = matchQuery.where('user',(user:UserModel)=>user.id, greaterThan(18)) with age as well checked if available on current workpieces. Therefore the Builder class would need an extra generic WorkpieceType or something.
As I said I haven't thought this through but I think it might be possible with immutable Builder Instances so you create a new Instance on every change of the workpieces (i.e. in with(), match(), unwind())

What do you think about this aproach? Possible? Usable? Valuable?

[Bastianowicz]

To make it a little clearer i wrote a small example. I created an interface with all the nodes and relationships plus their properties. I bind this as a generic to the match function. By that I can make sure that i only query for existing parameters and thus reduce the likelyness of errors when reusing partial cypher queries.

interface User {
  name: string;
}

interface Item {
  name: string;
  price: number;
}

interface KnowRelation {
  trust: number;
}

interface OwnRelation {
  since: Date;
}

interface UserUserItemRelation{
  user1: User;
  user2: User;
  item: Item;
  knows: KnowRelation;
  owns: OwnRelation;
}

// tslint:disable-next-line:max-line-length
function match<MatchType = any, MatchPatternType extends MatchType[keyof MatchType] = MatchType[keyof MatchType]>(name: keyof MatchType, label? :String, pattern?: Partial<MatchPatternType>): void {
}

match('user2', 'User', { name: 'John' }); // works untyped due to the fallbacks to any
match<UserUserItemRelation, User>('user2', 'User', { name: 'John'}); // compiles and can be written with autocompletion

match<UserUserItemRelation, User>('user2', 'User', { name: 2 }); // won't compile
match<UserUserItemRelation, User>('user2', 'User', { name: "John", price: 3 }); // won't compile

I think i am going to try to introduce that some day but i have my issues with getting to know lodash and stuff. If you find this idea worth discussing please let me know. Maybe you can speed up my learning curve a little ;)

[ImperfectSeven]

@Bastianowicz
I'm curious if you have made any progress with this. I am wanting to accomplish a very similar thing but in my mind I was more of creating typed models that would use cypher-query-builder as opposed to adding types to cypher-query-builder itself. In either case I think being able to have intellisense inform you about what nodes and relationships look like would be very powerful.

[Bastianowicz]

I am actually using a fork of this repo where I did at least a big part of the typing. Although there are so many cases where I use the library differently then I intended in first place I often end up annoyed by the types. On the other hand it has indeed helped me with typos and to structure my calls correctly.
Feel free to have a look. I have paused the delopment atm since it offers enough for me to use it, but would maybe put some afford in it in the future.
To give it a try you can get it via npm / yarn.