Develop Reference

Firestore SDK cannot mock DocumentSnapshot

So I am trying to create a unit test for a firestore trigger, triggered by an onCreate event. The firebase documentation said to do this as so: Firebase Unit Testing Background Functions
I copy the documentation pretty closely:
const snapshot = test.firestore.makeDocumentSnapshot(
{owner: 'testUserA', text: 'response from test user a'},
'users/testUserA/questions/testQuestion/responses/testResponse'
);
This line gives the error:
UnhandledPromiseRejectionWarning: SyntaxError: Unexpected token u in JSON at position 0
At first I thought it might have to do with the refPath because it starts with u, but after changing it, the error is identical, so I assume it has to do with the first parameter, which seems like correct json, but apparently not. I'm kind of stumped.
Any ideas? Thanks!

Do you have test.cleanup() in any other testing cases before you use test.firestore.makeDocumentSnapshot()? If any, remove them and run the test again

Mixpanel returning a response object instead of undefined even when opted out in AVA Unit Test

I'm trying to implement an AVA Unit Test for my mixpanel implementation. To do this, I'm comparing the result of mixpanel.track() where if it returns anything, the track was successful, otherwise, it should be undefined.
I thought maybe it was that it was using a different mixpanel instance so I tried creating a named instance and ensuring that but it was to no avail. I'm also trying the same process but with Amplitude and it seems to be working fine (when I am opted out, the response fails as expected)
I have done this in my components where if
const test = mixpanel.track('event_name', {}) is successful, !!test === true but if I do mixpanel.opt_out.tracking() prior to const test = mixpanel.track('event_name', {}), then !!test === undefined.
Expected behaviour (and the observed behaviour when I use it in my components):
trackResponse === undefined
Observed behaviour:
trackResponse === { event: 'asdf',
properties:
{ '$browser': 'Safari',
'$current_url': 'about:blank',
'$browser_version': null,
'$screen_height': 0,
'$screen_width': 0,
mp_lib: 'web',
'$lib_version': '2.30.1',
time: 1572898982.142,
distinct_id: '[some_id]',
'$device_id': '[some_id]',
'$initial_referrer': '$direct',
'$initial_referring_domain': '$direct',
token: '[token]' } }
where [some_id] and [token] are some distinct values I've deleted.
I don't understand why in the AVA test, I'm receiving a response when normally a failed track() results in an undefined response. Could someone shine some light on this?
Let me know if I need to provide any additional information. Thanks.

I figured it out in case anyone else runs into this issue.
I used a debugger to step into the mixpanel.track() calls and figured out that to see if the user had opted out, mixpanel checks for a property in the localStorage and compares it to see if it's === to '0'. If this fails, it assumes the user has not opted out and carries out the track call as normal.
I guess during the AVA test, it was unable to access this property and assumed the user had not opted out. To fix it, in my call to mixpanel.init(), I added opt_out_tracking_persistence_type: 'cookie' as an option so that my opt_out call was being saved somewhere that the property could be accessed during the test.

Error: Exception in HostFunction: Malformed calls from JS: field sizes are different. In an Animated View

As I understand this error can occur in a number of different use cases. Here is what happened in this use case
An Animated View is being controlled by a PanResponder and this is reset at certain intervals to create an infinite scroll effect.
Compiles and runs perfectly and functions as intended.
Small gestures (almost like a tap) ie. pixel movements of about +- 4dx/ 4 dy the code crashes with the error in the title.
The error is thrown in the Child View of the PanResponsder with the mismatch resulting from the translate: [{transform}] I believe.
Why does the code function fine except for smaller gestures? What casuses the error?

I ended up resolving the issue.
In this case, it was specific to a PanResponder, but I believe this can occur in other situations as well, the error tracking should be similar. A moveY variable on the PanResponder went beyond a threshold set elsewhere. This resulted in translateY being set to NaN which threw the above error. This results in a mismatch in props.
If others experience this issue my advice would be to identify the specific component experiencing the mismatch. (In this case PanResponder)
Isolate the props (set defaults/ dummy values) and ensure that each prop is resolved correctly (especially in Animated transform: translatex/translateY )
Trace the prop responsible and adjust the logic specific to that prop to avoid NaNs and undefined being passed.

I got this error when i mistakenly passed a closure as a second argument to AsyncStorage instead of the string literal i needed to store
AsyncStorage.setItem('loggedIn', (err, result) => {
console.log('I am logged In');
});
The correct thing to do is
AsyncStorage.setItem('loggedIn', 'my-jwt-token', (err, result) => {
console.log('I am logged In');
});

