nodejs / node-addon-api

Module for using Node-API from C++
MIT License
2.17k stars 459 forks source link

Migration from NAN to object_wrap / determine invoked property name #1114

Open pdehne opened 2 years ago

pdehne commented 2 years ago

This is a usage / migration from NAN question. With NAN I used the following to determine the invoked property name:

NAN_GETTER(ClassName::Getters)
{
        ...        
        std::string propertyName = *Nan::Utf8String(property);
        ...
}

This helped me to reduce C++ boilerplate code for classes with many properties because I did not have to declare and define every single setter and getter method in C++.

Is this still possible?

github-actions[bot] commented 2 years ago

This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.

mhdawson commented 2 years ago

Added to list of issues to discussion in next node-api team meeting

mhdawson commented 2 years ago

@vmoroz will take a look this week.

mhdawson commented 2 years ago

We talked about this is in the Node-API team meeting today and we don't have any easy way to do this today.

@vmoroz will think a bit more about it.

vmoroz commented 2 years ago

My understanding of the issue is that NAN uses the V8 ObjectTemplate that uses Proxy-like methods for Object's getters and setters to access all object properties. In Node-API we use a different approach: we define a JavaScript class as a FunctionTemplate and then explicitly add instance and static properties. I would suggest that we add to Node-API a new construct to define a native object that could use the V8 ObjectTemplate and Proxy for other JavaScript engines. Until this new API is added, developers can achieve the same effect by using existing Node-API to create a Proxy object.

KevinEady commented 2 years ago

In today's Node API meeting, we discussed the possibility of using the Proxy object as a wrapper on the natively ObjectWrap'd object. Using this approach, we may be able to create the "dynamicness" that is requested in this original post, for example passing a get handler that would pass the property name to a native method provided by the underlying ObjectWrap'd object.

@vmoroz will take a look and attempt to create some unit tests that does this and provide feedback, determining if we need to enhance the Node API for anything.

vmoroz commented 2 years ago

We used a very similar approach before to implement JSI on top of Node-API. The plan is to add unit tests to depo the approach with the plain Node-API and the C++ Node-API. Then, we will see if we can add C++ Node-API extensions to help migrating from NAN.

vmoroz commented 2 years ago

I had started to work on the unit test. So far, it works for a very simple object. I am going to continue to improve the code to cover more scenarios. https://github.com/nodejs/node/pull/42911

github-actions[bot] commented 2 years ago

This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.

mhdawson commented 2 years ago

Just leaving open, as @vmoroz is planning to add a C++ version of the example. The C based one he added has landed.

github-actions[bot] commented 1 year ago

This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.

github-actions[bot] commented 1 year ago

This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.

github-actions[bot] commented 1 year ago

This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.

github-actions[bot] commented 1 year ago

This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.

vmoroz commented 11 months ago

Reopening the issue. We still want to find a good solution here.