So now to test out if this module works in a node script, to do so I just need to require the script in like always. The way that I typically do this is to require the path module, and then join the value of the dirname global with the path to the utils.js file that I coved above fro the script that is using it. This way I end up with an absolute path to the script, which will always be the location of the utils script regardless of where I call this example with nodejs.
I can then call one of the public methods of the module from the script that makes use of it, for this example I am just testing out that distance formula.
If I then save the above code as index.js in a folder, and then place the utils.js file that I coved above in the lib folder off of that folder like so I can then call the index.js script in the thermal like this.
So then the module is working as expected in node, but what about a browser example.
So then this kind of pattern will work for most of the kinds of modules that I make, but not all of them. There is a point where a script that I have in mind is just going to need to be very much node only, and the same can still be said of many of the modules that I make that are very much client side only when it comes to something that has to do a lot with canvas elements for example.
Still when it comes to some kind of module that has to do with the creating and mutating of a simple object state, a parser, or something to that effect this kind of module pattern seems to work just fine. It might be a good idea to think in terms of making some kind of core module that creates and updates a state object, but refrain from combining code that has to do with rendering that state.
This kind of module seems to work okay, at least with the few test scripts that I put together for it. However I have not done anything to major with this, or anything else that I have made based off of this so I might stop writing about it for now until I have more to say about it. There are many frameworks that have this kind of system built into it, but I just wanted to quickly thrash together my one system for making user defined events.
So then here is a nodejs demo of this event module. Just like with any other nodejs module I just need to require it in, and then I can use it. For this example I just made a very simple demo of a player object and setting up a on hit event for the object. That is that the player object just has one property that is a hit points value, and I want to have an event that will subtract some damage from that hp value each time the hit event happens.
Here now is more or less the same demo as before but now I am creating a client side demo of the module. This time I am using a text area element as a way to go about logging the output of the results.
It is great that if I want to, I can go about writing my modules like this, so that code will only have to be written once and then it can be used in the front or back end. However just because I can do something does not alone mean that it is a good idea. It might still be best to maintain browser and nodejs variants of the same module, but doing something, especially when it comes to using features that are node or browser only.
There are many popular frameworks that follow some kind of pattern like this, and that does not keep me from using them. Or at least I would not stop using it as long as there is not some good reason why not to. It should go without saying that if we are talking about some kind of sever side script that contains source code that should not end up being public that is of course a whole other story. However when it comes to kind of library that I would want to make portable from both the client side and sever side environments then it is nice to have one file that will work in bother environments.