Uniforms: [QUESTION]: GraphQLBridge error Field not found in schema

[simplecommerce]

Hi,

I have a quick question,

I have a schema which has a custom scalar type called JSON.

My schema is defined like this:

input Update {
  field: JSON
}

Since my field accepts a JSON value, I try to pass field.name as a field name and it keeps giving me an error saying "Field not found in schema".

But in my GraphQL playground I have no problem.

Is there away to make the bridge work with custom scalar types ?

The context in which I am using it is the following.

I have a parent component <Parent name="field" /> and I have a child inside which I wanted to use connectField with.
<Child name="name" />.

This causes an issue because it doesn't exist.

I have read some responses in the previous tickets saying the bridge doesn't support this (custom scalars).

So far my only option I have found that worked, is to not use connectField on the child and use onChange in order to update the sub fields.

onChange("value","field.name")

Which works, but if there are any other ideas, I would appreciate the feedback or input.

Hope you can help, thanks!

[radekmie]

Hi @simplecommerce. The truth is, that there is only partial support for custom scalars.

• Fields can set "unknown fields" in onChange, so onChange('field.a.b.c', 1) will work.
• Fields cannot refer to "unknown fields", as Bridge.getField won't work. The thing is, that uniforms do need to know, what is the type (other properties too, but type is the most important here) of this field. And here, field.a is JSON.a where JSON is a custom scalar - it has no information about its content.
• Custom fields can be used with custom scalars. For example, you can create JSONField, that may render a code editor (or just textarea) and let users paste in their JSON. We've done that actually a few times.
• Custom bridges can be aware of scalars and in their getField function handle it correctly. It may sound complex, but it really depends on your use case - if the scalar is non-recursive (e.g. type GeoPoint { lat: Float! lng: Float! }) then it's simple.

[simplecommerce]

@radekmie Thanks for the reply, with the currently implementation of the graphql bridge, is there an easy way I can extend the getField per use case?

[radekmie]

@simplecommerce I've just checked and it seems that it's not that easy without actually copying the implementation and adjusting it to your needs, sorry. You could call the original one within try block and if it's not found add your own logic.

I was thinking about getType which _is_ easy to extend, but assumes that getField works - this may be useful for scalars without nested fields, e.g. DateTime.

[simplecommerce]

@radekmie ok no problem, I will do it using the onChange which works for the use case I have, thanks for helping out and answering my questions!