I'd like to add the ability to hook into a Node.js program I am writing for release. Ideally, I'd like something like the Wordpress Hook system (traditionally for PHP and recently for Javascript!) that is very robust, yet simple.
It seems WP has released a Node module for just this purpose: https://www.npmjs.com/package/#wordpress/hooks
However, I can find no documentation or real-world examples explaining how exctly to implement this.
Lets say I have a function that does this:
function processObj(myObj){
doThing1(myObj);
doThing2(myObj);
// I want to allow plugin writers to add a Thing3, Thing4, etc...
return myObj;
}
I believe this is a filter... As in I want to allow plugins to filter myObj through Thing3 (which they create) before the return. But I'm lost as to how to implement.
Related
I'm writing some tests for my React-Native application (using JS) in a NodeJS environment. In one scenario, I need to attach to an already-running Windows application. In order to attach to this Application, I need to know the NativeWindowHandle value.
For example, if you open Inspect.exe on a window, you'll find the "NativeWindowHandle" hex value.
Is there anyway I can find this value programmatically?
What I've Tried:
I'm able to find the PID of the app using:
const exec = require('child_process').exec;
exec('tasklist', function (err, stdout) {
....
}}
However, I haven't been able to turn that into the window handle. Does anyone have any ideas here? Is this possible?
This can be reliably accomplished by writing a native (C++) node addon which calls the appropriate Windows API functions and passes the results back to JS land.
eg you might want to call FindWindowEx and Windows will find and return the HWND (native window handle) of the matching open window. Or use one of the enumeration functions if you need to do the search yourself.
I did a quick search of npm and it looks like there might be a few packages that have done this work already, but you'll need to evaluate them.
If none of the npm packages will work, you'll need to write it yourself. This isn't too hard if you have a little C++ knowledge, but alternatively you might be able to get away with using node-ffi, which lets you write everything in JS and marshals the native calls for you.
(Using ffi will be a little slower than writing the native module yourself, but for your purposes that doesn't really matter. Either native or ffi will be much faster than spawning child processes.)
I'm trying to apply new documentation to legacy code that is
Undocumented
Minified (We don't have the source code)
Included in the rest of the code via window.thing = thing in the minified file, instead of using modules and exports.
Used literally everywhere. It's the base framework for the entire web application.
My main intent is to get vsCode to display some intellisense for this module when I create a new page/file, rather than having to copy&paste code from other pages/files before it will tell me how to use the module's methods. And even then, it doesn't tell me how it works. Although after a few months I can now write this code somewhat reliably without looking, I've had to unravel the minified file some to find all the methods and properties available. I should be copy&pasting imports, not the whole damn file. We're also bringing in new developers soon, and (although coworkers disagree), I want to have something more for them to look at then just 'follow the pattern on the other pages'.
We are using webpack and have the ability to use modules. I prefer the module pattern, but it is clear that those who came before us did not. Using window.thing to use the module between files. My coworkers prefer to 'follow the pattern already there', rather than trying to fix old code. I don't whole-heartedly disagree, but still. So I need to make this as unobtrusive as possible.
webapp/documentation/main.js
import './thing.js';
/**#type {thing}**/
var thing; // This does not work. `thing` is marked as any.
// So I changed the type to thingModule.
/**#type {thingModule}**/
var thing; // This works.
/**#type {thingModule}*/
window.thing; // This does not work.
/**#type {thingModule}**/
var thing = window.thing; // Works for thing
// But does not change window.thing
However, none of those above propagate into the next file.
webapp/view/someFile.js
import '../../documentation/main.js';
/**#type {thingModule}**/ var thing = window.thing;
// Cannot change below this line //
thing.addView(/*blah blah blah*/);
thing.doStuff();
This allows me to look up properties of thing. But it does change the code slightly. Not much, but just enough that it would be frowned upon if left in the code when committed. Plus, if I find other modules that need similar documentation, I don't want a growing import statement for just documentation.
I need to be able to include it in a single line that only provides documentation.
import '../../documentation/main.js';
// Cannot change below this line //
thing.addView(/*blah blah blah*/);
thing.doStuff();
In this case, thing is shown as ':any' instead of ':thingModule' like it needs to be.
tl;dr:
I need to assign the #typedef to window.thing and make the jsDoc definition propagate anywhere documentation is imported. And I need to not change the actual declaration of window.thing.
What I've got
A large (proprietary unfortunately) JS library, the many small modules that get rolled up into it during the build process, the accompanying source map, and over 300 examples that use the built version of the library.
The goal
A form of dependency tracking, I guess? I need to be able to modify one of the small modules, rebuild the large file, and then only re-verify the examples that were affected by this change. Note: I don't care whether this requires static analysis or if I have to run all examples thru a headless browser to extract something or so - I'm fine as long as it can be automated.
What I've tried so far
I've read answers to questions like this and tried pre-existing tools like
Madge, but none of them seem to work for my case. Madge in particular is great for telling me which of the modules depend on which modules, but that's not what I'm looking for. Most solutions online are based on the assumption that you're already using something like require.js or similar on which they can piggy-back, but in my case the library is simply just a giant blob.
My current approach is instrumenting the built version of the library by simply appending every line with something like neededModules["the_file_this_line_comes_from.module.js"] = true similar to how code coverage tools do it. However, that fails because of several parts like this:
Points.prototype = Object.assign( Object.create( Info.prototype ), {
plot: ( function () {
var static = new Background();
return function plot( line, physics ) {
<code>
};
}() ),
copy: function () {
return new this.constructor( this.info, this.history ).copy( this );
}
} );
The copy function is tracked/skipped just fine, but because the plot function is an IIFE(right?), the line var static = new Background(); always gets executed, even if there is absolutely no connection to the Points module.
What I'm looking for
Either some help with my current approach and its problems with IIFE or a different solution altogether. I've seen Facebook's Jest does offer dependency tracking, maybe someone has experience with that one, or there's some way to incorporate the source map?
Again, as long as it's automatable and finishes in let's say < 5 min, I'm totally fine with it no matter if it's static analysis or just some hacky script or whatever :)
Thanks!
Facebook's JS SDK has recently started using newer ES5 Javascript methods such as Object.keys() and [].map(). They still support older browsers by having an ES5() function that accepts the original object, the name of the desired method, and any parameters. It then runs either the native method or an equivalent JS method if the native one isn't available. For example:
ES5(g.api.whitelist, 'forEach', true, function(ca) {
s[ca] = 1;
});
or for top-level objects,
ES5('JSON', 'parse', false, r.responseText);
I suspect that this is the result of a preprocessor, and FB's devs are actually writing something more along the lines of
g.api.whitelist.forEach(function(ca) {
s[ca] = 1;
});
and
JSON.parse(r.responseText);
(presumably with longer variable names too)
Now, assuming I'm right that there is a preprocessor, is the ES5() function and associated preprocessed are an open-source project or something in-house? If it's in-house, can anyone from FB comment on the possibility of open-sourcing it? It's something that I could find tremendously useful.
We are indeed using a preprocessor (based on jspatch) which lets us write regular ES5 code. The ES5 function itself is basically a wrapper around polyfills from MDN and JSON3.
Not only does this let us write ES5, but it avoids us using faulty implementations of things like Function#bind and JSON.stringify.
The blog post is now out.
Searching Facebook's open-source github repositories does not show any ES5 methods. I explicitly checked out and recursively grepped the ones that mention javascript. So it does not appear that what you are seeing is publicly available from them. I could not find it anywhere else either.
If you need ES5 backwards compatibility, have a look at this es5-shim
http://connect.facebook.net/en_US/all.js
is this what you want? it doesnt list any licenses in the file and it seems to be autogenerated?
https://github.com/facebook/connect-js/
?
this would point to "yes" and the license would be apache?
I'm taking a foray into Firefox extension development for the first time, and so far it's been pretty comfortable going, but I'm running into a problem; one of the things I need to do overwriting the built-in nsIPromptService and replacing it with something of my own instead.
I walked through the basic XPCOM component creation tutorial here and got the hello world one working:
https://developer.mozilla.org/en/creating_xpcom_components
And everything in that seems to work fine, but nothing I've been able to find or research shows how I can overwrite an interface from javascript. I've seen things in C++ and Java that seem to be able to overwrite the built-in components, but I can't find anything about doing this from javascript, and just trying to change the contract ID didn't work; when I try to get the service from the contract ID (as below), it just returns the original, built-in component version.
var myComponent = Components.classes['#mozilla.org/embedcomp/prompt-service;1']
.getService(Components.interfaces.nsIPromptService);
Is there something really obvious here that I'm missing? Is this the wrong way to go about overriding components (I can't seem to find anything anywhere, so I'm not really sure what I should be doing..).
Neil, thanks for the suggestion. That's what I thought I was doing (and I was), but if you're actually overriding a contract (instead of defining a new one), it looks like the answer is that you have to go to the nsIComponentRegistrar and actually register your factory (rather than relying on the chrome.manifest to handle it for you). An example of this would be:
Components.manager.nsIComponentRegistrar.registerFactory(CLASS_ID, CLASS_NAME, CONTRACT_ID, MyPromptServiceFactory);
Where the constans were:
const CLASS_ID = Components.ID("{a2112d6a-0e28-421f-b46a-25c0b308cbd0}");
// description
const CLASS_NAME = "My Prompt Service";
// textual unique identifier
const CONTRACT_ID = "#mozilla.org/embedcomp/prompt-service;1";
Where the CLASS_ID/CONTRACT_ID were the IDs for the pre-existing service.
You need to register your component using the contract id of the service that you want to override.