profile
viewpoint

loicmarie/hands-detection 84

Hands video tracker using the Tensorflow Object Detection API and Faster RCNN model. The data used is the Hand Dataset from University of Oxford.

loicmarie/lichess-opening-explorer 6

Wrapper for the Lichess Opening Explorer public API written in node.js

loicmarie/binance-bq-ticker-crawler 2

Tickers data crawler from Binance Exchange websockets API to Google Cloud Big Query

loicmarie/code-area 2

Polymer element wrapping CodeMirror (highlighting syntax, plugins and options)

loicmarie/lichess-statfish 2

Lichess deployment for Statfish UCI module.

loicmarie/ng2-chessboard 2

Angular 2 module wrapping chessboardjs library as a component

artonge/VocHodor 0

Projet de TAN

loicmarie/akita-ng-fire 0

Akita ❤️ Angular 🔥 Firebase

issue commentvuejs/vue-apollo

Cannot use apollo in Typescript @Component decorator with 'components' key

@Akryum the purpose of the composition API for vue 2 is to let developers experiment the composition API in Vue 3. But it is not something to be used in production, as stated on the repo in bold:

We do not recommend using this package for production yet at this stage

So using the composition API in Vue 2 seems not to be a viable solution, is it ? I think there should be both:

  • a vue-apollo release for Vue 2 without using the composition API
  • optionally a vue-apollo release for Vue 3 using exclusively the composition API

Don't you think solutions built around the composition API for Vue 2 will be compromised at Vue 3 release ?

Acidic9

comment created time in a month

issue commentgraphql-compose/graphql-compose

addTypeResolver() should accept InterfaceTypeComposer as type parameter

After some testing I found out that I can make it work with resolverType field and getType() function:

const StudentTC = schemaComposer.createObjectTC({
  name: 'Student',
  interfaces: ['Person'],
  fields: { name: 'String', year: 'Int' }
})

const TeacherTC = schemaComposer.createObjectTC({
  name: 'Teacher',
  interfaces: ['Person', 'Employee'],
  fields: { name: 'String', title: 'String', domain: 'String' }
})

const DirectorTC = schemaComposer.createObjectTC({
  name: 'Director',
  interfaces: ['Person', 'Employee'],
  fields: { name: 'String', title: 'String', headsSince: 'Int' }
})

const EmployeeTC = schemaComposer.createInterfaceTC({
  name: 'Employee',
  interfaces: ['Person'],
  fields: { name: 'String', title: 'String' },
  resolveType: (value) => schemaComposer.getOTC(value._label).getType()
})

const PersonTC = schemaComposer.createInterfaceTC({
  name: 'Person',
  fields: { name: 'String' },
  resolveType: (value) => schemaComposer.getOTC(value._label).getType()
})

const students = [{ name: 'Jean', year: 2020, _label: 'Student' }, { name: 'Albert', year: 2022, _label: 'Student' }];
const teachers = [{ name: 'Simon', title: 'Mr', domain: 'maths', _label: 'Teacher' }];
const directors = [{ name: 'Alfred', title: 'Mr', truc: 'machin', headsSince: 101, _label: 'Director' }];

schemaComposer.Query.addFields({
  persons: {
    type: '[Person]',
    resolve: () => students.concat(teachers).concat(directors)
  },
  students: {
    type: '[Student]',
    resolve: () => students
  },
  employees: {
    type: '[Employee]',
    resolve: () => teachers.concat(directors)
  },
  teachers: {
    type: '[Teacher]',
    resolve: () => teachers
  },
  directors: {
    type: '[Director]',
    resolve: () => teachers
  }
})

const schema = schemaComposer.buildSchema();

const req = `
{
  employees {
    name
    title
    ... on Teacher {
      domain
    }
    ... on Director {
      headsSince
    }
  }
  persons {
    name
    ... on Employee {
      title
    }
    ... on Teacher {
      domain
    }
    ... on Student {
      year
    }
    ... on Director {
      headsSince
    }
  }
}
`;

graphql(schema, req).then(res => {
  console.log(JSON.stringify(res, null, 2))
})

And then nested inheritance is possible. Would be cool to be able to do this with addTypeResolver method, without need of GraphQL types.

loicmarie

comment created time in a month

issue openedgraphql-compose/graphql-compose

addTypeResolver() should accept InterfaceTypeComposer as type parameter

Currently the addTypeResolver() method is defined as:

addTypeResolver<TSrc = any>(
  type: ObjectTypeComposer<TSrc, TContext> | GraphQLObjectType,
  checkFn: InterfaceTypeComposerResolverCheckFn<TSrc, TContext>
): this

But since interfaces can implement others, the resolveType method of an interface should allow to resolve an interface type too.

Minimal example:

const PersonTC = schemaComposer.createInterfaceTC({
  name: 'Person',
  fields: { name: 'String' }
})

const EmployeeTC = schemaComposer.createInterfaceTC({
  name: 'Employee',
  interfaces: ['Person'],
  fields: { name: 'String', title: 'String' }
})

const TeacherTC = schemaComposer.createObjectTC({
  name: 'Teacher',
  interfaces: ['Person', 'Employee'],
  fields: { name: 'String', title: 'String', domain: 'String' }
})