I was facing similar issue and solved it by changing easing value from elastic to other method. Yeah ! weird but solved the issue just incase it might be helpful to someone.
Animated.timing(height, {
toValue: 500,
duration: 1500,
easing: Easing.elastic,
}).start();
TO
Animated.timing(height, {
toValue: 500,
duration: 1500,
easing: Easing.linear,
}).start();

My issue was that I was using Easing.inOut itself without passing another easing function inside, like Easing.inOut(Easing.elastic(1)). I thought Easing.inOut was an ease in itself but it actually just makes whatever easing function you pass into it symmetric. Easing.in and Easing.out similarly make whatever you pass into them run forwards or backwards. See https://reactnative.dev/docs/easing

In my case, I was passing an entire response object to an analytics tool, but it wasn't JSON.stringify-able.

that error appeared to me when I passed a wrong type value as date to this peace of code
PushNotification.localNotificationSchedule({
channelId: 'channel-id', // (required) channelId, if the channel doesn't exist, notification will not trigger.
title: 'My Notification Title', // (optional)
message: 'My Notification Message', // (required)
date: date, // in 60 secs
allowWhileIdle: false, // (optional) set notification to work while on doze, default: false
repeatTime: 1, // (optional) Increment of configured repeatType. Check 'Repeating Notifications' section for more info.
});

I don't know if its relevent or not but in my case, this error was occuring when i was doing this in react native ->
Alert.alert("Error", error, [ { text: "OK", }, ]);
instead of this ->
Alert.alert("Error", error.message, [ { text: "OK", }, ]);
so that's means pass the correct data type and error will get resolve.

In my case I got this error when I was accidentally passing NaN to width property of a component.
So double check that all your data is in the expected/correct format at different stages of state updates.

How do I throw an error on a behaviour subject and continue the stream?

On one end, I have a stream which may occasionally throw an error:
this.behaviorSubject.error(error)
Later on, however, I want to continue the stream:
this.behaviorSubject.next(anotherValue)
on the other end, I have a subscriber subscribed to behaviorSubject.asObservable().
In the subscribtion, I'm handling the value and the error:
.subscribe(
( value ) => { /* ok */ },
( error ) => { /* some error */ }
);
I want the effect to be the same as a simple onSuccess and onError callback, where onError is called every time an error occurs and doesn't prevent future onSuccess calls from being made. How do I do this with RXJS?
I've looked into catch but it seems to just prevent error from being called on subscribers.

Short answer: It's not possible.
How to work with this: The basic concept of RxJS is that any error or complete-call will basically "kill" a stream. This concept forces you not "just to throw around errors here and there as you please" but to handle errors and the flow of data within your application properly. A BehaviorSubject for example is typically meant to hold data, however it should not be used to also include the process of retrieving/creating that data and handle possible errors that might occur during the retrieval of the data.
So if you want to go by the book, you should split up your flow into two parts:
Retrieval/creation of the data: A stream, that will run once then then completes and/or throws an error whenever one occurs.
When the data is retrieved it will be sent to the store.
The store (e.g. as in your case: a bunch of BehaviorSubjects): Only valid data arrives in the store, this means that no error-handling is done here and all parts relying on the store can trust in the store that it holds the correct data.
As an example your data flow could look as follows (as a rough sketch):
store.ts
dataStore: BehaviorSubject<IData> = new BehaviorSubject<IData>();
errorMessage: BehaviorSubject<IErrorMsg> = new BehaviorSubject<IErrorMsg>();
data-retrieval.ts
fetchDataById(id: string) {
httpService.get(`some/rest/endpoint/${id}`)
.subscribe(handleData, handleError);
}
handleData(data: IData) {
errorMessage.next(null);
dataStore.next(data);
}
handleError(error: Error) {
errorMessage.next(error.message);
dataStore.next(null);
}
"But this looks like a lot of overhead..." - True, however it ensures a clean and easy-to-understand flow of data within your application, that is easy to test and maintain. Also there are ready-to-use store-concepts like ngrx or redux that could be used.

Rx is fundamentally built upon the concept that an observable is either active or finalized (onComplete or onError). When an Observable is finalizing it will unSubscribe from its upstream Observable. No .catch can fix that behaviour, it only gives you the option to map the error to something else.
Rx.Observable.interval(500)
.mergeMap(i => i % 3 == 2 ? Rx.Observable.throw(new Error('kboom')) : Rx.Observable.of(i))
.catch(err => Rx.Observable.of(err.message))
.subscribe(
val => console.log('val: ' + val),
err => console.log('err: ' + err),
() => console.log('stream completed')
)
Note that this example completes after 3 emissions instead of 5
When you invoke this.behaviorSubject.error(error) it wil internally finalize the Observable contained in your Subject. If you want to somehow emit errors then you need to make your errors non-error values:
this.behaviorSubject.next({ value: 'somevalue' });
this.behaviorSubject.next({ error: error });
this.behaviorSubject.next({ value: 'somevalue' });
Then you are able to distinguish based on the properties on your emitted value what action you should take.

