You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Migration from NAN to object_wrap / determine invoked property name #1114
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++.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
Activity
github-actions commentedon Mar 24, 2022
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 commentedon Mar 24, 2022
Added to list of issues to discussion in next node-api team meeting
mhdawson commentedon Mar 25, 2022
@vmoroz will take a look this week.
mhdawson commentedon Apr 8, 2022
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 commentedon Apr 15, 2022
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
FunctionTemplateand 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 commentedon Apr 22, 2022
In today's Node API meeting, we discussed the possibility of using the
Proxyobject as a wrapper on the nativelyObjectWrap'd object. Using this approach, we may be able to create the "dynamicness" that is requested in this original post, for example passing agethandler that would pass the property name to a native method provided by the underlyingObjectWrap'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 commentedon Apr 22, 2022
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 commentedon Apr 29, 2022
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 commentedon Jul 29, 2022
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 commentedon Sep 23, 2022
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 commentedon Dec 23, 2022
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 commentedon Apr 4, 2023
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 commentedon Jul 4, 2023
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 commentedon Oct 11, 2023
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 commentedon Nov 11, 2023
Reopening the issue. We still want to find a good solution here.