Thank you for the reproduction here Sebastian.
Service not implemented
First thing to note, is that this is not an error - it’s a warning coming from the VSCode Redwood extension that is trying to be helpful (but failing in this case!)
As DT pointed out - the VS Code Redwood extension looks for schema’s in a certain place. You are welcome to raise an issue for this - but we are still to make a decision on the ongoing support of this extension.
I assume you are trying this to understand what Redwood is doing underneath rather than actually want to structure your project that way? It doesn’t look like you’re actually implemented a custom sdl - they’re still the same things that would be generated if you used yarn rw g sdl BookSerie
?
Cannot query field “books” on type “BookSerie”. Did you mean “Book”?GraphQL: Validation
This does not seem be an issue in your reproduction - I’m able to make the query - can you double check that it’s still an issue?
exported variable MUST be named just like the query in SDL
This is true, and a requirement. You will thank yourself later for maintaining this practice too!
Imagine having a query getMyBooks
and the service function called retrieveBooksFromDatabase
- it’s totally fine to do, once you have a few dozen queries and services in your project, you may find it confusing!
Personally I do not think we should add support for renaming the service functions to not match the query - because atleast this way it’s clear that there is a naming convention that must be followed.
I just now regenerated user with SDL and it would add UserResolvers hat were not there a sec ago at all
This is likely that you’ve changed your User
model - before it did not have relations, and now it does.
Redwood will generate “UserResolvers” when it realises that there’s a DB relation between User and something else. I now call these “relation resolvers” - but in reality they are just field resolvers.
Any property defined in the export const User = { customField: () => xxx }
will only be called, if the request has a customField
in it. This can be a powerful tool to optimise your database queries - for example if customField did heavy DB queries, you don’t really want to fetch it from DB unless the client actually requested it.
Apollo adds __typename: ‘Book’ to the query results and that needs to be stripped before handling it to another component -
I’m not sure why you would need to strip it out? Unless you have a prop called __typename
it should be harmless.
It looks to me like you’re trying to pass the result of your query, directly into your mutation. So QueryBook → UpdateBook - which seems a little odd. You probably want to pass the data from the form and not the original Book that you passed in.
How should lists of 100s or 1000s of elements be handled in such select fields?
This feels like a philosophical question - do you really want your user to edit 1000s of fields in one go? Why not separate your fields into different categories that they can edit e.g. Metadata, Author details, etc.