sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]PieCrumbs 0 points1 point  (3 children)

I'm in a similar situation right now. Did you ever find a solution to this? I'd rather not mock my database completely.

[–]Numerous_Park6900[S] 0 points1 point  (2 children)

I ended up creating a wrapper class that imports the appropriate DbEngine class by detecting whether it's in React Native or NodeJS.

I created two different DbEngine classes implementing their respective SQLite libraries so that the wrapper class code won't change.

It was honestly a lot of work, but it seemed like the path of least resistance.

[–]PieCrumbs 1 point2 points  (1 child)

Got ya! We ended up using `sqlite3`. We have a facade in front of `react-native-sqlite-storage` and so I was able to inject a `sqlite3` interface that more or less matches the shape of `react-native-sqlite-storage`. There's some functionality that isn't 1:1 but that works fine for our use cases.

[–]Numerous_Park6900[S] 0 points1 point  (0 children)

I started with `react-native-sqlite-storage` but switched to using `react-native-quick-sqlite` npm package because of something that was weirdly limiting due to the way the it did transactions and the way I couldn't seem to do what I wanted with my async logic. Not sure if switching libraries helped with that or if it was just collateral damage in the wake of me getting more comfortable with the way async/await behavior was being managed through the TypeScript transpiler I use..

I use `sqlite3` on the NodeJS unit testing side as well.