In React, we can use the useMutation or useQuery inside components. But let's say we want to run the query or the mutation inside a helper file (Let's say we extract the part where we format the data and execute the mutation to a helper function away from the component function). In here, we have two options:
Pass the mutation function obtained from useMutation to the helper function
Call the mutation directly inside the helper function like apolloClient.mutate
What is the most recommended way of doing things and what do you recommend?
The hooks expose additional component state for the returned data, loading state and error state. This is really just a convenience because it means you don't have to call useState yourself. As such, it's perfectly fine to use client.mutate if you don't need to keep track of those states. In a sense, it may be better since you're not needlessly using memory for variables you won't use anyway.
The same could be said for useQuery, which really just uses client.watchQuery under the hood and saves you from having to use useState and useEffect.
Related
How can I return multiple object from a mocked factory returning unique_ptr, when the calls cannot be identified through different input parameters to the called function?
I'm doing this:
EXPECT_CALL(MyFactoryMock, create())
.WillRepeatedly(Return(ByMove(std::make_unique<MyObjectTypeMock>())));
And run-time error is:
[ FATAL ]
/.../tools/googletest/1.8.0-57/include/gmock/gmock-actions.h:604::
Condition !performed_ failed. A ByMove() action should only be
performed once.
Doing the same thing only once, using WillOnce, works fine.
Follow-up question: Return multiple mock objects from a mocked factory function which returns std::unique_ptr
ByMove is designed to move a predefined value that you prepared in your test, so it can only be called once. If you need something else, you'll need to write it yourself explicitly.
Here's an excerpt from the googletest documentation:
Quiz time! What do you think will happen if a Return(ByMove(...))
action is performed more than once (e.g. you write ...
.WillRepeatedly(Return(ByMove(...)));)? Come think of it, after the
first time the action runs, the source value will be consumed (since
it’s a move-only value), so the next time around, there’s no value to
move from – you’ll get a run-time error that Return(ByMove(...)) can
only be run once.
If you need your mock method to do more than just moving a pre-defined
value, remember that you can always use a lambda or a callable object,
which can do pretty much anything you want:
EXPECT_CALL(mock_buzzer_, MakeBuzz("x"))
.WillRepeatedly([](StringPiece text) {
return MakeUnique<Buzz>(AccessLevel::kInternal);
});
EXPECT_NE(nullptr, mock_buzzer_.MakeBuzz("x"));
EXPECT_NE(nullptr, mock_buzzer_.MakeBuzz("x"));
Every time this EXPECT_CALL fires, a new unique_ptr<Buzz> will be
created and returned. You cannot do this with Return(ByMove(...)).
When performing mutations it is possible to value refetchQueries update and updateQueries options to provide reaction to current app query results.
However, i'd like to centralize reactive implementation, so various app components performing mutations will not have to deal - likely redundantly - with mutation|query relations.
I noticed ApolloClient constructor's options: ApolloClientOptions.defaultOptions.mutate.* which are functions that give chance to return RefetchQueryDescriptions or operate on DataProxy in response of a ExecutionResult argument alone which, in my opinion, does not provide enough context for the function implementation, as the triggering Operation would also be necessary.
I then took in consideration ApolloLink which seems a perfect candidate, having the chance to hook and override the Operation object, but unfortunately Operation object does not define any of those reacting properties.
Any advice on how to implement my use case?
Generally, whenever we want to wrap a Window/Thread in a C++ object, we do so by passing the this pointer via SetWindowLong/GetWindowLong or SetProp/GetProp for a Window, and as lpParameter for CreateThread/etc.
My question is specific to Hooks. What is the elegant approach to pass the 'this' pointer to SetWindowsHookEx's callback procedures, or in other words How to wrap a hook's callback procedure ?
Since SetWindowsHookEx does not accept any UserData argument, I don't see much options apart from using un-encapsulated i.e. global/static/TLS data.
You are expected to have just one instance of a given hook, so global data is not an issue.
If you are developing a library allowing multiple hook instances that can be dynamically added or removed, do not add multiple hooks at the OS level. Instead, add a library-level hook procedure that walks the list of hook instances. Since you maintain this list, you can track whatever "user data" alongside each entry you want.
The 'most elegant approach' is to use a thunk. It's a small piece of code generated at runtime that holds your this pointer. This is the approach that ATL uses even for regular windows.
See
What is a thunk?
How to generate the code for thunks
C++ WinAPI Wrapper Object using thunks (x32 and x64)
In my project I've multiple threads which have their own V8 isolates. So currently I don't need any v8::Lockers anywhere. But now I want to implement a function "execute" which asynchronously can execute other scripts:
Thread1: execute("script1", "param1"); execute("script2", {param1:
"param1", param2: 5});
Thread2: executes script1
Thread3: executes script2
So far so good... But now I want to pass V8 parameters across isolates. So is there any way to pass a v8::FunctionCallbackInfo argument array from one isolate to another?
With my current architecture I don't need any v8:Lockers, so a solution without having to use them across my whole code base would be preferred.
V8 developer here. v8::Values are generally tied to one isolate. The only way to use them in another isolate is to create a corresponding value there. Depending on your requirements, you can either copy them directly (iterating over the object, property by property, and creating a matching object in the second isolate), or use a serialization format in between (JSON, or StructuredClone, or something you define yourself).
The technical background is that each isolate has a garbage-collected heap, and those values are stored on that heap. One isolate can't access another isolate's heap, so it needs its own copy of any objects it wants to work with. They're called "isolates" because they're isolated from each other ;-)
I'd like to write a nested handler for consumption of json using rapidjson.
I've modeled my basic handler along the lines of the official simplereader example. This is fine for flat structures, but now I need to expand the parsing to nested objects as well.
The way I see it, I can either
have a central handler that keeps track of various domain objects to create and subsequent parse values into, or
I can change handler while parsing
Technically, I know how to do 1., but 2. seems like a neater solution, if possible.
Is it possible to change handlers mid-stream? Is there a best practice for doing this?
Thanks!
You can delegate the events to other handlers. This is often done by:
Applying the State Pattern internally in your custom handler. So that the handler can delegate the events to the current state object via polymorphism (a.k.a. virtual functions).
Using switch-case to do the delegation with an enum.
The first one has advantage if you need to deal with recursive structure. You can push the pointers of state objects in a stack.