Node-addon-api: Best practice to store context-aware class constructor reference

Created on 19 Jan 2020  路  2Comments  路  Source: nodejs/node-addon-api

I've seen many users just store the class constructor reference statically for later use. This will definitely cause issues if the addon is used in both master thread and worker threads. We shall document the best practice to prevent such pitfalls. Or was I just missed such docs?

Most helpful comment

@legendecas I was planning on writing a class Napi::Addon that would solve this problem by having all bindings be instance functions rather than static ones. However, I believe that it would be best to have https://github.com/nodejs/node/pull/30537/ (backport of instance data to v10.x) for that, so we can use napi_get_instance_data() for retrieving the addon instance in the implementation.

All 2 comments

@legendecas I was planning on writing a class Napi::Addon that would solve this problem by having all bindings be instance functions rather than static ones. However, I believe that it would be best to have https://github.com/nodejs/node/pull/30537/ (backport of instance data to v10.x) for that, so we can use napi_get_instance_data() for retrieving the addon instance in the implementation.

It turns out that adding such a class would mean that we'd have to pretty much duplicate the entire API for creating functions, classes, and property descriptors. So AFAICT it's best to do what #663 does, which is to make the data available on the Napi::Env.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

NickNaso picture NickNaso  路  8Comments

bmacnaughton picture bmacnaughton  路  6Comments

jeffrson picture jeffrson  路  4Comments

timarandras picture timarandras  路  4Comments

D-Andreev picture D-Andreev  路  6Comments