Alec Aivazis

not every fragment is refetchable, it has to be defined on a type that either extends Node or has a custom type resolution defined. `@refetchable` would act as a mark...

I think the flag should probably show up in 2 different places: on `fetch` for one-off situations as well a query-level configuration value. Maybe a new `CachePolicy`, something like `NoCache`?...

I'm going to close this to keep it tidy. the store model has drastically changed since this issue was opened and I think it needs to be refined a bit...

Yea, i agree that we probably want to be able to do this. I wonder if it would be enough to support having a floating `graphql` tag which would result...

Another option is that we could kind of merge these a bit so that a reference to an inline query returns the store: ```svelte const FooStore = graphql` query Foo...

i'm personally not a fan of the floating `graphql` tag. i think saying `const foo = graphql` is much more clear instead of having to define a query and then...

hm maybe i'm missing something but i'm not sure what `store` gets you in that example. What i have in mind would look something like ```svelte // type is inferred...

Just a heads up, support for this will be added as part of the upcoming work to support the new KitQL api 👍

After digging into this a bit, it turns out that the issue is that the store's value gets deleted from the unsubscribe which erases the value being rendered (at least...

I have a hunch that #449 will fix this. hopefully one of us will remember to confirm when its merged