This may not work for your situation, but I ran into this same issue when work with Angular 2 because we would navigate across screens and would want the service to retry an API and not just call the error function again. It would actually cause bigger issues because the function was called in our constructor and the error function would try to update the UI which was not yet ready.
What I did seems to work fine and be pretty clean. I created a reset the Subject in the error handler.
subject.subscribe(
( value ) => { /* ok */ },
( error ) => {
//handle error
//reset subject
this.subject = new Subject<any>();
}
);
This works in our case because every time you navigate to the screen new subscriptions are getting torn down from the old screen then set up in the new, so the new subject won't hurt anything.

As others have said, the error result is expected to be terminal.
Personally I think (in your case) there are 3 types of results (technically 4)
The ideal result is the success case that calls next().
A lethal fail (out of memory error or any other form of "call can't continue" error) should call error().
The third form and the one that is key to your problem is the non-terminal error. It is the "Result was not a success" form. Because you mean to continue, it is not an Error in the rxjs sense. It is merely another type of result. A result that says something else happened.
(The 4th form is "processing completed": done all I can and am exiting without error)
Now I'm not sure of the details, but as I recall typescript can handle union types (if not you might have to play with a result type of "any").
With Unions you can declare your object as (for example) Subject<string|failtype>
The point here is you can send different results from the next statement.
You'd do something like the following...
DoCoolThingFunction():Subject<string|failtype>
{
const response = new Subject<string|failtype>();
deeperPeriodicAsyncOperation.subscribe((result) => {
if (result is something I like) {
response.next(result.toString());
} else if (result is final value) {
response.next(result.toString());
response.complete();
} else if (result is something teminal) {
response.error(result);
} else if (result is non-terminal error) {
response.next(new failtype(result));
}
});
return response;
}
Basically, this is saying "An error in this range is non-terminal. As such it is not an error, it is just a different kind of operational data".
Of course it is up to your receiving code to determine which type of result it has been handed. I've no idea if there are any neat ways to do that. It'd be great if the result handler could have multiple different typed responses ((result:string) =>{}, (result:failtype)=>{}) etc. but that's not really a topic for this thread.

NS_ERROR_UNEXPECTED error in Firefox using Dojo

I'm having a strange issue that's being thrown in Firefox when using my Dojo (v.1.10.0) application.
Here is the following error that I'm seeing in Firefox:
Exception
{ message: "",
result: 2147549183,
name: "NS_ERROR_UNEXPECTED",
filename: "http://localhost:8888/dojo/on.js",
lineNumber: 354,
columnNumber: 0,
inner: null,
data: null
}
""
Unfortunately, I'm not sure where to go with this in my application. Can anyone point me in the right direction?
On line 354 of dojo/on, this is happening:
if(has("dom-addeventlistener")){
// emitter that works with native event handling
on.emit = function(target, type, event){
if(target.dispatchEvent && document.createEvent){
// use the native event emitting mechanism if it is available on the target object
// create a generic event
// we could create branch into the different types of event constructors, but
// that would be a lot of extra code, with little benefit that I can see, seems
// best to use the generic constructor and copy properties over, making it
// easy to have events look like the ones created with specific initializers
var ownerDocument = target.ownerDocument || document;
var nativeEvent = ownerDocument.createEvent("HTMLEvents");
nativeEvent.initEvent(type, !!event.bubbles, !!event.cancelable);
// and copy all our properties over
for(var i in event){
if(!(i in nativeEvent)){
nativeEvent[i] = event[i];
}
}
return target.dispatchEvent(nativeEvent) && nativeEvent; // Line 354
}
return syntheticDispatch.apply(on, arguments); // emit for a non-node
};
}

This is a generic FF error message... it's usually triggered by a timing or race condition, which may explain why it's showing up via dojo/on. Maybe the target or event handler that you're trying to work with is acting on something that has been removed, etc. It's unclear without knowing what event is triggering it or without seeing your full code example.
For example, maybe you're trying to add event listeners before the DOM is available, but that's just a guess. Or maybe the target node doesn't exist.
You can use the debugger to see the values of the event parameters, or you can look at your various event registration mechanisms, etc.

We have a similar issue using intern 2.0 and unit tests creating native select boxes.
Some library code (verified that its not our own) triggers a dojo.emit() which causes the internal error.
We're trying to identify the problem in more detail. If you find something please let us know as well!

we were also getting same exception at exactly same point,
for us, we replaced our code elementReference.destroy() // destroy is a dojo function with elementReference.domNode.remove() and it solved our problem.