I am using this library in where I was hoping to find yaw rotation in degrees from the given reference frame.
However when starting to test it out I am noticing the yaw changes drastically when slightly moving the device in roll and pitch fashion. When having the device on a table and rotating in it seem to give the correct values.
I am also noticing when looking at the roll - which seem to give correct values when rotating it in rolling fashion - that slightly moving it in pitch suddenly drastically changes the value.
Are the values given not isolated from each other - rotation from the given referenceframe?
Notice that the library uses quaternion - so there should not be a gimbal lock problem - or does it arise from simply representing the rotation in degrees (with Euler angles)?
Here is the source code
Edit: I modified the react-native-sensors to give me CMDeviceMotions atttitude on iOS (roll, pitch, yaw). They gave me the rotation independently from each other - which solved the problem.
The Gimbal lock is an inherent property of rotation representation using Euler angles (i.e., yaw, pitch, roll or any other combination). While you are correct that quaternions don't suffer from this issue, the Euler angles representation you convert them to does.
A "solution" often used in practice, if you want to keep on using Euler angles to represent your rotations, is to switch from the yaw-pitch-roll (x-y-z) representation to a different combination that works better in your coordinate system - have a look at the wiki page for combinations you could try. This essentially just places the gimbal lock to a different combination of angles, but for practical applications with well-defined ranges of values, this is often enough to avoid problems.
Depending on your use-case, a more "correct" solution could be to switch fully to quaternion representation, which avoids the problem altogether.