semanser ( Andriy Semenets )

The cache you created with new InMemoryCache(...) class is not meant to be used directly, but passed to the ApolloClient constructor. The client then accesses the cache using methods like readQuery and writeQuery. The difference between cache.writeQuery and client.writeQuery is that the client version also performs a broadcast after writing to the cache. This broadcast ensures your data is refreshed in the view layer after the client.writeQuery operation. If you only use cache.writeQuery, the changes may not be immediately reflected in the view layer. This behavior is sometimes useful in scenarios where you want to perform multiple cache writes without immediately updating the view layer.
The update function receives cache rather than client as its first parameter. This cache is typically an instance of InMemoryCache, as supplied to the ApolloClient constructor whent the client was created. In case of the update function, when you call cache.writeQuery, the update internally calls broadcastQueries, so queries listening to the changes will update. However, this behavior of broadcasting changes after cache.writeQuery happens only with the update function. Anywhere else, cache.writeQuery would just write to the cache, and the changes would not be immediately broadcast to the view layer. To avoid this confusion, prefer client.writeQuery when writing to cache.

Source: https://github.com/apollographql/apollo-client/pull/4664/files

wzup

comment created time in a month

startedwez/wezterm

started time in a month

startedtssm/up-to-date-real-world-haskell

started time in a month

startedjunegunn/vim-peekaboo

started time in a month

startedliuchengxu/eleline.vim

started time in a month

startedneoclide/coc-smartf

started time in a month

startedgrain-team/vttyl

started time in a month

startedwellle/context.vim

started time in a month

startedseanmonstar/reqwest

started time in 2 months

pull request commentgraphql/graphiql

Add VIM keybindings support

@acao so, I guess adding more tests has no sense, because this PR is going to be rejected?

semanser

comment created time in 2 months

push eventsemanser/graphiql

Andriy Semenets

commit sha 51bdc0e7bb3aecfcb5b656f28f1676b760a694b5

Add even more tests

view details

push time in 2 months

pull request commentgraphql/graphiql

Add VIM keybindings support

ugh i hate to do this because you did a great job of implementing this, and i asked you to add tests. That's totally fine, don't worry :)

for your purposes currently, is there a way you can just require codemirror-vim in a way that overwrites those bindings in a more minimal fashion?

What do you mean with that? Right now, I'm using the default codemirror vim keybindings (and I guess they should work fine). I guess for now, this implementation can work pretty well, and can be replaced later with plugins.

semanser

comment created time in 2 months

push eventsemanser/graphiql

Andriy Semenets

commit sha f9571c198dd5b5c1ec758825fc6aacdefdcab438

Add more tests

view details

push time in 2 months

Pull request review commentgraphql/graphiql

Add VIM keybindings support

 export class QueryEditor extends React.Component {     require('codemirror/addon/dialog/dialog');     require('codemirror/addon/lint/lint');     require('codemirror/keymap/sublime');+    require('codemirror/keymap/vim');

For the toggling between vim/sublime modes, we need to have these files to be preloaded.

semanser

comment created time in 2 months

push eventsemanser/graphiql

Andriy Semenets

commit sha c66374fb8e8db24b3f4262e800fdeb14226f4dea

Add basic tests

view details

push time in 2 months

startedyarnpkg/yarn

started time in 2 months

startedhecrj/iced