Generally, FFI functions are named as is (e.g.
functionName) when they can be used as-is and are otherwise named slightly differently (usually with a “Impl” suffix) when there’s additional work one must do to make it type-safe (e.g. something returns a
null and you want to convert it to a
-- in FFI file: `exports.functionName = functionName;
foreign import functionName :: Object String -> Int
-- vs something like
-- in FFI file: `exports.functionNameImpl = functionName;
foreign import functionNameImpl :: Effect (Nullable String)
functionName :: Effect (Maybe String)
functionName = map toMaybe functionNameImpl
That being said, there are some cases where you might want to use
Nullable rather than
It might also use the “Impl” suffix if the value is an uncurried function (e.g.
EffectFn4 a b c d e). Then one might provide a curried interface by wrapping the function in a
-- in JS: `exports.functionNameImpl = functionName;
foreign import functionNameImpl :: EffectFn4 Int Int Int Int Unit
functionName :: Int -> Int -> Int -> Effect Unit
functionName = runEffectFn4 functionNameImpl
I think the first part of a module’s name should follow the library. So, if you publish this as
purescript-firebase, the module should be
Firebase.Functions (onRequest) and not
Foreign.Firebase.Functions (onRequest). If you wanted to distinguish the backend (in case they have bindings to something other than JS and they’re different), then adding a
JS somewhere in there would likely work. However, I’m less sure/confident about this because most libraries are written for JS.