docs VS apollo-client

MS docs ar now on github. Licence lists "CC-BY-4 and MIT licence found" https://github.com/dotnet/docs/tree/main

Yeah, I saw that devdocs and the like don't include what was previously not cross platform and not popular for linux guys: C#, msbuild.

You might be able to do something with this: https://github.com/dotnet/docs

The browsy bits seem to require a server, but the documents themselves are markdown.

Use a coding style for all files and all methods. (see or this or the Framework design guidelines)

But no... they don't want to listen. Just take a look at the GitHub issue https://github.com/dotnet/docs/issues/27420: people are asking for an option to choose, but they don't receive any genuine answer, only someone who asks them "Why?" repeatedly, without offering any solution.

I have no idea what was in there mind to force this minimal agenda. If you look at this issue on github https://github.com/dotnet/docs/issues/27420 you will see that there is not much support for this and a lot of disappointed people, myself included. This also transfers to asp.net.

While you're at it, consider leaving feedback for the C# team. It'd be nice for them to start feeling the pain newbies feel.

The docs are on GitHub. If you think there's an improvement to make here, please submit a PR.

This is less meaningful than you think. The docs are open source on GitHub and they are written in markdown. You can just clone it and keep a local copy. Unless your goal is to print them, the markdown version of the docs is massively superior.

Actually, it's worse than that. Next has started throwing errors if it statically detects you even _importing_ hooks inside of a React Server Component environment:

- https://github.com/apollographql/apollo-client/issues/10974

- https://github.com/apollographql/apollo-client/issues/11167

To the point that Lenz Weber( a maintainer of Apollo Client, and my co-maintainer on Redux Toolkit), is considering resorting to a package that wraps and re-exports all of React's public API just to avoid that static analysis:

- https://github.com/apollographql/apollo-client/pull/11175

Apollo Client (18k ⭐) -> A comprehensive state management library for JavaScript that enables you to manage both local and remote data with GraphQL. Use it to fetch, cache, and modify application data, all while automatically updating your UI.

This currently doesn't work as expected so I have logged this issue in apollo client repo.

I understand this has something to do with the fact, that SvelteKit expects the client and server code to be completely identical - this has already prompted changes to rxjs and apollo is still pending to be fixed. I understand the reason behind being able to run rxjs and apollo on the server but

There is a long-standing issue with error caching (its absence, that is), which leads to errors being rendered as a loading state on the server side. Therefore, if you're doing SSR, you might want to design your schema in such a way that there are no intentional errors in queries whatsoever. To do so, we can use null values instead of NOT_FOUND errors (see how we essentially treated errors as data here?). Note how nothing stops us from setting the response code to 404 in case of a null value, should we want so.

Lol apollo client too.. saw this issue opened like, immediately after the release https://github.com/apollographql/apollo-client/issues/10231

If you look at how major backend projects structure their code, it's almost always object-oriented TypeScript.

I submit for the record:

- Apollo Client: https://github.com/apollographql/apollo-client/blob/main/src...

- Storybook: https://github.com/storybookjs/storybook/blob/next/lib/chann...

- Nest: https://github.com/nestjs/nest/blob/master/packages/core/nes...

- MongoDB Driver: https://github.com/mongodb/node-mongodb-native/blob/main/src...

- Prisma: https://github.com/prisma/prisma/blob/main/packages/engine-c...

We’re heavy users of Apollo GraphQL in my team at Swarmia, but sometimes mocking the queries is bothersome. And based on a few GitHub comments, it looks like we’re not alone. This blog post is here to help!

I have a functional component built around the React Table component that uses the Apollo GraphQL client for server-side pagination and searching. I am trying to implement debouncing for the searching so that only one query is executed against the server once the user stops typing with that value. I have tried the lodash debounce and awesome debounce promise solutions but still a query gets executed against the server for every character typed in the search field.