const StudentTC = schemaComposer.createObjectTC({
  name: 'Student',
  interfaces: ['Person'],
  fields: { name: 'String', year: 'Int' }
})

PersonTC.addTypeResolver(EmployeeTC, value => {
  return value.hasOwnProperty('title');
});
PersonTC.addTypeResolver(StudentTC, value =>{
  return value.hasOwnProperty('year');
});
EmployeeTC.addTypeResolver(TeacherTC, value =>{
  return value.hasOwnProperty('domain');
});

const students = [{ name: 'Jean', year: 2020 }, { name: 'Albert', year: 2022 }];
const teachers = [{ name: 'Simon', title: 'Mr', domain: 'maths' }];
const directors = [{ name: 'Alfred', title: 'Mr' }];

schemaComposer.Query.addFields({
  persons: {
    type: '[Person]',
    resolve: () => students.concat(teachers).concat(directors)
  }
})

const schema = schemaComposer.buildSchema();

const req = `
{
  persons {
    name
    ... on Employee {
      title
    }
    ... on Teacher {
      domain
    }
    ... on Student {
      year
    }
  }
}
`;

graphql(schema, req).then(res => {
  console.log(JSON.stringify(res, null, 2))
})

According to the spec, it should work, but it ends up with:

Error: For interface type resolver Person you must provide GraphQLObjectType or ObjectTypeComposer, but provided InterfaceTypeComposer

If you have any idea about how to reproduce such a multi-level inheritance schema, it would be very welcome. I tried to use resolveType parameter in InterfaceTypeComposer, but it needs a GraphQL type, and I don't think there is a "graphql-compose" way to get the GraphQL generated type from the interface or object composer.

created time in a month

issue commentgraphql-compose/graphql-compose

Support for adding interfaces to other interfaces

That was fast ! Thanks !

loicmarie

comment created time in 2 months

issue openedgraphql-compose/graphql-compose

Support for adding interfaces to other interfaces

In the latest GraphQL spec release, interfaces can now implement other interfaces. It has been shipped in GraphQL JS 15.0.0 so it should already be available in this repo.

This is a very useful feature when dealing with many deeply nested subsumption relations :+1:

Would it be possible to add ObjectTypeComposer interface methods to InterfaceTypeComposer ? Such as:

  • getInterfaces()
  • getInterfacesTypes()
  • setInterfaces()
  • hasInterface()
  • addInterface()
  • addInterfaces()
  • removeInterface()

created time in 2 months

issue openedneo4j-graphql/neo4j-graphql-js

Invalid input in generated query when using inline fragments inside fragments

Seems inline fragments does not work inside other fragments. I have this schema :

interface Contribution {
  id: ID!
}
type Post extends Contribution {
  id: ID!
  text: String
}

And now, I want to query Contribution:

query {
  Contribution {
    id
    ... on Post {
      text
    }
  }
}

This works well. But now if I try to use inline fragments inside a Contribution fragment:

query {
  Contribution {
    ...Contribution
  }
}
fragment Contribution on Contribution {
  id
  ... on Post {
    text
  }
}

It results in strange errors, such as:

Invalid input '(': expected an identifier character, whitespace, ':', ',' or '}' (line 1, column 167 (offset: 166))\n\"MATCH (`contribution`:`Contribution`) RETURN `contribution` {FRAGMENT_TYPE: head( [ label IN labels(`contribution`) WHERE label IN $Contribution_derivedTypes ] ),head([`contribution` IN [`contribution`] WHERE \"Event\" IN labels(`contribution`) | `contribution` { FRAGMENT_TYPE: \"Event\",  .id  }] + [`contribution` IN [`contribution`] WHERE \"Post\" IN labels(`contribution`) | `contribution` { FRAGMENT_TYPE: \"Post\",  .text , .id  }])} AS `contribution`\

Seems like the generated query is missing a variable name somewhere. This is odd, because it is really common to use fragments in combination with inline fragments when dealing with interfaced types.

created time in 2 months

issue closedneo4j-graphql/neo4j-graphql-js

Exponential response time with nested fragments in query

It seems that using nested fragments in queries results in exponential response time. With generated query/mutation and typeDefs :

type Image {
  id: ID!
  url: String
}
type User {
  id: ID!
  displayName: String!
  email: String
  photo: Image @relation(name: "HAS_PHOTO", direction: "OUT")
}

when sending multiple time a query such as:

query User {
  User {
    ...User
    __typename
  }
}

fragment User on User {
  id
  displayName
  email
  photo {
    ...Image
    __typename
  }
  __typename
}

fragment Image on Image {
  id
  url
  __typename
}

Response time will grow up until it crashes Version : 2.13.0

closed time in 2 months

loicmarie

issue commentneo4j-graphql/neo4j-graphql-js

Exponential response time with nested fragments in query

Sorry I just saw it was related to #415, and NPM version is not synced with master. It is not happening anymore when using latest commit. Waiting for NPM deployment :)

loicmarie

comment created time in 2 months

issue openedneo4j-graphql/neo4j-graphql-js

Exponential response time with nested fragments in query

It seems that using nested fragments in queries results in exponential response time. With typeDefs :

created time in 2 months

more