Cannot return <AmplifyContext.Provider /> because property client is missing in React.Element 1 but exists in Client
How to fix the error?
Try Flow
The direction for the solution is to type return value with usage React.Element and React.ComponentType. I put together the start of the solution (open in flow try), though I fell that better typing around client still needed there
Related
I'm using next js for my application and I'm facing some issues with routing to the previous route of the application. I know that there is a function like router.back(), but I do not know if I can go back from the current page.
I have read that we can check history.action !== 'POP' but now I check that history has no action property when using console.log(history)
I am using next/router.
Way too late to be useful but for the next person that comes along: If I read your question correctly, you're wanting to know if there is something in the navigation stack that you can navigate back to - and you want to do something else if there is no history.
You can use window.history.state to get a glimpse; although it doesn't give you clear access to the history stack the state has an "idx" property that is incremented when a location is added to the history stack. This means that if window.history.state.idx is zero there's nothing in the history stack, if it's bigger than zero then there is something in the history stack and you can navigate back.
An example for navigating back if you can or doing something else if not:
if (window.history.state && window.history.state.idx > 0) {
router.back();
} else {
// Do something else
}
Whenever I call a function that has (enforce-guard some-guard) from X-wallet or Zelcore it always fails with the error Keyset failure (keys-all)
I have no issues when doing this from Chainweaver
How to fix this
This is an issue if you are also providing capabilities with your request.
To fix this, you will need to put enforce-guard within a capability too.
So you will need to do something like
(defcap VERIFY_GUARD (some-guard:guard)
(enforce-guard some-guard)
)
And wherever you would call enforce-guard , you will then need to do
(with-capability (VERIFY_GAURD some-guard)
; Guarded code here
)
Why does this happen?
Chainweaver allows you to select unrestricted signing keys, which provides a key/guard for enforce-guard to work with.
However X-Wallet and Zelcore don't provide this if capabilities present on the request (otherwise they do).
It is probably better practice to add enforce-guard into capabilities anyways and use require-capability in places where you expect the guard to pass.
The following flow:
SignedTransaction stx =subFlow(new RedeemFungibleTokens(amt, issuer, new LinkedList(), criteria));
...is giving me "InsufficientBalanceException: Insufficient spendable states identified for 1 TokenType(tokenIdentifier='ABC', fractionDigits=0) issued by Node1."
This even though I am using identical "criteria" to a call to QuerybyAccount which returns a state with 30 of these tokens. And actually, even if I take out the "criteria" entirely, it still gives the same exception.
What could be wrong?
The trick was mentioned here:
https://github.com/corda/token-sdk/issues/146
Simply to use TokenType rather than IssuedTokenType. who knew? :)
I need to fetch from BaaS data store all records that doesn't match condition
I use query string like:
https://api.usergrid.com/<org>/<app>/<collection>?ql=location within 10 of 30.494697,50.463509 and Partnership eq 'Reject'
that works right (i don't url encode string after ql).
But any attempt to put "not" in this query cause "The query cannot be parsed".
Also i try to use <>, !=, NE, and some variation of "not"
How to configure query to fetch all records in the range but Partnership NOT Equal 'Reject' ?
Not operations are supported, but are not performant because it requires a full scan. When coupled with a geolocation call, it could be quite slow. We are working on improving this in the Usergrid core.
Having said that, in general, it is much better to inverse the call if possible. For example, instead of adding the property when the case is true, always write the property to every new entity (even when false), then edit the property when the case is true.
Instead of doing this:
POST
{
'name':'fred'
}
PUT
{
'name':'fred'
'had_cactus_cooler':true
}
Do this:
POST
{
'name':'fred'
'had_cactus_cooler':'no'
}
PUT
{
'name':'fred'
'had_cactus_cooler':'yes'
}
In general, try to put your data in the way you want to get it out. Since you know upfront that you want to query on whether this property exists, simply add it, but with a negative value. The update it when the condition becomes true.
You should be able to use this syntax:
https://api.usergrid.com/<org>/<app>/<collection>?ql=location within 10 of 30.494697,50.463509 and not Partnership eq 'Reject'
Notice that the not operator comes before the expression (as indicated in the docs).
I have the following. The parameter "g" is allowed to be "on" or "off", otherwise go to an error policy. However, the exception case is never called. Instead, the "on" case is called if something that is not "on" or "off" is passed as "g". Why is that? Or, is there a better way of expressing this?
<PreFlow name="PreFlow">
<Request>
<Step>
<Condition>message.queryparam.g := "on"</Condition>
<Name>GOn</Name>
</Step>
<Step>
<Condition>message.queryparam.g := "off"</Condition>
<Name>GOff</Name>
</Step>
<Step>
<Condition>!((message.queryparam.g := "off") || (message.queryparam.g := "on"))</Condition>
<Name>GError</Name>
</Step>
</Request>
I just tested your conditions and they work properly. If the request has the following query parameter values:
g=on or g=ON, the GOn policy will execute.
g=off or g=OFF, the GOff policy will execute.
g={anythingelse}, the GError policy will execute.
The := operator is the equals case-insensitive operator. How are you determining that the conditions are not working? Using your example, I made each of the policies a RaiseFault with a different fault response payload. This allowed me to verify which policy was executed depending on the value of g.
I agree with Michael, the code as shown is correct.
Thinking about possible issues that could cause this code to not work as expected:
Make sure that the names are correct inside your GOn, GOff, and GError policies. (If you are working offline, the name of the file has nothing to do with which policy gets called.) For example, the outer element of the GOn policy should look something like
<AssignMessage name="GOn">
If GOn uses AssignMessage to modify message, you might blow away the g query parameter during a step, and your later checks might fail. If you are modifying the message, store message.queryparam.g into a different variable before you do your checks.
I would use the trace tool and a tool like Postman to see what is happening for each request. The trace should tell you the variables that have been checked and their values, and you might be able to see where you are going wrong.
If you have multiple conditional checks try using javascritp.In the java script check the various conditions and set flag.And in the flow based on the value of flag execute the required policy.But for the above instance ,as Michael pointed out , the conditions should work as expected.