Support query outside of pages and layouts

[houdinigraphql]

Support query outside of pages and layouts

[AlecAivazis]

@thormuller I ran into something interseting while debugging this - if I change /src/routes/qry/index.svelte to look like

<script>
	import { query, graphql } from '$houdini';
	const { data } = query(graphql`
		query AllUsers {
			kitchenlab_users {
				email
				uid
			}
		}
	`);
</script>

{$data.kitchenlab_users.length}

Then I see the query being fired and a result is rendered. I'm going to keep poking at this to see if i can figure out the difference between this page the Login component but at least there is some progress.

edit: Whoops wrong button!

[AlecAivazis]

Hey @thormuller!

It might help to understand what the generated load function looks like so you can add logs in the right spot to capture the information you are investigating. At the moment, the most reliable place to see this is one of the snapshot tests. The top snapshot is what is generated for the load function and the second snapshot is what's left behind in your component. If you want to just test that load is being called where/when you think it is, you can add a console.log in the constructor for RequestContext. You should find a very similar file to the one in that link inside of $houdini/runtime/network.js.

It's probably worth mentioning, for anyone who finds this issue, that the first request your application fires will get logged on your server, not in the browser console. Queries that fire after the first request will be sent from your browser and logged in the browser's console.

[thormuller]

Brilliant, thanks for the tips. I'll give that a go.

[thormuller]

The issue is with line 15 in query.js:

const initialValue = document.initialValue.data;

There is no initialValue on document which leads to the aforementioned error. Does that imply that something is off in the configuration somewhere? The document object in query.js looks like this:

{
  initialValue: undefined,
  variables: undefined,
  kind: 'HoudiniQuery',
  artifact: {
    name: 'AllUsers',
    kind: 'HoudiniQuery',
    hash: '3509969641628a2b17ad4cbc3c28a55b',
    raw: 'query AllUsers {\n  kl_users {\n    email\n    uid\n  }\n}\n',
    rootType: 'query_root',
    selection: { kl_users: [Object] }
  }
}

[AlecAivazis]

Hm, well getting that far means the load function didn't see an error in the response. It also means that the data field in the response is undefined Having a query with no value and no errors seems like something is going on with the requests to the server.

Are you seeing load invoked when you navigate to a route? If so, do you see either data or errors in the response from your environment?

Regardless, we clearly need a better error message if query is invoked with an undefined initial value.

[thormuller]

I'm not seeing the log message when I load the route with the query. I'd think the load would happen before the query was fired, but I see no evidence of it. The log is in network.js like so:

export class RequestContext {
    constructor(ctx) {
        console.log("network.js")
        this.continue = true;
        this.returnValue = {};
        this.context = ctx;
    }

[AlecAivazis]

Do you see anything if you add a log on the api side of resolving kl_users? Fwiw, you are correct that you should see the log before the queries fires.

Is this the same repo you shared earlier? If so, mind pushing it up so I can take a closer look? Assuming that you have schema.json commited, I dont need access to a working API in order to see your problem so no need to worry about making that accesible

[thormuller]

Thanks! Just pushed the latest up to that repo. I hope this proves useful for general purposes!

[thormuller]

FYI, logging confirms the graphql api is not receiving any requests, while it is receiving Apollo requests from the same SvelteKit app just fine.

[AlecAivazis]

Ah, I think i have found the problem. The loading documentation says that:

load only applies to components that define pages, not the components that they import.

Since query desugars into a load function, I think this means that, at the moment, query only works in pages and layouts (ie, things that are inside of src/routes). This is definitely not intended - query should absolutely behave the way you expected. I'll try to get something out in the coming days to support this

[thormuller]

Aha, that makes sense. I can work around this in my situation. Again, many thanks for investigating my code–at least it seems like a useful case for future development. I'll stay tuned for how I can help this project as it blossoms!

[AlecAivazis]

No problem at all! I'm very excited to hear that at someone else is going to be using houdini - especially since you are clearly willing to opening tickets when you run into issues 😄

I'm currently trying to gather some people I can reach out to in order to validate PRs coming out. Would you mind if I tag you when I add support for query outside of pages/and layouts to test?

[thormuller]

Absolutely! Happy to help.

[pixelmund]

Supporting queries outside pages is a must however svelte ssr in my understanding isn't async the only way to fetch is per load/preload i believe. What im curious about is what you will do for variables/function. Since there is no load in Components we will pass the variables directly to the query or what will/should it look like? Also this could be a good point to think about the api for variables. I don't know if i like the current approach.

[AlecAivazis]

@pixelmund - I agree that the current approach is kind of clunky. Maybe it would help if I explained why the variable API is the way it is.

in order to get access to the page variables (so users can do something like pull a filter value from the url) the logic for computing the variable needs to be accessible in the module script where the actual network request happens. If the variables were just a static value, this wouldn't be a problem - the preprocessor could just copy the value up to the right script. Unfortunately that's too big of a limitation since a user could import external packages or put all sorts of complicated logic in that function. That means that the preprocessor would be forced to hoist up any necessary logic to perform the computation. By forcing the user to define their variable function in the module context, we can guarantee that anything that the user used to compute their variables is also accessible to the load function without any complicated hoisting logic.

All of that being said, the function defined in the module context is accessible to the normal script so we should be able to support routes, pages, and components all with the same API without worrying about the issue i outlined above. It definitely feels a little weird at first but Im not sure if there is an alternative that doesn't introduce a lot of complexity in a part of the application that's hard to debug. Definitely open to alternative tho!

[pixelmund]

That makes completely sense to me. I can't think of another alternative, so explaining why it is like that would probably be the best decision right now.

[AlecAivazis]

@thormuller I think I have a working update to support query in a component outside of src/routes. Mind pulling down #95 and giving it a shot?