Migration from NAN to object_wrap / determine invoked property name

[pdehne]

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]

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]

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

[mhdawson]

@vmoroz will take a look this week.

[mhdawson]

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]

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]

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]

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]

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.
nodejs/node#42911

[github-actions]

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]

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]

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]

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]

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]

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]

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