The sys module was moved from a neon-runtime crate when the C++/NAN backend was removed. Originally it made sense to have logic there in order to abstract over the backend. However, now that there is a single backend it's no longer necessary to restrict calls to Node-API to this module. In fact, the extractor PR makes heavy use of sys functions for performance.
A cleaner and easier to follow model is a module for each JavaScript type.
In this structure, we would move TryFromJs implementations. In many cases, we could de-duplicate code by making fn value(..) implementations delegate to try_from_js. For example, JsString::value:
impl JsString {
pub fn value<'cx, C>(&self, cx: &mut C) -> String
where
C: Context<'cx>,
{
String::try_from_js(self.upcast())?.unwrap()
}
}
The
sys
module was moved from aneon-runtime
crate when the C++/NAN backend was removed. Originally it made sense to have logic there in order to abstract over the backend. However, now that there is a single backend it's no longer necessary to restrict calls to Node-API to this module. In fact, the extractor PR makes heavy use ofsys
functions for performance.A cleaner and easier to follow model is a module for each JavaScript type.
In this structure, we would move
TryFromJs
implementations. In many cases, we could de-duplicate code by makingfn value(..)
implementations delegate totry_from_js
. For example,JsString::value
: